We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hi all ,
Using Uvision4 & LPC1768 & RTX RTOS , I want to jump to 0x10000 of the flash. Before running RTX , there is no problem but after using os_sys_init(APP_TaskStart) , when trying to jump , there is a hardfault . How could I jump while RTX is running ?
By the way , Is there a way to disable RTX ?
the boot loader performs a remapping of memory just before handing over to the application. what if an "unusual event" happens between the remapping and the hand-over.
a power failure will just remap back to the boot loader interrupt vector table for next restart I merely used a power failure as an example of an "unusual/unexpected event" such as the bootcable being unplugged, noise, ....
whatever the issues in this thread, I have just seen way too many boot/app switches that were prone to lock up if "unusual/unexpected events" happened. As a matter of fact I caught one in a Cortex-M3 deaign recently. This month (and maybe next) I am not doing ARM and thus do not have the specifics.
Erik
"what if an "unusual event" happens between the remapping and the hand-over."
Nothing happens. The boot loader don't need any interrupts when it is handing over to the application so it can turn off all interrupts, remap the interrupt vector table, and then call the application. And a boot loader that don't do tricks but requires a watchdog restart to activate an application can check flags/md5/crc/... and decide to start the application without even touching any interrupts. Only when the boot loader sees a need to transfer data can it turn on interrupts - and after transfer is done, it can do a watchdog reset before activating.
Any application that makes use of interrupts should start by setting the interrupt vector for the peripherial before it enables that interrupt - but that is the standard requirement anyway.
Anyway - any program that must not lock up should make use of a watchdog. So the boot loader should consider starting the watchdog (if the watchdog can just have a period time long enough that it's safe to initialize memory + RTL without a reset) before starting the application - andy fail then results in a reset and a new attempt at starting the application.
Power glitches that makes the processor hang? Sure, that is a possibility. But isn't something that have with boot loader concepts to do. You either have an external or internal watchdog that auto-starts. Or you just have to live with that time window from reset until the boot loader or application explicitly turns on the watchdog. No source code can change that.
But isn't something that have with boot loader concepts to do Problems with the bootloader itself are just plain bad coding, problems with the hand-off can be oversights.