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.

MSP430F5252: Jump from No RTOS bootloader to TI RTOS Application

Part Number: MSP430F5252

Hello,

I am currently working on a bootloader (not running TI RTOS) to update my main application and then jump to this application with TI RTOS.

My bootloader remaps the interrupt vector to the proxy vector of my application :

- it "copies" the value between 0xFF80 to 0xFFFE of the application inside a proxy vector located between 0xB000 and 0xB07E.

- it sets the values between 0xFF80 and 0xFFFC to the addresses of my proxy vector (i.e. 0xB000 to 0xB07C)

- it jumps to the main application by calling :

(*((void (*)(void))(*(uint16_t *)0xB07E)))();

Which is the reset vector in the proxy interrupt vector for my application.

It seems to jump correctly to the start of my application (0xB200 which is the value in the reset vector of my application) but it is not running correctly...

When I run the application without the bootloader, the main is at 0x19FD0 and not 0xB200, how can I get my jump to start my application ?

  • Hello Clement,

    Thanks for posting your question. We will look into it and get back to you ASAP.

    Thanks,

    Yiding

  • Hi Yiding,

    I managed to successfully run my application with the jump but for that I had to put the interrupt vector of my application inside the actual interrupt vector.

    Maybe I'm doing the remapping wrong. What should I do exactly to remap the interrupt to the proxy when my app is running ?

    Thanks for your help !

    Clement

  • Any update on that matter ?

    Thank you !

    Clement

  • Hello Clement,

    For TI BSL which is located in info memory, the address shall be 0x1000.

    It is described in the UG: http://www.ti.com/lit/ug/slau319ab/slau319ab.pdf section 1.3.2.

    And also make sure to disable the interrupt before executing the BSL.

    Thanks,

    Yiding

  • Hello Yiding,

    I am talking about a bootloader in the main memory, not in the BSL part.

    The thing is when I compile my application, I get an interrupt vector from 0xFF80 to 0xFFFE, which is normal.

    I would like to relocate it to the address 0xB000 to 0xB07E as a proxy, because I will have a bootloader. What I don't understand is :

    How can I "give" the interrupt to my application through the proxy vector ?

    Thanks for your help !

    Clement

  • Hi Clement,

     

    • First, let me mention that the MSP430F5252 has an option to redirect interrupt vectors to RAM when SYSCTL.SYSRIVECT=1.

    In this scenario, the "default" vectors will always be in 0xFF80-0xFFFE after reset, but then you can either copy these vectors to RAM, or you can copy totally different vectors (i.e. corresponding to your application). After copying the vectors, set SYSCTL.SYSRIVECT and you won't need to do vector redirection in Software.

     

    In here, the proxy table is comprised of "BRA" instructions.

    - As you know, the original vector contains only 2 bytes with the address of the ISR.

    I.e. if your ISR for ADC10 is in 0xC000, then the vector 0xFFEC will have 0xC000.

    - But when using a Proxy table, your vectors would contain the address of each entry in the proxy table.

    I.e. if your proxy is in 0xF000 and the proxy vector for ADC10 is in 0xF020, then 0xFFEC will contain 0xF020

    - Now, the proxy table can’t just have the address of the ISR because that won’t be a valid instruction to be executed by the CPU. That is why you need a “BRA” instruction

                I.e. The vector (0xFFEC) will contain the proxy address (0xF020), and the proxy address will contain a BRA to ISR (BRA to 0xC000).

     

    • You might be using a different approach and that is OK, however, your approach is not completely clear to me. 

    I don’t exactly know what are the contents of 0xB200 in your application, but it’s important to note that if you are using C, the compiler is most likely going to jump to an initialization routine before jumping to main(). If you check your linker file, you might notice an entry for 0xB200.

    From what I understand, you have the following:

    -          0xB200 (init routine)

    -          0x19FBD0 (main)

    -          0xFFFE = 0xB200

    -          0xB07E = 0xB200

    Your instruction to jump to the contents of 0xB07E seems valid; however, I can’t really explain why the device would not work correctly after you force a jump to 0xB200.

    My suggestion would be to run it step-by-step with the debugger. If the device is resetting, make sure the Watchdog is disabled and check the source of the reset (SYSRSTIV). If the device jumps to 0xB200 but it doesn’t seem to have valid instructions, then there is be something wrong because your reset vector can’t have this value.

  • Hello Luis,

    Thanks for your answer. How do I put a BRA to ISR in the proxy vector ? That is what I can't get my head around...

    Luis RC said:

    - Now, the proxy table can’t just have the address of the ISR because that won’t be a valid instruction to be executed by the CPU. That is why you need a “BRA” instruction

                I.e. The vector (0xFFEC) will contain the proxy address (0xF020), and the proxy address will contain a BRA to ISR (BRA to 0xC000).

    How exactly am I supposed to do so ? Keep in mind that my bootloader will by used to update the application, so, when my bootloader read the new application, it will put the vector in the proxy when it sees that the address of the data is in the range of the vector (i.e. 0xFF80 to 0xFFFF)

    Thank you !

    Clément

  • Hi Clement,

    In regards to your question:

    Clement Guillou1 said:
    How do I put a BRA to ISR in the proxy vector ?

    The way this is done in MSPBoot is as follows:

    • The bootloader defines the vector table like this:
    /* Value written to unused vectors */
    #define UNUSED                  (0x3FFF)       
    /*! Macro used to calculate address of vector in Application Proxy Table */
    #define APP_PROXY_VECTOR(x)     ((uint16_t)&_Appl_Proxy_Vector_Start[x*2])   // <-- This defines the start of the "application proxy vector table"
    
    // This table must be placed in the interrupt vector location (0xFF80-0xFFFD)
    // Note that it doesn't include the reset vector since the reset vector points
    // to the start of the bootloader.
    const uint16_t Vector_Table[] =
    {
         UNUSED,                                     // FF80 = unused
    ... (more unused vectors)
         UNUSED,                                     // FFD0 = unused
         APP_PROXY_VECTOR(0),                        // FFD2 =  RTC         
    ... (more defined vectors)
         APP_PROXY_VECTOR(21),                        // FFFC =  SYSNMI      
    };

      • Note that it just fills "reserved" locations with a value. 0x3FFF is a "JMP $" which just traps the device.
      • The "valid" vectors are pointing to the corresponding addresses of the Proxy table (i.e. say 0xF000)
      • Reset is not included in the table because it will automatically point to the start of bootloader after building the code.
    • On the other hand, the application defines its vectors as follows:
    // This table should be placed starting at _Appl_Proxy_Vector_Start 
    const uint16_t ProxyVectorTable[] = { 0x4030, (uint16_t)Dummy_Isr, // APP_PROXY_VECTOR(0) RTC <-- First valid ISR for device. A Dummy ISR when not used by application ... (Other dummy or defined ISRs) 0x4030, (uint16_t)P1_Isr, // APP_PROXY_VECTOR(6) PORT1 <-- Used by application ... (Other dummy or defined ISRs) 0x4030, (uint16_t)Dummy_Isr, // APP_PROXY_VECTOR(21) SYSNMI <-- Last valid ISR (doesn't include Reset) };
      • The table should be placed in a known location (0xF000 based on our example)
      • Note that "0x4030" is the OpCode for a BRA instruction.
      • The "Application reset vector" should also be placed in a known location (i.e. after this table). The address of the reset vector can be adjusted in the linker file (i.e. just as an example 0xF1FE)
      • Note that the proxy table ignores all the "reserved" vectors and only starts on the vector defined as APP_PROXY_VECTOR(0)
    • MSPBoot always starts executing the bootloader. The bootloader decides if it should stay in bootloader mode or if it should jump to the application. If it needs to jump to the application, it simply grabs the reset vector from the known predefined address of "Application reset vector" (i.e. 0xF1FE based on the example above)

    There are other ways to do the proxy table. One option could be just to define Proxy ISRs with a fixed location and use them to jump to the actual ISR. This is less cryptic than using an OpCode.

    Regards,

    Luis R

  • Thank you Luis,

    I'll try that as soon as I can and I'll come back to you if I have any other question, if not, I'll put this thread as solved.

    Clement

  • Sounds good.

    Good luck :)

    LR

**Attention** This is a public forum