JUMP Problem when using RTX RTOS

OS or not shouldn't matter. A jump to address 0x10000 is just a jump. Basically every function call you make is also a jump (except that you then often want to return).

So maybe you aren't telling us everything. Like if this is a boot loader + application, where you want/need to redefine the interrupt vector table or reinitialize the stack or heap or something.

Please give some actual context to what that jump really represent for the software architecture of your program.

Certainly is. Don't enable it.

and why, having chosen to use an OS (RTX), you then want to disable it?

Describe your goal(s): www.catb.org/.../smart-questions.html

Thanks for your attention ,

It’s a bootloader + application program

As I said without enabling RTOS it’s working fine so I thought maybe before jumping to the application I must disable it .
I tried to disable SystemTick Timer so as to stop OS and it was useless .
I disabled all interrupts (Global Flag) but it was useless too .

About reinitializing stack I haven’t done anything but both bootloader and application programs have got startup.s where stack is set there.

Lost by nature and Lost by name.

Check that system setting is the same for bootloader and application. If not you may need to reinitialise system setting at the begining of the application.

Yes , both are the same

The document says :
“A hard fault is an exception that occurs because of an error during exception
processing, or because an exception cannot be managed by any other exception
mechanism “

This is my code :

__disable_irq();
SCB->VTOR = 0x10000;
user_code_entry = (void (*)(void))(0x00010000 | 0x00000001);
user_code_entry();

Exactly at the "SCB->VTOR = 0x10000" line the hard fault occurs .
Probably this means an exception has occurred while SCB->VTOR has changed .
Probably this exception is The SystemTick exception .
SO if I disable SystemTick exception the problem is solved . Isn’t this true ?
But the problem is __disable_irq() doesn’t have any effect on SystemTick apparently.

How could I handle this problem ?

Are your boot loader _really_ so advanced that it needs to run an RTOS?

If you do have very complicated code in the boot loader that you want to use RTOS, why not then have the boot loader decide if it should just boot an application (do that without use of RTX) or decide that the boot loader needs to do advanced communiaction.

You could then always perform download of a new application and when everything is completed you can force a watchdog reset, and then have the boot loader directly start the application.

But in reality, a boot loader using RTX sounds like a violation of the KISS principle.

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

Are your boot loader _really_ so advanced that it needs to run an RTOS?

RTOS has its place, but I have seen more cases of a RTOS used where it should not be, than cases where a RTOS was not used but should be.

also a very complicated bootloader is more likely to suffer from the one unexcusable bootloader fault: "If power fails at point x, the system is hung".

ANY bootloader that can not be restarted if interrupted by ANYTHING such as noise, power failure or whatever is a piece of crap. The criticl place, of course, is the transition from boot to app.

Erik

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 ?

Are your boot loader _really_ so advanced that it needs to run an RTOS?
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 .
So I need to jump again .
Apart from that the jump problem through RTX must be solved for my future projects .

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.