JUMP Problem when using RTX RTOS

Not in privileged mode? Maybe you need to execute an SVC first.

Not in privileged mode? Maybe you need to execute an SVC first.

Thanks ,

RTX wasn’t in privileged mode so I checked it’s check box and now it’s in privileged mode .
Now when jumping to 0x10000 there is a hard fault again but it’s position has changed from the vector table of bootloader to the vector table of the application .
In fact this time the the bootloader has been able to remap the vector table but the hard fault persists like before .
How could I get rid of this hard fault ?

The best I can do is show you how one of my bootloaders jumps to another bootloader (analogous to your aplication):

void execute_user_code(void)
{
        // remap interrupt vectors
    NVIC_SetVectorTable(NVIC_VectTab_FLASH, MAIN_BOOT_FLASH_START);

    jump_to_application() ;
}

/* One major difference between an ARM7 device and a Cortex-M3 is the content of the vector table:
   when you jump to application in an ARM7, you can expect code inside the vector table, so you
   can jump to its beginning and know you are correct. The vector table of a Cortex-M3 needs to be
   dereferenced in order to retrieve the entry point to the application. */
__asm void jump_to_application(void)
{
    ; program stack pointer of main bootloader
    LDR     R0, =0x1000 ;=MAIN_BOOT_START
    LDR     SP, [R0]

    ; extract entry point into main bootloader
    LDR     R0, =0x1004 ;=MAIN_BOOT_START+4

    ; jump
    LDR     PC, [R0]
}

where

#define MAIN_BOOT_FLASH_START    0x1000

One thing here - you should really deactivate every single interrupt before you try to remap the interrupt vector table. How fun is it that you have given the interrupt vector controller actual pointers to ISR functions, when you then invalidate the right to make use of these functions...

But in response to:
"I can solve this problem by resetting the system but I need to jump from the application to the bootloader for reprogramming command again and the application program is in RTX OS too ."

The normal route is to just take a watchdog reset, and the boot loader will then check the state. Leave it a flag that tells the boot loader that you want to swap applications. Depending on your design, you either make use of a rather complicated flag in RAM (complicated to make sure that random RAM contents doesn't also look like your flag) or write the flag into flash or EEPROM so the boot loader even after a power off can see "current app is #1, wanted app is #2".

Just as Erik mentions - make sure that every step in the reprogramming sequence is allowed to fail at any stage from a power loss. The boot loader should be able to detect if there are valid firmware or not. It should be able to detect if it has only half-updated the device and either wait for the data again (if direct update through cable) or restart the programming in case you have a design with two memory regions to allow one app to run while next app gets downloaded.

Thanks my friends ,

Finally I used watchdog reset to get rid of this problem
At the first line of the bootloader I check one address of the flash .
If it is 0xFF then I go to the bootloader program and if is something else (0xAA) go to the application.
At the start of programming , the mentioned flash address is set to 0xFF .
if the bootloader has been able to completely program the application , at the final transmission , the mentioned flash address is set to 0xAA .

Thanks again

void execute_user_code(void)
{
        // remap interrupt vectors
    NVIC_SetVectorTable(NVIC_VectTab_FLASH, MAIN_BOOT_FLASH_START);

    jump_to_application() ;
}

if a power failure or similar event happens during this you are screwed

is in the start vector to have ONE bit/byte/word that directs the reset to app or boot. change the ONE bit/byte/word and reset the processor to switch

Erik

Erik,

Please explain what you mean exactly?

You don't know what you are doing. You write as if you know but what you write gives you away.

I am far better than you and I am not going to waste any more time with you.

Bighead Posted
I am far better than you

how fitting

Erik

PS I'd like to know who 'you' is, there are many posters in this thread.

Tamir,

the code you posted will work IF no power interruption happens while the snippet you posted is executing.

e.g.

void execute_user_code(void)
{
        // remap interrupt vectors
    NVIC_SetVectorTable(NVIC_VectTab_FLASH, MAIN_BOOT_FLASH_START);if power dies here you will have
//                                                                    the boot with some app vectors
//if power dies here you will have the boot with the app vectors
    jump_to_application() ;
}

if NVIC_SetVectorTable set the reset vector first, then

void execute_user_code(void)
{
        // remap interrupt vectors
    NVIC_SetVectorTable(NVIC_VectTab_FLASH, MAIN_BOOT_FLASH_START);if power dies here you will have
//                                                                    the app with some boot vectors
   jump_to_application() ;
}

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.