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 ?
Erik,
I am sorry, I still don't understand. If there is a supply failure at any point, then either my program ends up in the brown-out detection interrupt, or the program does not start because the processor supply was cut off. If the program counter ended up in an arbitrary place thanks to the supply issue (no brownout detection, say) they it does not really matter anymore - not? I fail to see how I can end up with a partially configured vector table and a functioning program, or maybe I missed something?
I think Erik assumed that the NVIC call did flash the interrupt vector table, i.e. that the processor only supported a single fixed-location vector table. This is common for many 8051 chips, where the boot loader must be "proxy" for any application ISR.
But since newer processors with support for boot-loader operation, allows a remapping of the interrupt vector table, the flash will contain more than one vector table (both for boot loader and for application). So either the boot loader performs a remapping of memory just before handing over to the application. Or the application startup file performs the remapping.
With a processor that supports remapping of the interrupt vector table, a power failure will just remap back to the boot loader interrupt vector table for next restart. A brownout interrupt will be caught by the application brownout handler (if so configured), letting the application save any state before the voltage gets too low.
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.