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/CC1310: [Trouble encountered] What secret is in "Mass Erase"?

Part Number: CC1310

Tool/software: Code Composer Studio

Dear Sir,

This is an emergency case.

I bought a CC1310 module from some third-party vendor.

I used the TI CC1310 launchpad as the JTAG debugger (by removing some jumpers from launchpad, and connect a JTAG 

cable to the third-party CC1310 module).

At beginning, I tried to program it by using CCS, however, CCS complained that it is "write protected".

So, I turned to use TI flash programmer 2 to execute a "mass erase". Then I can program it with my

image (.out file) by CCS.

The programming process looked good, and it ran well after pressing CCS "play" button.

However, when I tried to reboot and free-run the module (without XDS debugger), it seemed not running as I saw no packet

emitted from the module by packet sniffer's view.

I doubt that if the image really being programmed into the flash.

Then, I used the XDS debugger to launch it again without loading program, but just loading symbol tables only,

after doing run-> Reset -> System Reset, the module ran successfully again.

Q1: What is the key of my trouble? Is it related to bootloader?

Q2: I doubt if the "Mass Erase" erased the bootloader too. Is it true?

Q3: Does the .out image file contain bootloader?

Thank you for your help

BR,

Adam

  • Hi Adam,

    To answer your questions:

    1) It could be, it is hard to say without knowing your exact setup. issues with a "reset" is usually related to there being an bootloader loader (like in typical OAD cases) OR that the ccfg.c file not being setup correctly OR the application is not flashed with reset vectors at 0x0 (including a correct CCFG region).

    These issues are typically not spotted when debugging via CCS as it will jump correctly at load (as it does not run the ROM bootloader). But when you then run the ROM bootloader, if all things are not looking good, you instead fail.

    To give any better feedback on this, I would need to know what you tried to load on the device. 

    2) It would erase any Flash bootloader, yes. It will not remove the bootloader in ROM.

    3) Not unless you put one in there. If you do not expect to have a flash bootloader, then the .out should not contain one and it should be aligned with page 0 (reset vectors at 0x0) and have a valid ccfg region.

  • Dear M-W,

    Thank you for your patience reading my long statement.

    The same .out image (in fact, it is the sensor_CC1310_LAUNCHXL_tirtos project binary from SDK simplelink_cc13x0_sdk_4_10_00_10) can perfectly run 

    on CC1310 launchpad, even in a cold boot condition without XDS interference.

    Thus, I don't think something is wrong in ccfg.c (do you mean this <SDK_ROOT>/source/ti/devices/cc13x0/startup_files/ccfg.c ?).

    In fact, I don't even touch it. I copy-paste the project predefined symbols  at the end of the article.

    I was NOT exercising sensor_oad case either.

    When CCS download the program, it shows ".text 0 of 97600 at 0x0 ....". It looked normal, didn't it?

    Perhaps the third-party CC1310 module has different usage allocation on DIO pins compared to Launchpad.

    I suspect I that CANNOT erase the ccfg segment while downloading my program as it is related to the 

    module design of the third-party vendor. Am I correct?

    (BTW) Does the "define" in <work_space>/<project>/Application/Defines/sesnsor.opts override the "define" in ccfg.c?

    Thank you again

    Your any input is important to me. I appreciate very much.

    BR,

    Adam

    --------------------

    ${COM_TI_SIMPLELINK_CC13X0_SDK_SYMBOLS}
    Board_EXCLUDE_NVS_EXTERNAL_FLASH
    DeviceFamily_CC13X0
    SET_CCFG_BL_CONFIG_BL_LEVEL=0x00
    SET_CCFG_BL_CONFIG_BL_ENABLE=0xC5
    SET_CCFG_BL_CONFIG_BL_PIN_NUMBER=0x0D
    SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE=0xC5

  • Hi Adam,

    It could be related to package and a miss-match in DIO. You know what package is mounted on the module, 5x5, 4x4? The image you refer to should be fine in regards to the "ccfg" region.

    A quick note on the "SET_CCFG_BL_CONFIG" settings. These enable the serial bootloader together with the backdoor pin. This means that one DIO "0x0D" is low during boot (as defined by the BL_LEVEL and BL_PIN_NUMBER), the device will halt in the serial bootloader and not move on to run the application code. Could this also be your issue?

  • Hi M-W,

    Bingo.

    Yes, your reasoning is correct.

    The third-party module+our mother-board has different design in DIO 13.

    The default level (when the button is not pressed) is opposite compared to launchpad, thus, the board gets into bootloader

    backdoor mode after power-on.

    Yet, when we debug it with CCS, as you said, the bootloader is bypassed, so it is free from the issue.

    Thank you again. You are so great to me.

    BR,

    Adam