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.

MSPM0L1306: Hex file generation with offset for the application + bootloader

Part Number: MSPM0L1306
Other Parts Discussed in Thread: SEGGER

Hello,

I have two projects on CCS v20.3.1.5 for the MSPM0L1306.
One is a bootloader and the other is the application (which is supposed to be placed after the bootloader). 
I use the binary output file of the application project to create my upgrade package and it works correctly, from the bin generation up to the upgrade by the bootloader.

Now, I have to create one intel hex file for the production programming : I want to generate the hex file of the bootloader and the hex file of the application in order to merge them into one global file.

The problem is the hex file generation of the application project. The hex file is generated by the compiler but it seems to begin at the address 0x00. Even if my linkerfile set the application at 0x5400.

I generate the hex file with the post build step as follow : "${CG_TOOL_ROOT}/bin/tiarmhex.exe" --diag_wrap=off --intel "${BuildArtifactFilePath}" --outfile "${BuildDirectory}/application.hex"

For your understanding, I attached the linkerfile's content to this post.

linkerfile.txt 

How can I apply the application memory offset to the hex file ?

Thanks for your help.
Alexandre.

  • Hi Alexandre,

    Are you able to use TI-TXT hex file? If so, you can easily change what memory address to start writing by adjusting the value after the @ symbol.

    In the example below, if you want to have this application code sit at 0x1000, simply change the first line to @1000.

    @0000
    00 20 00 20 BB 01 00 00 C3 01 00 00 C3 01 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 C3 01 00 00 
    00 00 00 00 00 00 00 00 C3 01 00 00 C3 01 00 00 
    C3 01 00 00 C3 01 00 00 C3 01 00 00 C3 01 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 C3 01 00 00 
    C3 01 00 00 C3 01 00 00 00 00 00 00 00 00 00 00 
    00 00 00 00 00 00 00 00 00 00 00 00 C3 01 00 00 
    C3 01 00 00 C3 01 00 00 C3 01 00 00 C3 01 00 00 
    00 00 00 00 00 00 00 00 C3 01 00 00 C3 01 00 00 
    C3 01 00 00 C3 01 00 00 00 00 00 00 C3 01 00 00 
    00 00 00 00 C3 01 00 00 C3 01 00 00 C3 01 00 00 
    82 B0 29 48 29 49 01 23 01 93 9A 07 1B 06 03 24 
    00 94 E4 04 26 4D 27 4E 6E 60 27 4F 7E 60 27 4E 
    2E 60 3E 60 10 26 B7 1E 3F 1F 00 BF FC D2 24 4E 
    81 27 F7 60 37 61 B7 62 37 60 0E 46 10 3E 32 60 
    0A 62 07 46 10 3F 23 26 F6 04 3E 60 06 62 1D 4D 
    00 26 2E 60 1C 4D 2D 68 00 9E B5 43 1A 4E 35 60 
    B5 68 01 9E B5 43 18 4E B5 60 05 46 20 3D 2C 60 
    0D 46 20 3D 2A 60 3B 60 00 BE 14 4D AE 1E 36 1F 
    00 BF FC D2 04 60 03 60 0A 60 AE 1E 36 1F 00 BF 
    FC D2 04 60 03 60 0A 60 AE 1E 36 1F 00 BF FC D2 
    04 60 03 60 0A 60 E9 E7 B0 32 0A 40 B0 12 0A 40 
    00 08 0A 40 03 00 00 B1 00 28 0A 40 01 00 00 26 
    90 80 42 40 08 03 0B 40 00 01 0B 40 00 24 F4 00 
    06 48 80 F3 08 88 00 BF 00 BF 00 F0 10 F8 00 20 
    FF F7 8E FF 01 20 00 F0 03 F8 C0 46 00 20 00 20 
    00 F0 01 F8 FE E7 00 BF 70 47 E9 E7 70 47 01 20 
    70 47 FE E7 00 00 00 00 
    q
    

    Best,

    Owen

  • Hi Owen,

    In production process, we are always using the Segger Flasher pro with JFlash utility + hex file program.
    This is why I need the hex file.

    Regards,

  • Hi Alexandre,

    I believe the TI-TXT hex file format should work with the JFlash utility (from the JFlash Documentation).

    Best,

    Owen

  • Owen,
    I upgraded my JFlash utility and now I am able to use ti-txt files. But I still have the same issue, the ti-txt file base address is "@0000" and there is another address indicator near to the end of the file "@5280".
    I know the offset can be added with a simple script, but is there any way to manage this by the TIarm.exe compiler ? 

    Regards
    Alexandre

  • Hi Alexandre,

    I believe the issue lies with your linker file. I would refer to the linker file in the bim_sample_image example:

    /*****************************************************************************
    
      Copyright (C) 2023 Texas Instruments Incorporated - http://www.ti.com/
    
      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" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
      LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
      A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
      OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
      SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
      LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
      DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
      THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
      (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
      OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
    
    *****************************************************************************/
    -uinterruptVectors
    
    #define MCUBOOT_HEAD_SIZE             0x100
    
    /* Memory map. Should match the map in the flash_map_backend.c of the boot application */
    #define BOOT_PRIMARY_BASE_ADDRESS     0x5400
    #define BOOT_PRIMARY_SIZE             0x5400
    #define BOOT_SECONDARY_BASE_ADDRESS   0xA800
    #define BOOT_SECONDARY_SIZE           0x5400
    
    #ifdef PRIMARY_SLOT
    
    #define FLASH_BASE (BOOT_PRIMARY_BASE_ADDRESS + MCUBOOT_HEAD_SIZE)
    #define FLASH_SIZE (BOOT_PRIMARY_SIZE - MCUBOOT_HEAD_SIZE)
    
    #else
    
    #define FLASH_BASE (BOOT_SECONDARY_BASE_ADDRESS + MCUBOOT_HEAD_SIZE)
    #define FLASH_SIZE (BOOT_SECONDARY_SIZE - MCUBOOT_HEAD_SIZE)
    
    #endif
    
    MEMORY
    {
    	FLASH (RX) : origin = FLASH_BASE, length = FLASH_SIZE
    	SRAM  (RWX) : origin = 0x20000000, length = 0x00001000
    }
    
    SECTIONS
    {
        .intvecs:   > FLASH_BASE
        .text   : palign(8) {} > FLASH
        .const  : palign(8) {} > FLASH
        .cinit  : palign(8) {} > FLASH
        .pinit  : palign(8) {} > FLASH
        .rodata : palign(8) {} > FLASH
        .ARM.exidx    :  palign(8)  {} > FLASH
        .init_array   :  palign(8)  {} > FLASH
        .binit        : palign(8) {} > FLASH
        .TI.ramfunc   : load = FLASH, palign(8), run=SRAM, table(BINIT)
    
        .vtable :   > SRAM
        .args   :   > SRAM
        .data   :   > SRAM
        .bss    :   > SRAM
        .sysmem :   > SRAM
        .stack  :   > SRAM (HIGH)
    }
    

    Best,

    Owen

  • Hi   ,

    I figured out where the problem is with my linker file. I shared with you some kind of "light" version, but in reality I have "#ifdef" pre-compiler instructions within the linker file.

    MEMORY
    {
        #ifdef BOOTLOADABLE
        FLASHUSERDATA   (RX)  : origin = 0x00003000, length = 0x00002400
        FLASH           (RX)  : origin = 0x00005400, length = 0x0000ABF0
        #else
        /* Reserve app data at the end of the memory, last sector will no be used */
        /* App in debug is placed from 0 address. */
        /* App data will not be placed at the same location between bootloadable app and debug config. */
        FLASH           (RX)  : origin = 0x00000000, length = 0x0000ABF0
        FLASHUSERDATA   (RX)  : origin = 0x0000D800, length = 0x00002400
        #endif
        SRAM            (RWX) : origin = 0x20000000, length = 0x00001000
        BCR_CONFIG      (R)   : origin = 0x41C00000, length = 0x000000FF
        BSL_CONFIG      (R)   : origin = 0x41C00100, length = 0x00000080
    }


    In my project, I set 2 configurations (Debug and Bootloadable) and one of the configurations has "BOOTLOADABLE" symbol in Pre-define.

    For a reason that I don't understand, when I change the build configuration : 

    • The IDE dynamically activates/deactivates the code in the linker file : OK
    • The compiler never takes the "BOOTLOADABLE" symbol as active. : NOT OK
      • This is why the instructions are placed at 0x00

    I tried to add "#define BOOTLOADABLE" directly in the linker file for testing and after that the output files began at 0x5400.

    Where should I be suppose to add the "BOOTLOADABLE" definition in the project configuration ? 

    Best regards
    Alexandre.

  • Hi,

    I found the solution.
    There are two locations for pre-processor symbols in the project configuration. One is for the compiler only and the other is for the linker. 
    Now my "bootloadable" config works normally without any workaround.


    Best regards
    Alexandre.

  • Hi Alexandre,

    Sorry for the delay in response, due to the recent holiday in US, I was out of office.

    I see you found the solution to the problem, but if you need any further assistance, please feel free to open up a new thread.

    Best,

    Owen