• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 56 subscribers
  • Views 815 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.

CC1352P: CC1352P Serial Bootloader Configurations

shiv patil
Genius 3356 points

Part Number: CC1352P
Other Parts Discussed in Thread: Z-STACK, REMOTI, SIMPLELINK-CC13X2-26X2-SDK, FLASH-PROGRAMMER, CC2530

Hello Community,

I am working on the CC1352P ZNP device & the sbl_tool.bin Application of the Zigbee Lunux Gateway Application.

I am able to commuicate with the CC1352P ZNP device over uart communication with ZNP Host Framework & Zigbee Lunux Gateway Application.

But 

While using the serial bootloader application (sbl_tool.bin) I am not able to program the ZNP device.

Note :  Cmd used to run sbl_tool.bin script : ./sbl_tool.bin znp_CC1352P_2_LAUNCHXL_tirtos_ccs.hex /dev/serial/path 1

Here are the sbl_tool.bin application logs.

***** TI LPRF ZigBee Serial Bootloader Tool for Linux v. 0.85 *****
Requested file file: 1352_1500000_with_out_flow_control.hex
Requested serial port: /dev/serial/by-id/usb-Phynart_Zigbee_01-if00-port0
Debug traces enabled
clear reset pin : 0x0103
set reset pin : 0x0303
zbSocOpen : /dev/serial/by-id/usb-Phynart_Zigbee_01-if00-port0
UART OUT 2020-12-03 10:24:35 --> 6 Bytes: SOF:FE, Len:01, CMD0:4D, CMD1:07, Payload:01, FCS:4A
write=6
zbSocSblEnableReporting
Timer created OK
Timer created OK
Image size: 419764 bytes
Press [ENTER] any time to abort downloading image.
state = 1
Handshaking:
  Sending reset command
UART OUT 2020-12-03 10:24:35 --> 6 Bytes: SOF:FE, Len:01, CMD0:41, CMD1:00, Payload:01, FCS:41
write=6
  Closing port
  Performing HW reset
clear reset pin : 0x0103
set reset pin : 0x0303
  Opening port
UART OUT 2020-12-03 10:24:57 --> 6 Bytes: SOF:FE, Len:01, CMD0:4D, CMD1:07, Payload:01, FCS:4A
write=6
  Sending handshake command
UART OUT 2020-12-03 10:24:57 --> 6 Bytes: SOF:FE, Len:01, CMD0:4D, CMD1:04, Payload:02, FCS:4A
write=6
zbSocEnableTimeout #0
./sbl_tool.bin: waiting for poll()
Timer expired: #0
-- TIMEOUT --

I am not able to understand the  following commands

UART OUT 2020-12-03 10:24:57 --> 6 Bytes: SOF:FE, Len:01, CMD0:4D, CMD1:07, Payload:01, FCS:4A

UART OUT 2020-12-03 10:24:57 --> 6 Bytes: SOF:FE, Len:01, CMD0:4D, CMD1:04, Payload:02, FCS:4A

I have also refer the Z-stack API Moniter & Test Doc. but not able to get the information related to it.

I would also like to know,

Is there any configurations need on the CC1352P - ZNP application related to the serial bootloader?

Regards,

