RM doc request: Please add a note to WWDG + Option byte programming

[flyer31]

Posted on March 25, 2013 at 17:36

Hi, after I finally got my option byte programming running nicely (STM32F4).

Just now I recognized that this collides with the WWDG being active (WWDG max time is 69msec, but option byte programming requires a 16kB erase cycle, which needs 300-500msec). So if I work with WWDG (which for God sake cannot be stopped by software...), my only possibility is to program the option byte before starting the WWDG. It is a bit annoying to recognize this only after all programming is completed ... . Could you please add the following Notes/Warnings in the STM32F4 reference manual: Note: The maximumg timeout time of WWDG is 69msec. Therefore it is not possible to performe any flash erase / option byte programming, after the WWDG has been activated! Please perhaps at the following 3 positions: - In WWDG-Chapter, perhaps 19.2. - In 3.5, perhaps after ''... not guaranteed if a device reset occurs during a Flash memory operation.'': - In 3.6.2

[Tesla DeLorean]

Posted on March 25, 2013 at 18:02

Note: The maximum timeout time of WWDG is 69msec. Therefore it is not possible to performe any flash erase / option byte programming, after the WWDG has been activated!

Can you not do it from RAM? Reading from the flash array while it is busy writing/erasing breaks real time responsiveness of the system in many conditions beyond just watchdog timers.

[flyer31]

Posted on March 25, 2013 at 19:48

This is an interesting idea ... .

Is it easy to do it from RAM? (Until now all my software runs from Flash). Is it straight forward to switch between RAM operation and Flash operation? After the Flash programming, usually I would prefer to switch back to Flash - somehow the software operating from Flash sounds more secure to me. Is there any example software, how to switch from Flash to RAM and back? Or some application note?

[Tesla DeLorean]

Posted on March 25, 2013 at 21:59

You basically copy your routines to an area of RAM you control, and then call the routines there. Pretty straight forward to do in assembler, gets more fun in C as you'll want to understand what the compiler and linker generate. Figure though you can memcpy() a routine, and jump via a function pointer.

I'm not sure there's a data sheet or app note about it, but it's a technique that's been used for decades because you can't run/program NOR flash at the same time. You either create the code to run at a specific address, or make it agnostic (ie PC relative). You have to move the interrupts and vectors into RAM too because any touching of flash will stall the CPU. What you copy must be self contained, calling flash based library code or routines will also stall the CPU. The 2MB version of the STM32F4 has two flash banks, this should permit execution from one while the other is busy, I haven't looked at the options bytes. Does it make the system more vulnerable, well yes, I'm not sure you can write protect the RAM, but you're also vulnerable if the CPU goes out to lunch for 100's or 1000's of milliseconds, or erasing chunks of flash. Do it with the watchdog turned off, reset the CPU if you have too. Pick your battles, quantify the risks, understand your limitations.

[flyer31]

Posted on March 26, 2013 at 11:24

Hi Clive,

thanks for the detailed description. As the option byte will be programm mainly only once for each PCB, it is no restriction for me to do this after a software-reset, before new activation of the WWDG. So I will keep with this solution, I am happy with it. I think that the program running from RAM will get quite challenging - this might be useful for bootloader software or so, but for me now this sounds a bit too much.