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

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?

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

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.