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.

CC2642R: How to use SblAppEx application to burn serial data for many times?

Part Number: CC2642R
Other Parts Discussed in Thread: SYSCONFIG

Thank you for asking for help. I want to use the SblAppEx application to burn continuously. At present, I can achieve single burning. First erase, and then configure the io port to pull down by default. Then power on again to achieve burning. According to the instructions in the manual, the CCFG file needs to be configured. After I configure it, I re record the new bin through serial mode. After restart, the program runs normally, but it still cannot be burned again. Every time, it needs to be erased again by force. May I ask where I made a mistake?

  • Hi LTS,

    You need to select and control a BL_PIN_NUMBER which corresponds to the GPIO that the device checks the BL_LEVEL of during startup to determine whether it should enter the ROM bootloader.  Otherwise only by erasing the entire flash can the bootloader be entered, as you've observed.

    Regards,
    Ryan

  • "BL_PIN_NUMBER" refers to the boot enabled IO port? In the previous test, I found the enabling foot according to the document and suggested that it was forced to lower, but it was still invalid, so I raised this question.

  • The BL_PIN_NUMBER is the Bootloader backdoor enable pin which is ultimately dependent on your project's CCFG configuration.  For DIO11, SET_CCFG_BL_CONFIG_BL_PIN_NUMBER should be 0x0b.

    Regards,
    Ryan

  • Thanks for your reply. I just tried the following:

    1: Reconfigure the four parameters of CCFG, which are 0xC5, 0x00, 0x0B, 0xC5, and then recompile the program;

    2: My DIO11 is forced to lower;

    3: I force the program "forced mass erase" to be erased again

    4: Open sblAppEx to restart serial burning

    5: The program runs normally after resetting the program.

    6: Open sblAppEx to restart serial burning, cooperate with the reset operation, and the boot program cannot be entered. After many attempts, the operation fails. (No response from device. Device may not be in bootloader mode. Reset device and try again.

    If problem persists, check connection and baud rate.).

    What are the problems above?

  • 0x0B/DIO11 is a suggestion, however you will need to review the hardware design you are using to make sure it is an adequate pin setup.  You should use a logic analyzer or oscilloscope to further analyze the bootload pins and ensure they are acting as intended.  Also, try to read the CCFG contents after the initial program to verify that the bootload bytes are configured properly.  You could use application indications (radio activity, LED, user UART) to observe whether the device is running the firmware or has likely entered the ROM bootloader.

    Regards,
    Ryan

  • Ok, thanks for your reply!

    I try the following:

    1: DIO11 is grounded, and the oscilloscope is used to test the level. The level remains low;

    2: Use "flash programmer 2" -->forced mass erase;

    3: Read CCFG ->Figure 1;

    4: Reconfigure the four parameters of CCFG, namely 0xC5, 0x00, 0x0B and 0xC5, modify only the four parameters, and then recompile the program;

    5: Through the "flash programmer 2" burning program, read the CCFG after burning ->Figure 2;

    6: The program does not run after reset, and the program can only run when DIO11 is set to high level (does this phenomenon indicate that it is effective to enter the boot mode when DIO11 is low?);

    7: Open sblAppEx to restart the serial burning, and cooperate with the reset operation, unable to enter the boot program. The operation failed after several attempts.

    What is the above question? Why can't I enter the boot program for the second time?

  • Here is my process so that you may understand what is incorrectly occurring from your end:

    • Import a SimpleLink SDK project into CCS
    • Ensure that SysConfig -> Device Configuration has Enable Bootloader and Enable Bootloader Backdoor selected, and further choose the Bootloader Backdoor DIO and Trigger Level
    • Add post-build steps to generate a binary image (if not already done in Project Properties -> CCS Build -> Steps)

    ${CG_TOOL_ROOT}/bin/tiarmobjcopy ${BuildArtifactFileName} --output-target ihex ${BuildArtifactFileBaseName}.hex
    ${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.bin ${CG_TOOL_ROOT}/bin/tiarmofd ${CG_TOOL_ROOT}/bin/tiarmhex ${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin

    • Build two versions (1&2) of the project with discernable run-time differences and copy both output binaries into the sblAppEx_1_03_00_00\bin folder with different names
    • Program the target device with project version 1, mainly to initialize CCFG settings
    • Rename the existing sblAppEx_1_03_00_00\bin\blinky_backdoor_select_btn26x2.bin to something else, then rename the binary of project version 2 binary to blinky_backdoor_select_btn26x2.bin so that it becomes the uploaded image during sblAppEx operation
    • Confirm proper operation of project version 1 on the target device before triggering bootload mode by activating the bootload pin and resetting, at which point the device is now unresponsive (bootload mode)
    • Run .exe from within a command prompt located at sblAppEx_1_03_00_00\bin, choose the correct UART port and device to program project version 2 (currently named blinky_backdoor_select_btn26x2.bin)
    • Disactivate the bootload pin so that the device operates project version 2 after the flash program and device reset is completed
    • Confirm that project version 2 is now active on the device
    • Revert blinky_backdoor_select_btn26x2.bin back to the original project version 2 name and rename the project version 1 binary image to blinky_backdoor_select_btn26x2.bin instead
    • The process can now be repeated indefinitely

    Under these conditions, the bootloader is always enabled since the project versions both have valid CCFG configuration which are re-written with each flash program operation.  Thus sblAppEx can be run repeatedly without forcing a mass erase of the device.

    Regards,
    Ryan

  • Hello, thank you for reply!
    I have never been realized according to the operation. The only possible problem is the problem of equipment configuration. Can it provide a simple LED flash light available item?
    My project operation process is:
    1: Import "Buttonled_cc26x2R1_LAUNCHXL_TIRTOS7_TICLANG" to modify the LED automatic flashing;
    2: Modify the CCFG file, 0xc5, 0x00, 0x0b and 0xc5;
    3: DIO11 forced pulling down;
    4: Forced cutting Flash;
    5: Use sblappex serial records to successfully record.
    6: Restart the device and cannot start;
    7: DIO11 forced pulling the level, restarting the device, LED flashing, successful start;
    8: Use "Flash Programmer 2" Read The CCFG After Burning-> Figure 1;
    9: DIO11 is forced to lower, restart the device, and use the Sblappex serial recording again, and the burning record failed.

  • Version used:ccs1030、simplelink_cc13xx_cc26xx_sdk_6_20_00_29

  • 0x57FDB should be 0xC5 for BOOTLOADER_ENABLE to be set.  You could also consider a HW pin change to confirm that DIO11 is not errant, but based on the CCFG memory read it appears that your bootloader has not been enabled.

    Regards,
    Ryan

  • OK, thanks for your reply. I didn't have time to delay the project some time ago, but I still couldn't find the problem after I re operated. Can you provide a feasible software code to solve the problem more quickly.

  • These are the SysConfig settings I used on default software projects to configure the backdoor bootloader operation.

    Regards,
    Ryan