• State
  • Locked Locked
  • Replies 1 reply
  • Subscribers 79 subscribers
  • Views 365 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Simpliciti based bootloader for ez430-RF2500

John Osen
Genius 3585 points


I am working with an ez430-RF2500 using CCS 5.3 and wish to update the program on the end device using the wireless link.  I.e. make the end device field servicable.

I have programmed multiple bootloaders for the LM4F chip, one family of bootloaders being wireless.  A bootloader is what I call a small program that gets a data stream over UART, CAN or wireless and reprograms a second program into another portion of memory, then jumps to it.  Basically the same as the MSP430's UART bootloader in ROM, which I have never used.

The memory layout of the MSP430 is different AND StellarisWare is not there to help you.  So I have a few questions:

1) Is there a MSP430 example of what I am trying to do?  I assume not, so if not...

2) In the linker command file, about the only user changable address range is for the segment usually called FLASH.  Correct?  (I have done it, moving the base from 0x800 to 0xC800)

3) Most importantly, the ISRs are at a fixed FLASH address range (FF.  Correct?  (The LM4F has the interrupt vectors figured out at the base address of the program.)

4) If so, then I have two programs that need to use the same ISR vectors.  Is the appropriate approach:

Use an alternative to the #pragma vector/__interrupt to define the interrupts for the bootloader.  Both the bootloader and target application need to load the last 32 bytes of memory at run time to get the interrupts correct.  This would be similar to writing my own version of StellarisWare's interrupt register routines.

5) Do users do this with the MSP430?  It seems while you are updating the ISR vectors, you could easily brick your processor, assuming both bootloader and app use ISRs.

6) Or is a better way just to make the bootloader a polled rather than ISR application?  (That would be ugly.)

Thanks for considering an involved question.

  • 0
    Guru 227245 points

    1) every MSP (except for the smaller G series parts and the L092) have a built-in bootstrap loader (BSL). You'll find lots of threads when searchign for BSL as keyword. On some MSPs (5x/6x family, but not all), the BSL can be replaced by a custom one. The Chronos watch has a wireless BSL. And its source should be available. As well as a demo BSL source for a timer UART.

    2) in the linker command file, you shouldn't change anything unless you exactly know what you're doing. Of course, changing the settings does not add flash to the MSP. :) But what you can do is to 'split' a segment into two, so you can put your BSL in one segment and the applciation into another. However, there are other things to change too. Inlcuding the fact that the linker will automatically include startup code for every C project - and tries to launch this at device start (through the reset vector). Which won't work well if you have two applications.

    3) ISRs may be anywhere below 64k. But the interrupt vectors that point to the ISRs are indeed located from 0xffff down. YOu may trick around this by using a double-jump table. Details are found in the mentioned threads.

    4) that's the problem. The double-jump allows you to point the 'real' vector to point to your BSLs ISR which will check by a flag whether the BSL is active or not and then forward to the applciations ISR. It requires that the applicaiton doesn't put its vectors directly into the vector table. Again, see the other threads.

    5) yes. Been there, done that. And with the double-jump, updating the vector table isn't necessary. The expense is that you add a few more clock cycles interrupt latency.

    6) that's what the original BSLs do, as they have to leave the whole applciaiton flash including vector table free for the application. BTW: the internal BSL mechanism implements calling a 'check if BSL needs to be executed' function after a POR and before calling the reset vector. Makign it totally independent of the main memory content.

**Attention** This is a public forum