CC2651R3: Guidance Required to Implement UART Backdoor Bootloader in CC2651R3

Hi Clement,

Thanks for your quick response,

In Uniflash currently I am selecting device name CC2652R1F (BOOTLOADER) to upload the firmware in UART BL Backdoor mode.

(why CC2652R1F (BOOTLOADER) (because functionalities are same of the CC2651R3 and CC2652R1F)

Kindly refer the below screenshot......

When I attempt to upload firmware in Bootloader (BL) mode, I consistently encounter the errors mentioned in screenshot.

I also tried uploading a .bin file and manually CCFG settings, but the result remains the same.

Could you please advise if there are additional steps or settings I might be missing? Any guidance to resolve this issue would be greatly appreciated.

Regards,

Rajnish Singh

Hi Clement,

Thanks for your response,

I understand that the memory check run by UniFlash will fail since the devices are different. However, I just attempted to upload the firmware by selecting the CC2652 device type because both MCUs are compatible.

I am currently using the sblAppEx library (as per Serial Bootloader Interface documentation) to upload firmware to the CC2651R3 in bootloader mode, as this is the currently available solution due to the lack of support in other tools. While the library works effectively for uploading a single file at a time, I would like to know if there is a way to upload multiple files simultaneously or sequentially without restarting the process for each file manually.

Could you please provide guidance or suggestions on achieving this functionality using the sblAppEx library? If modifications or additional tools are required, I would appreciate any relevant documentation or examples.

Thank you for your support.

Regards,

Rajnish

Include this as well,

After Bootloader changes done in ccfg.c file, i am not able to enable Backdoor Bootloader option in the project -> project_zero.syscfg -> Device Configuration

Kindly refer below screenshot...

What steps are required to enable this?

Regards,

Rajnish

Hi, 

For OAD-enabled projects, the CCFG should be configured from the MCUboot project. 

I hope this will help,

Best regards, 

Hi Clément,

Thanks for your response,

I already did the changes in CC2651R3 respective MCUboot Project (you can find start of this thread),

Rajnishkumar Singh said:

Configured the ccfg.c file to enable the backdoor bootloader and set the required activation pin and logic level

(ccfg.c file path - bim_offchip_LP_CC2651P3_nortos_ticlang/Application/ccfg_app.c/DeviceFamily_constructPath(startup_files/ccfg.c))

With the help of the sblAppEx library, I am able to update the firmware in bootloader mode when a valid image is found.

However, if no valid image is present in the flash memory, I am unable to burn the firmware in ROM bootloader mode.

Could you please suggest what might be causing this issue?

Regards,

Rajnish

Hi, 

Great progress, thank you for sharing. 

Rajnishkumar Singh said:

However, if no valid image is present in the flash memory, I am unable to burn the firmware in ROM bootloader mode.

If no image valid is present, the device is expected to enter the serial bootloader mode - no matter the state of the back door pin. See Figure 2-1 in https://www.ti.com/lit/swra466 

Best regards, 

Hi Clément,

Thanks for your response,

I am working on an OAD-enabled project (off-chip OAD) where I need to upload two firmware files (BIM and Application) using the ROM Bootloader in case of valid image not found.

With the sblAppEx library, I am currently able to upload only one file at a time. However, I noticed that the logic for uploading multiple files is implemented in the sblAppEx.c file, but this option is not accessible in the sblAppEx.exe GUI.

(refer below code snippet of sblApp.Ex.c) 

flashing:

    file = ifstream();

    //
    // If we are loding the second binary, there is no need to create and connect a new SBLDevice.
    //
    if (dualBinaryLoaded == false)
    {

        //
        // Create SBL object
        //
        pDevice = SblDevice::Create(deviceType);
        if (pDevice == NULL)
        {
            cout << "No SBL device object.\n";
            goto error;
        }


        //
        // Connect to device
        //
        cout << "\nConnecting (" << comPort << " @ " << baudRate << " baud) ...\n";
        getTime();
        if (pDevice->connect(comPort, baudRate, bEnableXosc) != SBL_SUCCESS)
        {
            goto error;
        }
        printTimeDelta();

    }

What steps should I take to enable and access this multi-file upload option in the GUI?

Regards,

Rajnish

Hi Rajnish, 

The tool can be recompiled - sources are provided as you mentioned. 

Alternatively, images can be merged prior using the tool. 

I hope this will help,

Best regards, 

Hi Clément,

Thanks for your response,

I tried to rebuild this library using VS Code, but i am facing compilation error.

Clément said:

The tool can be recompiled - sources are provided as you mentioned. 

Alternatively, I also tried using a merged image file:

1. Merged the Hex (BIM + App) using hexmerge.py (successfully generated the merged hex file).
2. Converted the merged Hex into a Bin file using oad_image_tool.
3. I can see the converted merged Bin file in the project build directory, but the size of the merged Bin file is the same as the application Bin file.
4. Successfully flashed the merged Bin file into the device, but the device is not advertising. However, if I flash the same merged Bin file along with the boot project file, it works.
5. Based on my observations, it seems that the tool is generating the same application Bin file but naming it as the merged Bin file.

Please find below the post-build steps for the same.

${CG_TOOL_ROOT}/bin/tiarmobjcopy -O ihex ${BuildArtifactFileName} ${BuildArtifactFileBaseName}.hex
${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/oad_image_tool --verbose ccs ${BuildDirectory} 7 -hex1 ${BuildDirectory}/${BuildArtifactFileBaseName}.hex -k ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/private.pem -o ${BuildDirectory}/${BuildArtifactFileBaseName}_oad
python ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/ble5stack/hexmerger/scripts/hexmerge.py		-o ${BuildDirectory}/${BuildArtifactFileBaseName}_merged.hex   ${BuildDirectory}/${BuildArtifactFileBaseName}.hex	${BIM_HEX_DIR}/bim_offchip_LP_CC2651P3_nortos_ticlang.hex
${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/oad_image_tool --verbose ccs ${BuildDirectory} 7 -h ${BuildDirectory}/${BuildArtifactFileBaseName}_merged.hex   -k ${COM_TI_SIMPLELINK_CC13XX_CC26XX_SDK_INSTALL_DIR}/tools/common/oad/private.pem -o ${PROJECT_ROOT}/${ConfigName}/${ProjName}_merged_oad

Regards,

Rajnish

Hi Rajnish, 

I could not identify the issue for now - and I'll be out for two weeks. 

As a temporary workaround, I'd suggest to flash the two images on a device using the debug interface / UniFlash. After this, you can dump the device flash content to a file and use this file for flashing through the serial boot loader. 

I hope this will help,

Best regards, 

Hi Clément,

Thank you for your suggestion regarding the temporary workaround. However, this task is critical, and we cannot afford to wait for two weeks.

Could you kindly assign this to someone else who can assist us in identifying and resolving the issue promptly? Your support in ensuring timely progress on this task would be greatly appreciated.

Regards,

Rajnish