FLASH_ProgramWord not working

[daviddavid942]

Posted on February 18, 2010 at 10:34

FLASH_ProgramWord not working

#stm32 #stm32

[armmcu2]

Posted on May 17, 2011 at 13:40

Hi Marco,

Have you tied to do this word flash programming  though linker options as below ?

Const int Data __attribute__((at 0x8002400))= 0x????.????;

Cheers.

[daviddavid942]

Posted on May 17, 2011 at 13:40

Hi,

if you mean const initialization... yes. I did not report the full form above, but the configurtion variable is declared as <<const CFG_T Cfg __attribute__((at 0x8002400)) = { ... }; >> and it shows up correctly initialized during debug. If you mean changing it to int type... why ? If you mean other link options... then I don't understand, please explain...

[armmcu2]

Posted on May 17, 2011 at 13:40

Hi,

My undestanding, is if you are making this:  

Const int Data __attribute__((at 0x8002400))= 0xaaaa5555;

So normally 0xaaaa5555 word is programmed through Keil Flash loader into 0x8002400 location. So my question is: Does this write operation  well done by Flash loader. my aim is to just verify that your issue is well linked to your programming sequence.

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

What speed are you running the system at? ST's boot loader has the PLL running, at 48 MHz or so. I seem to remember a speed requirement, but can't pull a cite right now.

Not having any problem here with an STM32F103, the writes must be WORD/HALFWORD aligned, and the buffers must have been erased.       FLASH_Unlock();       FLASH_ClearFlag(FLASH_FLAG_BSY | FLASH_FLAG_EOP | FLASH_FLAG_PGERR | FLASH_FLAG_WRPRTERR);         while(len--)         {             FlashWord = (u16)*s++;             FlashWord += (u16)*s++ << 8;         FLASHStatus = FLASH_ProgramHalfWord(FlashAddr, FlashWord);             if (FLASHStatus != FLASH_COMPLETE)                 printf(''FLSH : ?? Error %08X\r\n'',FLASHStatus);             FlashAddr += 2;         } I have other methods to program the flash too, and they all work without any issues. Check that the memory is erased, and check that the half word you want to write is blank (ie 0xFFFF). Also check the error/status value returned.

-Clive

[daviddavid942]

Posted on May 17, 2011 at 13:40

Hi,

the answer is YES. Off course I'm not using your value, I'm using other meaningful values. The flash memory is correctly initialized by the linker and the loader, because when the program starts I can see correct values with the debugger memory window.

[daviddavid942]

Posted on May 17, 2011 at 13:40

Hi Clive1,

I'm not using ST bootloader, I wrote my own because we have a Company custom bootloading protocol. Anyway, BOTH bootloader and Firmware run at 48MHz. I did some experiments: the problem seems to be related to some heap corruption. I was using many Singletons (so many new in program first steps...) and I tried converting them to global instances. Problem solved! I went back to singleton architecture and increase (a lot!) the heap size into ''startup_stm32f10x_md.s'' file but the problem was still there. I'm pretty sure the heap is big enough to contain all singleton instances and their members... I must say that I'm aso using Keil RL-RTX kernel/scheduler, so maybe the problem is in some heap interaction between my fw and the os (the singleton static members also were not correctly initialized by the loader... I had to write my own static initializer... maybe this was a sympton of somethig strange going on....) The strange thing is that Flash writing is the only part of the fw that goes wrong, all other parts wotks fine (and there are many heavy and call-deep tasks, even if I don't have full code-coverage test yet....) I'm marking the problem as solved for now, and maybe ask Keil some questions. Thank you

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

The bootloader was thrown in as a known working example, along with the other ST examples for the flash.

I can't speak to the RTX, but a lot of the Keil/ST examples have woefully small stacks. To the point where importing sscanf() and using it causes the stack to descend into the heap and wrecking havoc. Other people have had problems with large local allocations blowing out the stack. I tend to instrument the stack to confirm the maximal size periodically. You can also park the JTAG memory window over the bottom of the stack, heap or static allocations and watch the mayhem. If you suspect variables are getting trashed, instrument the code with printf()s and sanity check values, or place guard markers around critical structures and check them to. Other issues that could cause the flash to stop would be other code (or re-entrant behaviour) writing to the flash controller's lock or other registers, or interrupts corrupting registers. In a multithreaded system you probably need a lock/semaphore/mutex to serialize use of the flash controller. Also be aware that using the flash controller significantly increases interrupt latency. -Clive