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.

CC2652P: code size changed in SDK v7.40

Part Number: CC2652P

Hi all,

I'm using host test example on CC2652P1F with SIMPLELINK-LOWPOWER-F2-SDK v7.40. When I flashed gbl file to ble chip with Flash Programer 2, the error prompt: "Unknown record type: 3". Then I found that the gbl size is 445Kb, but flash size on CC2652P is 352Kb. 

To flash image on CC2652P, is there any way to reduce gbl size?

  • Hi,

    How are you generating the gbl file?

    The host_test example from the SDK should generate a .out or .hex file, and this should be built with the correct firmware size:


  • Hi Toby,

    Thanks for your reply.

    The generated image should be hex file, not gbl. I'm sorry to have confused you.

    I created hex file from example project CC2652PSIP LaunchPad -> TI Clang Compiler -> host_test. Attached image showing the files size.

    Which project should I choose to generate correct firmware size?

  • Hi West,

    Is this an unmodified host_test?

    Which CCS version are you using?

    Can you try building a drivers example?

    When I build this in my CCS, I see the following for Memory Allocation (Window --> Show View --> Memory Allocation):

    So the actual firmware image takes up 170kB flash. This is equivalent to the .map file, which has this:   FLASH                 00000000   00056000  0002988f  0002c771  R  X
    (0x2988F is the used flash).
    The hex file generated is 362kB.

    The reason for difference, is that the hex file contains the full image (including "empty" space) to be programmed onto the device.

    Can you check what you see in your .map file or "Memory Allocation"?


  • Hi Toby,

    Thanks for your reply. I'm West's colleague.

    We only doing a little modification. Such as changing the backdoor's DIO, and baud rate, and enabling the advertising channel (adding the flag DADV_RPT_INC_CHANNEL=1).

    Following is my "Memory Allocation". 

    And the FLASH in map file is shown as follows.

    FLASH                 00000000   00056000  0002b544  0002aabc  R  X

    However, the size of the hex file still keeps 443KB. Would you tell us how to reduce the "empty" space in the file?



  • Hi Rote,

    Which CCS version?

    What is size of hex file when you build unmodified example?


  • Hi Toby,

    We are building project with CCS v12.

    I imported host_test project from Resource Explorer, and project path is 

    SimpleLink CC13xx CC26xx SDK ( -> CC2652PSIP LaunchPad -> BLE5-Stack -> host_test -> TI Clang Compiler . The project was build without any changes, and the .hex file in "workspace -> Release" is still 439 KB over the chip flash size 352KB. The FLASH configuration in .map file is "00000000   00056000  0002af60  0002b0a0  R  X".

    Hope these information would help.



  • Hi West,

    I think it might be related to how that project is generating the hex file.

    Try these steps:

    1. right-click project --> Properties
    2. Build --> Steps --> Post-build steps --> delete the contents there
    3. Build --> Arm Hex Utility --> Enable 'Arm Hex Utility'

    For me, this reduced the hex file to something more reasonable.


  • Hi Toby,

    I followed your settings and the .hex reduced to 101KB, thanks for your tips.

    The .hex can write to CC2652P with Flash Programer 2, but there have no response on btool after flash chip. After flash back to previous SDK version(7.10), btool show responses form chip. It seems that some functions lost in the .hex file.

    How to make the .hex file workable?



  • Try the suggestion here:

    Specifically add a post build step: "${CG_TOOL_HEX}" -order MS --memwidth=8 --romwidth=8 --intel -o "${ProjName}.hex" "${ProjName}.out"

  • Hi Toby,

    I can build .hex file with size 381 KB after set this configuration, and host_test function is workable.

    Thanks for your help.


  • The modification in code size for CC2652P in SDK v7.40 signals a noteworthy directv plans development. Whether it's an expansion or reduction, such alterations often reflect optimizations or additional functionalities. Developers should carefully assess the impact on memory usage and performance, ensuring compatibility with existing codebases and considering potential benefits for future projects.