Shiv Patil.

  • 0
    TI__Guru**** 220377 points

    Hello shiv,

    I can only speculate that a CMD0 = 4D indicates a MT_RPC_SYS_UBL (RemoTI) AREQ which makes little sense, however the fact that any MT commands are being sent by the ZNP after reset indicates that the bootloader mode was not entered.  This should either happen through a blank flash memory check or enabling the active state of the backdoor bootload pin.  I recommend you review SWRA466 and evaluate the sblAppEx or FLASH-PROGRAMMER bootload sequence before trying sbl_tool.bin, which I cannot confirm has been tested with the SIMPLELINK-CC13X2-26X2-SDK devices.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3356 points

    Hello ,

    I have studied the sbl_tool.bin application code, CC1352P ZNP application code & the Serial bootloader (section 10) in the CC1352P Technical Reference Manual & come to know following things.

    1. UBL commands (MT_RPC_SYS_UBL) for the CC1352 ZNP Application defined in the mt.hnot defined as 0x4D. but in the serial boot loader application it is more related to the MT_RPC_SYS_SBL.

    2. The backdoor bootload pin is activated by default in the CC1352P ZNP application stack ( see znp.syscfg -> TI DEVICES -> Device Configuration ) & the  backdoor bootload pin is DIO15 which is used as a Button1 on CC1352P-2 Lauch Pad.
    I have made some test cases by holding the button1 while reseting the CC1352P ZNP Device. Still not able to communicate with the device & getting same out put as posted in question.

    3. Aslo I have made a test case with the completely errased CC1352P ZNP device (with out any application code ) to communicate using the sbl_too.bin application. but getting the same results.

    Finally I came to the conclusions,

    1. Are the following functionality implemented on CC1352P ZNP stack? if not? what is their use case in the sbl_tool.bin application?
        1. zbSocSblHandshake()
        2. zbSocSblEnableReporting()

    2. How do I come to know, the Serial Bootloder Application is suitable & tested for the CC1352P ZNP Application?
        If not Please suggest me any example application.

    Regards,
    Shiv Patil.
  • 0 in reply to shiv patil
    TI__Guru**** 220377 points

    I looked further and found that 0x4D corresponds to the SB_RPC_SYS_BOOT of the CC2530/1 flash bootloader solution.  This is not compatible with the CC1352P and confirms my previous statement that sbl_tool.bin is not a solution for the SIMPLELINK-CC13X2-26X2-SDK devices.  I've already mentioned the available examples which you can further reference.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3356 points

    Hello ,

    As per your suggestion, I have made the following test cases.

    1. I have Programed the CC1352P ZNP device using FLASH-PROGRAMMER 2 via serial bootloader. It is working fine.

    2. I have found a sample example application of serial bootloader functionality for the CC1352P Device.

    https://www.ti.com/tool/download/TI-15-4-STACK-GATEWAY-LINUX-SDK

    With the help of the cc13xx-sbl Application, I am also able to program the CC1352P ZNP Module.

    Now I have a sample code for the serial bootloader application & it's working fine.

    But I would like to know more.

    1. Is the backdoor bootload pin is must needed for programming the CC1352P ZNP module.

    2. What is its effect on security while using this backdoor bootload pin.

    3. Is there any solution without using the backdoor bootload pin.

    Regards,

    Shiv Patil.

  • 0 in reply to shiv patil
    TI__Guru**** 220377 points

    Two conditions are possible, either the backdoor bootload pin must be enabled or the Flash image validation register in the CCFG parameter shows an invalid address for the device to enter the ROM bootloader, as shown in Figure 1 of SWRA466.  In regards to security, a secure boot/BIM implementation can be considered to verify integrity and validity of on-chip code execution if the ROM bootloader must remain enabled in the field.  More about the Bootloader and CCFG are provided in the TRM SWCU185.  Zigbee Security features are provided in SWPB022 and Secure Boot options are discussed in SWRA651.

    Regards,
    Ryan

  • 0 in reply to Ryan Brown1
    Genius 3356 points

    Hello ,

    I would like to know.

    out of 2 options, i.e (1.  backdoor bootload pin  & 2.  Flash image validation register).

    Which is a more secure & standard method of the serial bootloader to program the CC1352P ZNP device?

    Regards,

    Shiv Patil.

  • 0 in reply to shiv patil
    Guru 735695 points

    1. I think it's mandatory to use backdoor bootloader pin

    2. For, this field must have the address value of the start of the flash vector table in order to enable the boot FW in ROM to transfer control to a flash image. Any illegal vector table start address value will force the boot FW in ROM to transfer control to the serial bootloader in ROM.

  • 0 in reply to shiv patil
    TI__Guru**** 220377 points

    I imagine you will lock the JTAG for further security so erasing flash or altering the CCFG is not an option.  Therefore you can only enter through the backdoor bootload pin.  As discussed in SWRA651, you will use the secure BIM to verify validity of the firmware programmed via the ROM bootloader.

    Regards,
    Ryan