AnsweredAssumed Answered

Flash write causes crash after porting code.

Question asked by TeeJay on Feb 25, 2016
Latest reply on Feb 26, 2016 by Clive One
Hi, I have hit a rather strange problem that has completely stumped me!

I have a really simple bootloader for the STM32L100 device which uses the USB DFU interface to copy new firmware into the flash. The bootloader resides at 0x08000000 and is about 3K in size. The main firmware sits at 0x08003000. The original code was developed on the IAR platform and worked absolutely fine. Yesterday, I ported the code over to eclipse/gcc where I built both the firmware image and the bootloader image with no problems at all. I uploaded the bootloader and it appeared to run fine (at first). It creates a DFU device on the PC and seems to do everything it should until I try to actually upload the firmware.

For some reason, the GCC version of the bootloader hangs as soon as it tries to write to the flash memory whereas the IAR version does not!

I have run it with the debugger and I have tracked the problem down to a call to:

FLASH_ProgramHalfPage() which appears to be an ST Library function

I checked the parameters to the function using a breakpoint and both the address and buffer were correct. The Address was 0x8003000 and the buffer points to a valid ram location which contained the correct data. It all looks correct.

When I step into the FLASH_ProgramHalfPage() function, I find that the crash occurs 
at this line:

 *(__IO uint32_t*) (Address + (4 * count)) = *(pBuffer++)

and by stepping though the assembler, if find it is the STR instruction that causes the fault

str r2, [r3, r4]

That suggests to me that the flash is write protected at that point?

The source code is identical, it was just a case of porting it over and rebuilding it, I did not have to make any changes at all. 

The only possible causes that I can think of are

1 - Optimisation - I tried various settings. IAR was set to -Os. Also when I step through the code, everything seems to happen just as I expect (until it crashes!!!)

2 - Environment Variables (They all appear to be the Same), I could not find anything that could explain what I was seeing.

3 - A timing issue ?? - Again, I checked and it all looks right. The USB works, which indicates that the clock speeds are what I expect. Not surprising, it is the same source code!

4 - Some other hidden gem of config information that IAR is keeping to itself.


5 - Something so obvious that I cannot see it for looking! (Most probable!)

I know this is a shot in the dark, but can anyone offer me some clues where to look next?

What else could cause a fault at that point in the code? is there something about ST Flash memory and GCC that I need to know about? Or some Magic that IAR do in the background during initialisation. I have looked at everything I can think of.

I can provide version numbers and snippets of the source code if they help.

I have developed a lot of very low level code in GCC for  all sorts of hardware (it what I do for a living) and this is the first time I have ever seen a problem like this. I have Googled everything I can think of. I know it must be something very simple and probably quite low level. I also know that that  will probably be quite obvious when I know where to look! But I am darned if I can put my finger on it? 


Help Please!


Regards


Tim

Outcomes