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.

CCS/MSP430F169: Debugging with custom linker command file

Part Number: MSP430F169
Other Parts Discussed in Thread: MSP430FR4133

Tool/software: Code Composer Studio

Hi,

The application I am writing uses a custom linker command file that moves the reset and interrupt vector to 0xD7E0 since I have a custom bootloader that will occupy the bottom of flash. When I attempt to debug my application it cannot find the main symbol. It appears to jump to 0xFFFE for the reset vector by default and I cannot find how to change this. How can I tell the debugger to jump to my custom reset vector (which resides at 0xD7FE)? Note that I'm using CCS v5.5.

Thanks,

Dan Closson

  • Hi, Dan, 

    As I know, Reset vector and interrupt vector cannot be modified because it is hardware designed. You can just modify the content in the reset vector address 0xFFFE, i.e. start address of your code. From this address, you can start your bootloader. 

    Thanks, 

    Lixin 

  • Thanks for your response Lixin. I have been remapping the reset and interrupt vectors for ages and as far as I understand can be done by simply editing the linker command file and specifying the vector address locations in flash memory.

    I have two programs, a bootloader that has the reset vector at 0xFFFE (program resides at 0xD800 to 0xFFFF) and my application program with the reset vector at 0xDFFE (program resides at 0x1100 to 0xDFFF). I can run and debug my bootloader program normally. However, I cannot run and debug my application program when the reset vector has been remapped to 0xDFFE. As a workaround I've been changing the linker command file to place the reset vector at 0xFFFE when I'm debugging and then when I release the program I set the reset vector to 0xDFFE and program it along with the bootloader (everything works fine). My question is if there is a mechanism that will allow me to debug my application program with reset vector at 0xDFFE?

    Thanks,

    Dan

  • Hi, Dan, 

    I tried to change the reset vector in the linker file on MSP430FR4133 target board (I have no the F169 board in hand now but I think it should be same operation theory for this issue debug). But I could not pass the linking and the .out file was not built. 

    Error message: 

    error #10010: errors encountered during linking; "Reset_vector_change.out" not built

    "../lnk_msp430fr4133.cmd", line 123: error #10264: RESET memory range overlaps existing memory range FRAM

    What I changed is the file "lnk_msp430fr4133.cmd", and made following change for the reset vector: 

    "RESET                   : origin = 0xFFFE, length = 0x0002"  ->  "RESET                   : origin = 0xDFFE, length = 0x0002"

    It is confirmed the 0xDFFE is the valid memory in MSP430FR4133 which code memory is 0xC400 ~ 0xFFFF. 

    Could you share how you changed the linker file and passed the linking to build the .out file? 

    Thanks, 

    Lixin 

  • In addition, my test code is very simple - it is the "msp430fr413x_1.c" in MSP430FR4133 code examples

  • Hi, Dan, 

    I don't think there is a mechanism that will allow you to debug your application program with reset vector at 0xDFFE. 

    Since the bootloader has the reset vector at 0xFFFE, I think you can jump to your application code in the bootloader. Then you can debug your application code. 

    Thanks, 

    Lixin  

  • Hi, Dan, 

    I successfully built the code with changing the reset vector: changed the reset vector to 0xDFFE and also changed the FRAM section length

    • FRAM                    : origin = 0xC400, length = 0x1B80

    But the code could not run as normal after programming into the MCU. It could not also think it is because the MCU hardware doesn't think the 0xDFFE is a valid reset vector. 

    Could you share your experience how to do like you mentioned above ? "I have been remapping the reset and interrupt vectors for ages and as far as I understand can be done by simply editing the linker command file and specifying the vector address locations in flash memory."

    Thanks, 

    Lixin 

  • Hi Lixin,

    I'm attaching two linker command files. One I use for the bootloader that has FLASH mapped to 0xD800 with length of 0x27E0. The RESET vector is at 0xFFFE (the expected location) so I can debug the bootloader. The 2nd file is the linker command file for the application. It has the FLASH mapped to 0x1100 with length 0xC6E0. The RESET vector is at 0xD7FE. If there is no firmware update then the bootloader will jump to 0xD7FE and the main application will run. This works fine however, when I want to debug the main application I have to modify my linker command file to place the RESET vector at 0xFFFE or I cannot debug the application. This was the intended purpose for my original post was to see if the community new of a better way to debug an application with the reset vector remapped. I know this is possible with other ARM microcontrollers but doesn't seem possible with MSP430? I could be wrong.

    Thanks,

    Dan C.

  • I'm having trouble attaching the files so here is the section of interest.

    Bootloader Linker Command File

    /****************************************************************************/
    /* SPECIFY THE SYSTEM MEMORY MAP */
    /****************************************************************************/

    MEMORY
    {
    SFR : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
    RAM : origin = 0x0200, length = 0x0800
    INFOA : origin = 0x1080, length = 0x0080
    INFOB : origin = 0x1000, length = 0x0080
    FLASH : origin = 0xD800, length = 0x27E0
    INT00 : origin = 0xFFE0, length = 0x0002
    INT01 : origin = 0xFFE2, length = 0x0002
    INT02 : origin = 0xFFE4, length = 0x0002
    INT03 : origin = 0xFFE6, length = 0x0002
    INT04 : origin = 0xFFE8, length = 0x0002
    INT05 : origin = 0xFFEA, length = 0x0002
    INT06 : origin = 0xFFEC, length = 0x0002
    INT07 : origin = 0xFFEE, length = 0x0002
    INT08 : origin = 0xFFF0, length = 0x0002
    INT09 : origin = 0xFFF2, length = 0x0002
    INT10 : origin = 0xFFF4, length = 0x0002
    INT11 : origin = 0xFFF6, length = 0x0002
    INT12 : origin = 0xFFF8, length = 0x0002
    INT13 : origin = 0xFFFA, length = 0x0002
    INT14 : origin = 0xFFFC, length = 0x0002
    RESET : origin = 0xFFFE, length = 0x0002
    }

    Main Application Linker Command File

    /****************************************************************************/
    /* SPECIFY THE SYSTEM MEMORY MAP */
    /****************************************************************************/

    MEMORY
    {
    SFR : origin = 0x0000, length = 0x0010
    PERIPHERALS_8BIT : origin = 0x0010, length = 0x00F0
    PERIPHERALS_16BIT : origin = 0x0100, length = 0x0100
    RAM : origin = 0x0200, length = 0x0800
    INFOA : origin = 0x1080, length = 0x0080
    INFOB : origin = 0x1000, length = 0x0080
    FLASH : origin = 0x1100, length = 0xC6E0
    INT00 : origin = 0xD7E0, length = 0x0002
    INT01 : origin = 0xD7E2, length = 0x0002
    INT02 : origin = 0xD7E4, length = 0x0002
    INT03 : origin = 0xD7E6, length = 0x0002
    INT04 : origin = 0xD7E8, length = 0x0002
    INT05 : origin = 0xD7EA, length = 0x0002
    INT06 : origin = 0xD7EC, length = 0x0002
    INT07 : origin = 0xD7EE, length = 0x0002
    INT08 : origin = 0xD7F0, length = 0x0002
    INT09 : origin = 0xD7F2, length = 0x0002
    INT10 : origin = 0xD7F4, length = 0x0002
    INT11 : origin = 0xD7F6, length = 0x0002
    INT12 : origin = 0xD7F8, length = 0x0002
    INT13 : origin = 0xD7FA, length = 0x0002
    INT14 : origin = 0xD7FC, length = 0x0002
    RESET : origin = 0xD7FE, length = 0x0002
    }

  • Hi, Dan, 

    Are you referring to the application report of slaa600 (http://www.ti.com/lit/an/slaa600d/slaa600d.pdf) for your code development of the customized bootloader and application code? If yes, the concept is the application code cannot be debugged because the reset vector and interrupt table are remapped in the application code project and the generated .txt file is downloaded to the MCU through the bootloader which is programmed to the MCU in advance. 

    In the customized bootloader of slaa600 document, the interrupt table is copied to the 0xFFE0~0xFFFC by bootloader before jumping to the application code start address. You can refer to following figure (copied from slaa600) for the interrupt vector redirection. 

    If you want to debug the application code, you have to change the linker command file to default file so that the reset vector and the interrupt table will be normal. After the debug, you need to change back to the remapped linker command file to generate the .txt so as to work with the customized bootloader. 

    Thanks, 

    Lixin 

**Attention** This is a public forum