STM Flash Erase Crash

marknorman9 · ‎2009-05-28

Posted on May 28, 2009 at 09:21

marknorman9 · ‎2011-05-17

Posted on May 17, 2011 at 13:13

This is a question to anyone who is expert in IAP programming.

I am experimenting with relocating code on a Keil MCBSTM32 board.

I have taken the ''measure'' example and have modified it so that through the menu system I can make a copy of it into the second part of the Flash starting at 0x8010000.

During the copy I modify the IVT so that they all point into the relocated code. Then I can jump into the the modified image resetting the IVT offset to the new position as I go.

This looks good as everything seems to run okay and it can report that its start address and main address is where I expect it to be.

Now here is where it goes wrong. I try to erase the original image ( from the new running image ) and it all locks up. Also if I start again and switch to the new image and back to the old one, the old image can not erase the new one. It can do this if I do not do the jump in and out again.

It locks up during the erase sequence during the Control register is set to STRT. e.g.

FLASH->CR|= CR_PER_Set;

FLASH->AR = Page_Address;

FLASH->CR|= CR_STRT_Set; <--- locks here

I have checked that the CR has not got the lock bit set and also done unlocks before hand just in case.

At the moment I can think of two reasons why this may be.

1) There is still code ( maybe interupts ) running in those pages and the FPEC dies.

2) The FPEC thinks there is still code running in there and dies.

Any one got any ideas, it does not matter how off the wall they are. I'm stuck.

marknorman9 · ‎2011-05-17

Posted on May 17, 2011 at 13:13

Ah ha

I've made a break through, but still not out of the woods. I'm re-running the application by jumping into the relocated main(). However if I just jump into the un-relocated main I get the same problem with erasing any page. So it must be something to do with either it not liking being re-initialised or maybe staking the while loop with-in another while loop in the same thread. I'll try disabling the initialises on re-entry and see if that helps.

pswenson · ‎2011-05-17

Posted on May 17, 2011 at 13:13

I'm no expert, but can you debug it and see where you're hung? Are you being dropped into a fault handler? Try disabling Prefetch?

marknorman9 · ‎2011-05-17

Posted on May 17, 2011 at 13:13

I can debug if I go in to the relocated imageand then come out again so that the debugger realigns. There does not appear to be a hardware exception but what I do notice is that if it fails the FLASH_SR has 0x03 instead of the normal 0x20. According to the Flash Programming Manual bit 0 set means busy and bit 1 is reserved, although later on in the manual it gives a name of ERLYBSY (page 27) in the map to that bit. Does this mean early busy??? It is looking like the PFEC locks the whole processor but I'm still scratching my head to why. Thanks for your suggestion I will try it, wondering if I could try different latencies too.

marknorman9 · ‎2011-05-17

Posted on May 17, 2011 at 13:13

All solved

Crash was down to stdio needing to be remapped to new zone. I have done this in a pretty brutal way when the image copy is being done where any 0x0800 half words are changed to 0x0801. This is pretty dangerous but at least it proves the relocation concept. I will resolve the exact address remapping later. Thank's for looking.