Running code out of RAM after a full flash erase

ron2399 · ‎2016-06-13

Posted on June 13, 2016 at 23:54

I am using an STM32F415 as part of a USB dongle that generates and stores cryptographic keys. For the development version of the dongle I want to be able to switch back and forth between RDP levels 0 and 1, which I can do. The problem is that when I go from level 1 back to level 0 the chip does a full flash erase, which nukes the firmware, and so the device appears to hang. I would like to make the device's behavior a little more user-friendly by providing some feedback that the mass erase has completed. Theoretically this should be possible by running the code that initiates the flash erase out of RAM. My question is: will this actually work? Has anyone ever done this before? Is there some model code out there that I can use or am I charting new territory here?

AvaTar · ‎2016-06-13

Posted on June 14, 2016 at 07:39

> My question is: will this actually work? Has anyone ever done this before?

Using IAR WB, this is directly supported with the compiler specific keyword ''__ramfunc'' there. The toolchain also does the non-trivial arrangements of loading this function(s) to RAM at startup, and routing the calls correctly.

I use it to erase and program the Flash (in a secor-by-sector fashion, on a Cypress MCU).

Not sure how it works with other toolchains, but it's not ''charting new territory''.

ron2399 · ‎2016-06-15

Posted on June 15, 2016 at 19:09

Thanks, AvaTar! ramfunc turned out to be the keyword I needed.

Unfortunately, it turns out that this won't actually work because transitioning from RDP1 to RDP0 also erases the user RAM.

Which raises a related question: is it even possible to provide feedback as to when a full flash erase has completed? If not, how long does it it take? Because I've discovered the hard way that if you stop a full flash erase in the middle, it disables DFU mode and you can no longer (AFAICT) reprogram the chip.

Tesla DeLorean · ‎2016-06-15

Posted on June 15, 2016 at 19:40

Most people working on these things tend to be working for corporate masters, and really unlikely to share secrets freely.

Don't think I've ever totally bricked a part like this, on occasion I've gotten pretty close, but can generally walk the part out via the System Loader on the USART

Not aware that it Nukes RAM, do you have a specific cite for that?

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

ron2399 · ‎2016-06-27

Posted on June 28, 2016 at 08:25

> Not aware that it Nukes RAM, do you have a specific cite for that?

Turns out I was wrong about that. The RAM remains intact. (But it's still very challenging to maintain a running system because you have to make sure everything -- including the interrupt table, all library routines, and all static data you need to proceed -- is in RAM. That's not so easy to arrange.)

AvaTar · ‎2016-06-28

Posted on June 28, 2016 at 10:49

The code I worked on is simpler in this regard, because it does not support overwriting itself. That means, only the routines directly involved in flashing reside in RAM.

For the 'bricked' board, I'm sure clive1 is right. The system loader mode does not require any ''proper'' Flash code, so it should always work.