MSP430F67691A: Issue with Interrupts When Jumping from Bootloader to Application on MSP430F67691A

Part Number: MSP430F67691A

Tool/software:

Dear Texas Instruments Support Team,

I am currently implementing a bootloader for the MSP430F67691A and have encountered an issue where interrupts are not functioning correctly after jumping from the bootloader to the application.

Issue Details:

  • The bootloader successfully loads and jumps to the application.
  • After the jump, the application runs, but interrupts do not seem to trigger as expected.
  • The application vector table is correctly placed at 0xFF80 - 0xFFFF, and the reset vector at 0xFFFE points to the application entry point.
  • I have disabled global interrupts before the jump and re-enabled them in the application, but the issue persists.

I use proxy vector table in application also interrupts are not generated ,so I attached my both application and boot cmd file can you check the memory allocation is correct or not.

Does the bootloader need to explicitly reconfigure the vector table after jumping to the application?

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*application code cmd file*/
/* ============================================================================ */
/* Copyright (c) 2020, Texas Instruments Incorporated */
/* All rights reserved. */
/* */
/* Redistribution and use in source and binary forms, with or without */
/* modification, are permitted provided that the following conditions */
/* are met: */
/* */
/* * Redistributions of source code must retain the above copyright */
/* notice, this list of conditions and the following disclaimer. */
/* */
/* * Redistributions in binary form must reproduce the above copyright */
/* notice, this list of conditions and the following disclaimer in the */
/* documentation and/or other materials provided with the distribution. */
/* */
/* * Neither the name of Texas Instruments Incorporated nor the names of */
/* its contributors may be used to endorse or promote products derived */
/* from this software without specific prior written permission. */
/* */
/* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

             

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/*bootcode cmd file*/
/******************************************************************************/
/* LINKER COMMAND FILE FOR MSPBoot BOOTLOADER USING msp430f67691A */
/* File generated with MSPBoot_linkergen_Flash.pl on 24-02-2025 */
/*----------------------------------------------------------------------------*/
/****************************************************************************/
/* SPECIFY THE SYSTEM MEMORY MAP */
/****************************************************************************/
/* The following definitions can be changed to customize the memory map for a different device
* or other adjustments
* Note that the changes should match the definitions used in MEMORY and SECTIONS
*
*/
/* RAM Memory Addresses */
__RAM_Start = 0x1C00; /* RAM Start */
__RAM_End = 0x9BFF; /* RAM End */
/* RAM shared between App and Bootloader, must be reserved */
PassWd = 0x1C00; /* Password sent by App to force boot mode */
StatCtrl = 0x1C02; /* Status and Control byte used by Comm */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Any guidance on best practices for handling interrupts during the bootloader-to-application transition would be greatly appreciated.

Thank you for your time and support.

Ankush

  • This device has the ability to locate the interrupt vectors at an alternate location. Which is at the top of RAM.

    That space must be reserved so that the initial stack pointer is placed below it. You still have __RAM_End = 0x9bff so the stack would trash the vectors.

    Something, bootloader, application, must copy the vectors from where they are in flash to their correct location in RAM. Then enable the alternate vector table (SYSRIVECT) , and finally enable interrupts.

    The reset vector is always 0xfffe.

  • HI David,

            I tried this process but not working .so can you please provide any example for this alternate vector table. below I attached code what I done for alternate

    vector table can please check this is correct or not.

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    #define RAM_VECTOR_TABLE_ADDR (0x1C00) // Top of RAM for MSP430F67691A
    #define FLASH_VECTOR_TABLE_ADDR (0xFF80) // Start of the flash interrupt vector table
    #define TIMER0_A0_VECTOR (0xFFEE)
    // Function prototypes
    void init_ram_vector_table(void);
    void TIMER0_A0_ISR(void);
    void main(void) {
    WDTCTL = WDTPW | WDTHOLD; // Stop watchdog timer
    init_ram_vector_table(); // Initialize the RAM vector table
    SYSCTL |= SYSRIVECT; // Enable RAM-based interrupt vector table
    TA0CCTL0 = CCIE ; /* Timer interrupt enabled*/
    TA0CCR0 = 16000 ; /* compare the clock frequency with the number of counts giving an interrupt every milisecond*/
    TA0CTL = TASSEL__SMCLK + MC_2 + TACLR ; /* TBSSEL_1 + MC_1 + TBCLR;Timer source is ACLK, Timer in upmode (counts up to TBCL0), clear TBR*/
    }
    __enable_interrupt(); // Enable global interrupts
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Thank you,

    Ankush

  • Hi,

    You will need to set the interrupt vector in the application code. Please refer to this app note for 'Use RAM-based interrupt vector instead of FRAM-based interrupt vector. And you can also download the example code in the note.

    https://www.ti.com/lit/an/slaa968/slaa968.pdf

    Best regards,

    Cash Hao

  • Just off the top of my head, this code copies the boot loader vectors to the start of RAM. Useless.

**Attention** This is a public forum