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.

MSP430G2955: Custom Bootloader Interrupt Vector Table data getting overwritten

Part Number: MSP430G2955
Other Parts Discussed in Thread: UNIFLASH

Hello,

I'm working on a custom bootloader code for MSP430G2955.

After writing the source code, I observed that the data at the locations of INT00 to RESET (0xFFE0 to 0xFFFF) was different from the values I provided. The FLASH section contains the correct data. I used similar write statements for the entire source file.

I'd like to know if we need to write into these locations while bootloading. If yes, then do they need any additional statements.

I'm using the document SLAA600D and the source  code provided in it's link as a reference and couldn't find any of the above.

Thanks

Srikrishna

  • Hi Srikrishna,

    Ling

  • Hello Ling,

    Thank you for responding. But the file doesn't help resolve my issue. Please, let me be more specific.

    I'm using an Motorola M-2 type S-record as a source file. The below hex is a code for blinking an LED.

    I'm ignoring the S0 record as it provides no destination address.

    S00600004844521B

    I'm writing the below S2 records into the mentioned destination address. No issues here.
    S2220031002183B240805A2001C2432900D2D32A00D2E32900B140102700008193000004
    S22200311EF8279183000081930000F327FA3F31400021B0124E310C43B01200311C4380
    S21A00313CB012483132D01000FD3F03430343FF3F03431C4330410F

    The below S2 records have the mentioned address as 0xFFDE to 0xFFFF which according to the file is the interrupt vector table. This data was observed to be corrupted when checked later using Uniflash - Memory. Also, when these addresses are written to, I think the program gets stuck in some indeterminate state & doesn't proceed as expected. When these records are ignored, the bootload function is performed successfully, but the application doesn't behave as expected. (In this case, LED is solid instead of blinking, which could be a case of the pin being in indeterminate state).
    S20600FFDEFFFF1E
    S20600FFE04031A9
    S20600FFE24031A7
    S20600FFE44031A5
    S20600FFE64031A3
    S20600FFE84031A1
    S20600FFEA40319F
    S20600FFEC40319D
    S20600FFEE40319B
    S20600FFF0403199
    S20600FFF2403197
    S20600FFF4403195
    S20600FFF6403193
    S20600FFF8403191
    S20600FFFA40318F
    S20600FFFC40318D
    S20600FFFE2C319F

    I'm calling the code jump function using the address provided in th below S8 record.
    S80400312C9E

    I need to know where the mistake is.

     

    Thanks and regards

    Srikrishna

  • Hi 

    First in the demo of SLAA600D, the host side just can hand the .c file that is converted from .txt file. The .txt file can be generate by CCS or IAR. Which software do you use?

    For the interrupt table in the target device should be the same you can see we define the values in the vector table in the file named "TI_MSPBoot_VecRed_G2553_Boot.c" which is in the boot side project. The value in the vector table (From 0xFFE0- 0xFFFF) should be 

    @ffe0
    C2 FB FF 3F C6 FB CA FB FF 3F CE FB D2 FB D6 FB
    DA FB DE FB E2 FB E6 FB EA FB EE FB F2 FB B6 FF

    Because the APP_PROXY_VECTOR array's address is defined in the cmd file as 0xFBC2

    So the interrupt will jump to the array of APP_PROXY_VECTOR which's value is defined in the application's code like this

    const uint16_t ProxyVectorTable[] =
    {
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(0) TRAPINT
    0x4030, (uint16_t) P1_Isr, // APP_PROXY_VECTOR(1) PORT1
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(2) PORT2
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(3) ADC10
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(4) USCIAB0TX
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(5) USCIAB0RX
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(6) TIMER0_A1
    0x4030, (uint16_t) Timer_A, // APP_PROXY_VECTOR(7) TIMER0_A0
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(8) WDT
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(9) COMPARATORA
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(10) TIMER1_A1
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(11) TIMER1_A0
    0x4030, (uint16_t) Dummy_Isr, // APP_PROXY_VECTOR(12) NMI
    };

    Best regards

    Gary

  • Hi,

    I'm using CCS version 8.3.

    So, is it necessary to have separate interrupt tables for the application and bootloader codes, by defining them in the .cmd file?

    Thanks

    Srikrishna

  • Hi 

    Yes, for the boot code just use the reset vector 0xFFFE, the other interrupt vector is used by application. We organize this by .cmd file.

    Best regards

    Gary

  • Hi Gary,

    Thank you, this resolved my issue.

    However, if there is a need to use any isr's in the bootload program, do we enable the respective vectors? And can they be reused for the Application program?

    Thanks

    Srikrishna

  • Hi Srikrishna

    I have not try this. But that seems workable. 

    We do have some shared functions that can be used by boot code and application code.Like the codes in file TI_MSPBoot_CI_PHYDL_I2C_Slave_x2xx.c 

    const uint16_t Boot2App_Vector_Table[] =
    {
    (uint16_t) &TI_MSPBoot_CI_PHYDL_Init, /*! Initialization routine */
    (uint16_t) &TI_MSPBoot_CI_PHYDL_Poll, /*! Poll routine */
    };

    The function "TI_MSPBoot_CI_PHYDL_Init" and "TI_MSPBoot_CI_PHYDL_Poll" can be used by boot code and application code.

    You can see the application code of App2 in our demo code have used this feature.

    Best regards

    Gary

**Attention** This is a public forum