• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 52 subscribers
  • Views 852 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

CC2340R5: How to flash without Code Composer

Albert Carles
Prodigy 40 points

Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH

Dear,

We need to prepare the documentation for EOL procedure to flash CC2340 modules. Nowadays, in development, we are using Code Composer flashing tools to erase/flash the device. We use XDS-110 debug probe, so there is any way to perform that flash by using an external flashing tool such as a generic TI Flashing Tool ?

Also, for the final compilation image we don't know if we will need to deliver in .HEX or .BIN format (also because we will use TI Bootloader to flash the unit in field), so can you tell us how we can manage the conversion between .HEX (default format) and .BIN (format to be use during Boot flashload).

Thanks,

  • +1
    TI__Genius 14324 points

    Hello Albert Carles,

    I hope you are well. 

    To perform a flash without CCS I would recommend using Uniflash.

    To convert your format, I would recommend viewing our CCS User's Guide, specifically section 6.1.3.4 Pre and Post Build Steps, looking at the post-build steps provides guidelines on how to convert the executable (.out) crated by the project into a hex or binary format using the hex converter, or tiobj2bin. 

    Thanks,

    Alex F

  • 0 in reply to Alex Fager
    Prodigy 40 points

    Okay, I was able to use Uniflash with no problem. 


    Regarding .bin creation, the documentation that we use from TI was not completed (basically the .exe names are incorrect). However, finally we accomplish to create the file. The main issue is that the size is huge due some "footer" content at some high address that implies a 1GB file creation.. Can you help us ? This info is needed?

    Here I attach two image as per your reference.

    Thanks,

  • 0 in reply to Albert Carles
    TI__Genius 14324 points

    Hello Albert Carles, 

    First to address your large .bin file, it seems likely that the file is uncompressed since 4E0207F0 = 1308755952 = ~1.2 GB. 

    Taking a step back, there is another command for the post-build-step processing, which is lifted from the BLE "basic_persistent..." project example in the SDK (simplelink_lowerpower_f3_sdk_7_10_00_35): 

    ${CG_TOOL_ROOT}/bin/tiarmobjcopy ${ProjName}.out --output-target binary ${ProjName}.bin --remove-section=.ccfg
    ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/tools/common/mcuboot/imgtool sign --header-size 0x100 --align 4 --slot-size 0x2C000 --version 1.0.0 --pad-header --key ${COM_TI_SIMPLELINK_LOWPOWER_F3_SDK_INSTALL_DIR}/source/third_party/mcuboot/root-ec-p256.pem ${ProjName}.bin ${ProjName}.bin

    When I changed the post-build-steps to these steps then cleaned project, and then rebuilding the project resulted in a .bin file of 17 KB (for the uart2echo example). As a note when using Uniflash, after you load a file, you might need to press reset since the device will be stuck in debug mode a wait a few seconds for the program to start. 

    Let me know if this solves your issue about the .bin file being too large.

    If you not using OAD you could just use the .out file. 

    Thanks,
    Alex F

  • 0 in reply to Alex Fager
    Prodigy 40 points

    Okay, so can we avoid to flash ccfg always? We was thinking into split the huge BIN into two files. One with application and the other one with CCFG and check to flash with uniflash by using the two binaries.

    Thanks,

  • 0 in reply to Albert Carles
    TI__Genius 14324 points

    Hello Albert Carles,

    Albert Carles said:
    Okay, so can we avoid to flash ccfg always?

    CCFG only needs to be programmed once, afterwards if you do not make any changes to it then you can leave it alone. The CCFG exists outside of the regular flash memory area on the CC2340 devices. Also included is a picture from Uniflash which includes options about flashing (clear or retain CCFG). 

    Albert Carles said:
    split the huge BIN into two files

    The .bin files do not accept holes in the file (ie jumping from one memory location to another to continue writing) thus the massive bin size where it fill all the memory space, even the illegitimate flash areas; also since CCFG is loaded in the end part of flash "The CCFG is placed at the end of the last flash page and lets the customer configure various chip and system parameters", which may cause a very large file size.

    Albert Carles said:
    One with application and the other one with CCFG and check to flash with uniflash by using the two binaries.

    In the steps I included "--remove-section=.ccfg" since the CCFG is handled by the BIM project, where the hex image is loaded alongside the application images; and this reduced the .bin size to 16 KB. 

    Things to try, I recommend you try to take the good hex file and convert it to your .bin files as needed:

    https://e2e.ti.com/f/1/t/1237079 (hex to bin file conversion) 

    Options you can try:

    1. Use the generated hex file as long as you are not using OAD applications, unless you have any other *.bin requirement.

    2. Take the generated hex file, split it into two (one for application and one for the other CCFG) and run a hex to bin converter to create two bin files to program (this E2E thread will be helpful when it comes to this topic).

    I hope this helps.

    Thanks,
    Alex F