Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
PIC32 bootloader issue
26-05-2014, 08:16 PM,
#1
PIC32 bootloader issue
Hi all,

i am creating a new thread, which is closely related (if not the real issue) to the 2 previous threads i created (floating point calculation issue and PIC32 CDC issue).
After quite a lot of exchanges (thanks John) and trials and experiments with my PIC32MX250 DIY board, as well as some digging in the map file, i am on the way to conclude that the two above issues are not related to the C code itself, nor to the compiled file, but, with a high probability, to the bootloading of this code inside the PIC.
Indeed, once the compiled code size is a little bit above 14624 bytes (as reported by the IDE) the PIC don't work (PIC is stalled ) while if the code is under this value, everything works nicely.
It looks like either the uploader do not send correctly the full hex file or the bootloader code in the PIC is somewhere bloated.
I have to test with mphidflash to see if the problem occurs too.

Joël
Reply
26-05-2014, 10:14 PM,
#2
RE: PIC32 bootloader issue
It has -h for help I think and its code is on the net with samples of usage as I recall.

John
Reply
27-05-2014, 02:20 AM,
#3
RE: PIC32 bootloader issue
Joel,

The size reported by IDE is total of flash and RAM, it may exclude the size used by the bootloader. If you use 'mips-size', it will give you more details separated by different sections. Still the best way is to analyze the map file yourself.

Many times, the reason the PIC is not running after successfully compile and upload is due to uploading error. I don't mean uploading failed and retry, but the compiled hex file may not be acceptable by the uploader. You can enable 'verify' option of 'mphidflash' and you may see some differences from reading back of the flash after writing.

This type of error is usually caused by multiple non-zero initialized static variables in the global scope. Possibly the routine to initialize the initial static variables may have problem. Just guess only.

DJ
Reply
27-05-2014, 09:24 AM,
#4
RE: PIC32 bootloader issue
If it's that (and I don't know) then it would point to a bug in the Pinguino code (in its start-up support code in that case). Let's see and if so fix it.

John
Reply
27-05-2014, 04:11 PM,
#5
RE: PIC32 bootloader issue
Hello,
i can also confirm that Pinguino bootloader on pre-flashed PIC32MX250F128b won't write anything beyond address 0x9d007fff, which leaves for about 14K of program size. I tested for this issue by placing some code around this address followed by reading the flash memory.

Regards,
Mihai
Reply
27-05-2014, 07:47 PM,
#6
RE: PIC32 bootloader issue
The mphidflash verify option do not work neither on working code nor on non working code (stall)..so it is difficult to tell from that point of view if the code was written properly (i am under win7,if it can be a reason)

Concerning variable initialization and so on, why the problem occurs only when size is over around 14k ? Will an initialization of all the variables (with 0 for example) solve the problem? (easy to test, will do so)

IIf it is, as John told, ,a bug in the pinguino code, i do not feel capable of fixing (particularly if it is assembly code...)! Confused

Joël
Reply
28-05-2014, 01:26 AM,
#7
RE: PIC32 bootloader issue
The way C (static, i.e. non-auto) variables get initialised is that they're all marked by the compiler such that the linker can collect them (using the link script .ld / .x etc files) into one or more lumps ("sections"). Each start & end of the section is known and then when all this stuff is flashed into the chip and chip reset occurs some init code runs. It zeros the whole area, no matter how large. Very simple code (like memset).

Now, if the compiler version changed and did things a little differently and the link script didn't change to cope with it fully, trouble could occur.

The same applies, with tweaks, to other variables and indeed code.

Don't know if this is helping!

John
Reply
28-05-2014, 09:12 PM,
#8
RE: PIC32 bootloader issue
(28-05-2014, 01:26 AM)pingotg Wrote: Don't know if this is helping!

John

At least i understand what you are telling...Smile
My plan for the end of this week will be to get a fresh linux install and see if it happens also with pinguino under linux, then, may be try to re-programm a pic32 (to see if the booloader code in my PIC is somewhere bloated)...and if nothing work i'll be stuck there...

Anyway, for sure, if we can have a solution for this annoying issue (either by trying this two points or if someone on this forum have a fix) it will remove a big "pain" for the users of the pic32 DIY(if they have the same problem than me, which i don't know...). Indeed this little PIC32 board is really powerful (EEPROM/SRAM) and it is "too bad" to be blocked in the full usage of this power by such a bug!!
Reply
29-05-2014, 08:23 AM,
#9
RE: PIC32 bootloader issue
(27-05-2014, 04:11 PM)mihaim Wrote: i can also confirm that Pinguino bootloader on pre-flashed PIC32MX250F128b won't write anything beyond address 0x9d007fff, which leaves for about 14K of program size. I tested for this issue by placing some code around this address followed by reading the flash memory.

I missed this statement and it possibly explains all the issues.

The flash region up to 0x9d007fff is the max size for PIC32MX220. If PIC32MX250 is using the same bootloader created for PIC32MX220, the bootloader will not erase or write above the address.

DJ
Reply
29-05-2014, 09:06 AM, (This post was last modified: 29-05-2014, 02:34 PM by pingotg.)
#10
RE: PIC32 bootloader issue
Aha! I suspect you've found it.

Looking at the MX220 bootloader source, it erases only up to there (checks Address < 0x9D008000) so any reflash is doomed above there. I don't know if it was changed for the MX250 (but it needed to be).

Do you have any way to reflash the bootloader? (I think you'd need a PICkit2 or 3.)

I think JP & RB (Regis) made the bootloader but I may be wrong. See if you can PM them.

John
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)