MSP430G2553: Jumping to program at specific flash location at runtime

Reiner Schmidt

Part Number: MSP430G2553

I am working on a small bootloader for the MSP430. I cannot use the BSL loader because of pin restrictions for the project.

Currently I am able to receive the firmware, write it to flash and verify it. I then use UNIFlasher to dump the flash afterwards and verify it again during development. All of this is working well.

I am stuck where I set the program counter to the new firmware location and hope that everything works. However It does not seem to work correctly. In fact my current program just resets. At first I thought it was an artifact of the debugging but even when using the firmware without the debugger attached I had the same issues. Here is how I jump to the program from software.

    __disable_interrupt();
    ((void (*)())0xCA20)();

I have tried a couple other things as well.

enable watchdog after setting the program counter
using assembly instructions directly (br and MOV), it compiles the same so don't think it will make a difference anyhow.

Normally I would just step my way through the assembly and figure it out, but in this case I think debugging is having an effect. Any help would be great!

over 2 years ago

0 Reiner Schmidt over 2 years ago

Prodigy 10 points

Some details I realized I missed in the main post

the bootloader itself is constrained to the correct flash size, in this case `FLASH: origin = 0xC000, length = 0x0A00`
the main program starts at the next address when loaded
if I load the bootloader into memory, then load firmware and set the program counter it just resets to my bootloader and the bootloader runs as if device was reset (this is the main bad behavior)
if I load the main program at its offset using UNIFlasher it runs correctly.

0 David Schultz over 2 years ago in reply to Reiner Schmidt

Guru 18885 points

Is 0xCA20 where the target code expects to start execution?

0 Reiner Schmidt over 2 years ago in reply to David Schultz

Prodigy 10 points

Yes, that's correct. I have tried making smaller programs and going deeper into the address space but its the same result. I guess there is potential for the program to not begin properly, the watchdog kicks in and resets back to the bootloader. hmmmm, I think this could be something.

Does the watchdog run even if something isn't being executed? Time to check the docs.

0 Johnson He over 2 years ago in reply to Reiner Schmidt

TI__Mastermind 28286 points

Hi Reiner,

Do you try to disable the WDT and using those two line code to enter Bootloader code?

Thanks!

Best Regards

Johnson

0 David Schultz over 2 years ago in reply to Reiner Schmidt

Guru 18885 points

The watchdog runs unless you stop it.

The hard coded jump address is a problem because the correct entry address could change. I suspect that you are reading the code from a .hex file in which case finding the reset vector value is easy. You need that value to start the target program now and you have to save it somewhere to use after the next reset.

0 Reiner Schmidt over 2 years ago in reply to David Schultz

Prodigy 10 points

David Schultz said:
The hard coded jump address is a problem because the correct entry address could change

This is interesting, I wasn't aware. The only curious thing about this is that other examples of bootloaders for the MSP430 I have seen all use the same method for setting the reset vector, and its just hardcoded. I think this pointed me in the right direction, taking a look at this thread I think I can muster up a solution.

(2) MSP430 reset vector - MSP low-power microcontroller forum - MSP low-power microcontrollers - TI E2E support forums

Yes the watchdog timer is always off for these tests. I don't want to go near it until I get this full sample working.

0 Johnson He over 2 years ago in reply to Reiner Schmidt

TI__Mastermind 28286 points

Hi Reiner,

Does your question is resolved? or need future support?

Thanks!

Best Regards

Johnson

**Attention** This is a public forum