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.

MSP-EXP432P4111: Attempting to run BSL from source build in CCS, having problems

Part Number: MSP-EXP432P4111

Hi,

 there are 2 .cmd files for the source for MSP432BSL_1_01_00_00 for the launchpad, 401r

one is msp432p401r_debug_flash, which loads the BSL at address 0, for debugging

the other is msp432p401r.cmd, which loads the BSL where it supposed to go

these .cmd files have the date 2015, when I try to run using the debug flash .cmd file, the ccs debugger says the board is held in reset and won't run.

when I compared the .cmd file to a more recent projects .cmd file, the style of commands has changed, in particular, there is a statement that tests the version of the compiler,

new style:

#ifdef __TI_COMPILER_VERSION__
#if __TI_COMPILER_VERSION__ >= 15009000

My questions are:

 1. how do I determine the version of my compiler

 2. do I need to rewrite the  debug flash .cmd file to match (and will this get the launchpad out of reset)?

thank you (and happy holidays to all)

bob s.

  • I modified the .cmd file and it loads but I can't debug because the launchpad is stuck in reset.

    I am attaching the modified .cmd file:

    --retain=flashMailbox

    MEMORY
    {
    MAIN (RX) : origin = 0x00000000, length = 0x00002000
    BSL_START (RX) : origin = 0x00002000, length = 0x00000010
    BSL_FLASH1 (RX) : origin = 0x00002020, length = 0x00000060
    BSL_INTVEC (RX) : origin = 0x00002080, length = 0x00000020
    BSL_FLASH2 (RX) : origin = 0x000020A0, length = 0x00003F60
    /* SRAM_CODE (RWX): origin = 0x01000000, length = 0x00010000 */
    /* SRAM_DATA (RW) : origin = 0x20000000, length = 0x00002000 */
    #ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
    ALIAS
    {
    SRAM_CODE (RWX): origin = 0x01000000
    SRAM_DATA (RW) : origin = 0x20000000
    } length = 0x00010000
    #else
    /* Hint: If the user wants to use ram functions, please observe that SRAM_CODE */
    /* and SRAM_DATA memory areas are overlapping. You need to take measures to separate */
    /* data from code in RAM. This is only valid for Compiler version earlier than 15.09.0.STS.*/
    SRAM_CODE (RWX): origin = 0x01000000, length = 0x00010000
    SRAM_DATA (RW) : origin = 0x20000000, length = 0x00010000
    #endif
    #endif
    BSL432_VERSION_VENDOR (R): origin = 0x00002010, length = 0x00000002
    BSL432_VERSION_CI (R): origin = 0x00002012, length = 0x00000002
    BSL432_VERSION_API (R): origin = 0x00002014, length = 0x00000002
    BSL432_VERSION_PI (R): origin = 0x00002016, length = 0x00000002
    BSL432_VERSION_ID (R): origin = 0x00002018, length = 0x00000002
    }

    /* The following command line options are set as part of the CCS project. */
    /* If you are building using the command line, or for some reason want to */
    /* define them here, you can uncomment and modify these lines as needed. */
    /* If you are using CCS for building, it is probably better to make any such */
    /* modifications in your CCS project and leave this file alone. */
    /* */
    /* A heap size of 1024 bytes is recommended when you plan to use printf() */
    /* for debug output to the console window. */
    /* */
    /* --heap_size=1024 */
    /* --stack_size=512 */
    /* --library=rtsv7M4_T_le_eabi.lib */

    /* Section allocation in memory */

    SECTIONS
    {
    .BSL432_VERSION_VENDOR : > BSL432_VERSION_VENDOR
    .BSL432_VERSION_CI : > BSL432_VERSION_CI
    .BSL432_VERSION_API : > BSL432_VERSION_API
    .BSL432_VERSION_PI : > BSL432_VERSION_PI
    .BSL432_VERSION_ID : > BSL432_VERSION_ID
    .bsl_start: > BSL_START
    .intvecs: > BSL_INTVEC
    .text : >> BSL_FLASH1 | BSL_FLASH2
    .const : >> BSL_FLASH1 | BSL_FLASH2
    .cinit : > BSL_FLASH2
    .pinit : >> BSL_FLASH1 | BSL_FLASH2
    .init_array : > MAIN

    .binit : {} > MAIN

    .flashMailbox : > 0x00200000

    .vtable : > 0x20000000
    .data : > SRAM_DATA
    .bss : > SRAM_DATA
    .sysmem : > SRAM_DATA
    .stack : > SRAM_DATA (HIGH)

    #ifdef __TI_COMPILER_VERSION__
    #if __TI_COMPILER_VERSION__ >= 15009000
    .TI.ramfunc : {} load=MAIN, run=SRAM_CODE, table(BINIT)
    #endif
    #endif
    }

    /* Symbolic definition of the WDTCTL register for RTS */
    WDTCTL_SYM = 0x4000480C;

  • found this warning in the build, but pretty sure not related to the old in reset. dueling declarations, defined as opposites:

    "/Applications/ti/ccs1010/ccs/ccs_base/arm/include/msp432p401r_classic.h", line 2676: warning #48-D: incompatible redefinition of macro "UCRXIE" (declared at line 78 of "../BSL432_Peripheral_Interface.h")
    "/Applications/ti/ccs1010/ccs/ccs_base/arm/include/msp432p401r_classic.h", line 2679: warning #48-D: incompatible redefinition of macro "UCTXIE" (declared at line 77 of "../BSL432_Peripheral_Interface.h"


    ../BSL432_Peripheral_Interface.h:
    #define UCTXIE EUSCI_A_IE_RXIE
    #define UCRXIE EUSCI_A_IE_TXIE

    msp432p401r_classic.h:
    #define UCRXIE EUSCI_A_IE_RXIE /*!< Receive interrupt enable */
    #define UCTXIE EUSCI_A_IE_TXIE /*!< Transmit interrupt enable */

  • You can find the version at here:

    I think you problem is that for the code that loads the BSL at address 0, for debugging can't work automatically.

    Can you tell me what happens when you make the device in debug mode and press the run button?

    Can you direct set the PC point to the main function? You can find the entrance in the .map file

  • "

    I think you problem is that for the code that loads the BSL at address 0, for debugging can't work automatically.

    Can you tell me what happens when you make the device in debug mode and press the run button?

    Can you direct set the PC point to the main function? You can find the entrance in the .map file

    "

    Hi, Eason,

    I'm replying here because I can't find the reply button at the bottom of your message.

     I cannot debug, I get the error message that the CPU is held in reset.

    "Trouble Halting Target CPU: (Error -1266 @ 0x0) Device is held in reset.

    Take the device out of reset, and retry the operation"

    After the holidays, I'll try using the other non-debug .cmd file and see how far that gets.

     bob s.

  • I must have hit reply before editing, the reply button eventually showed up, and I was able to copy-and-paste but not edit.

  • I tried the .cmd file, msp432p401r.cmd that came with the BSL project and got a series of error messages.

    My question is, could this project have ever run via CCS?

    <Linking>

    warning #10247-D: creating output section ".TI.noinit" without a SECTIONS specification

    "../MSP432P401x/msp432p401r.cmd", line 81: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment fails for section ".text" size 0x287b.  Available memory ranges:

       BSL_FLASH1   size: 0x60         unused: 0x0          max hole: 0x0       

       BSL_FLASH2   size: 0x1f60       unused: 0x6          max hole: 0x6       

    "../MSP432P401x/msp432p401r.cmd", line 82: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment fails for section ".const" size 0x18a.  Available memory ranges:

       BSL_FLASH1   size: 0x60         unused: 0x0          max hole: 0x0       

       BSL_FLASH2   size: 0x1f60       unused: 0x2          max hole: 0x2       

    "../MSP432P401x/msp432p401r.cmd", line 83: error #10099-D: program will not fit into available memory, or the section contains a call site that requires a trampoline that can't be generated for this section. placement with alignment fails for section ".cinit" size 0x46.  Available memory ranges:

       BSL_FLASH2   size: 0x1f60       unused: 0x2          max hole: 0x2       

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

  • I think yes. I need to consult other colleague. I will come back before tomorrow.

  • Can you send me you file? As I check the latest 432 SDK doesn't have the BSL code.

  • Please put the code under C:\ti.

    Load the project(MSP432P401) without loading it into workspace (It uses absolute file address)

    I think then you will meet a problem about the SDK. Then select the right product in properties.

    Please check if it can help you.

    MSP432P_BSL_Source.zip

  • How do I attache a zipped file?

  • this reply is in response to your first request, "Can you send me you(r) file?"

  • I am not sure about what you are requesting for "Load the project" as I can't build the project.

    I'm under the impression that a project has to build before being loaded.

    Also, I am using ubuntu, there is no C: drive.

    Perhaps your request pertains to the windows version of CCS?

  • I believe what you sent me, is what I already have.

    Do you see the two similar command files, msp432p401r_debug_flash.cmd and msp432p401r.cmd?

    the first, debug, builds but leaves the launchpad in reset

    the second won't build and outputs the "trampoline" error

  • 1. Yes, I want a project which can run on window CCS.

    2. To upload the zip file, you just need to drag it into the reply column.

    3. About ".TI.noinit" warning, it lies on here. NOINIT will create the code saved in ".TI.noinit", which is not existed in .cmd file.

    4. For the first, using debug_falsh.cmd, the reason why the device can't find the right main function entrance is that, it doesn't  put the "_c_int00_noargs" at 0x00000000 (The default entrance of ARM). After you do the changes in the .cmd file. The code will jump into main function automatically. The reason why he do this, is because he want to make the two .cmd file to be constant. I think you can find some explain from the BSL document.

    5. To make it work without changing the cmd file, you can just enter the value of "_c_int00_noargs" found in .map file in debug folder into PC. Then press enter, you will find the right entrance.

    6. For the msp432p401r.cmd file, on my side I can build it without fault:

    7. All the test is on window CCS. hope to give you some guidance.

  • Hi, this solved the issue for the "debug" command file. BUT ...

        I'm still having the no memory or trampoline error for the non-debug .cmd file.

       New data point, this (the non-debug) compiles w/o error using CCS on my mac, but generates the trampoline error using CCS on ubuntu.

      Any help with this?  The error message seems to be platform dependent.

      I need to get this working on ubuntu (linux is the common platform for the project I'm working)

    bob s.

  • I switched to a microsoft windows 10 vm, installed CCS v11.1, installed the BSL project files, made the patches you suggested in a previous message but the msp432p401r.cmd still returned the memory/trampoline error. I then added the compiler flag suggested in the message/link above, and there was no improvement.

    So, the ubuntu and windows CCS versions fail for me.

    What version CCS are you using for windows' CCS for building with msp432p401r.cmd, that doesn't generate errors for you?

  • I also try it on CCS11. I put the changed code on the E2E. Please remember to put it under the c:/ti. And don't load it into workspace, as it use Absolute address. Hope it can solve your problem.

    8203.MSP432P_BSL_Source.zip

  • thank you, I apologize for being slow to reply, I am working another high priority task in parallel, I hope to get back to this by next week.