• State Not Answered
  • Locked Locked
  • Replies 28 replies
  • Subscribers 21 subscribers
  • Views 5886 views
  • Users 0 members are here
2025 survey

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.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

JUMP Problem when using RTX RTOS

LOST ISLAND

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 ?

Parents
  • 0 in reply to Tamiryan Michael

    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.

Reply
  • 0 in reply to Tamiryan Michael

    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.

Children
  • 0 in reply to ImPer Westermark

    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