calling boot/flash loader from user code

[john]

Posted on March 28, 2008 at 11:28

calling boot/flash loader from user code

[john]

Posted on May 17, 2011 at 12:27> the problem is of course that ST might change the loader anytime (and apparently they have, AFAI can remember). if you depend on their code instead of making you own loader you'll always be exposed to changes. It's only for a short term in-house solution, so I'm not too worried about that. I am writing our own flash upgrade code... You seam to be quite friendly with STOne-32 - please can you let him (?) know that for us developers, it is useful to be able to manually call their flashloader. I don't mind if it changes in its operation, just as long as it is still available for us to use. ie. please don't add anything in there that would FORCE us to have to set the boot pins correctly. Once our device is inside its production plastics, it's not easy to get at the boot pins... The built-in flashloader just gives us that safety net level of having a failsafe (I assume their code is quite robust), just in case our flash loader fails at some point... so we may well leave this option in our production code, as its not really any code overhead in terms of size. > here's what I'd do instead of emulating a reset: after reset I'd check the reset source and if it's software then I'd invoke the loader by setting PC and SP as per your assembly code. > (I'd do a real reset instead of emulating one because I'd feel safer, not because it's needed of course.) That's a good idea ! Thanks, John.

[lanchon]

Posted on May 17, 2011 at 12:27

> the software reset comes back into the FLASH

tough luck, soft reset obviously resets VTOR. > I can't find a decent description of NVIC_SETFAULTMASK() what I meant was that you should set or clear all core flags as if a reset was done to be maximally compatible. for example, if you have the PRIMASK set, i guess you'd have to clear it before triggering the bootloader. it all depends on the state the core is at the time and how compatible you want to be. the problem is of course that ST might change the loader anytime (and apparently they have, AFAI can remember). if you depend on their code instead of making you own loader you'll always be exposed to changes. here's what I'd do instead of emulating a reset: after reset I'd check the reset source and if it's software then I'd invoke the loader by setting PC and SP as per your assembly code. if using c++ I'd do this in the startup code (which is assembler in my case), before constructors of static objects are run. (I'd do a real reset instead of emulating one because I'd feel safer, not because it's needed of course.)

[lanchon]

Posted on May 17, 2011 at 12:27

> friendly with STOne-32 - please can you let him know

only contact with her or him is via this forum. in fact if I could contact him some other way I'd be bugging him like crazy over a FOC library that I desperately need for yesterday. but I can understand why ST chose not to allow invocation of the loader: -they want the freedom to change the loader (say, make it usb) or remove it completely (which i find most logical, we'll see what happens when the new parts come out on Q2). -using the loader like you are is not robust, it requires a working flash image. what if the update process is interrupted? still think the BOOT pins are not a good idea? the right way to do it is to lock 4K of the flash and use it to hold a constant and debugged bootloader. the trigger (equivalent of the BOOT pins) is what's ideal for your application and the result is robust: -independent of ST code -can recover from a failed update -can verify the integrity of the rest of the flash before invoking the main program and potentially raising havoc and destruction. (think of a multikilowatt motor controller with a corrupted firmware...) that is not to say that ST should do nothing! in fact IMHO ST should provide a ready-made bootloader application (not a fragile example) that is compatible with sys mem loading (actually it'd be almost the same code) but with these added functions: -customizable the trigger -checking and launching of app if no trigger -checking by crc or optionally by shared-secret ''signing'' (hash of firmware plus secret) -customizable check-failed handler