• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 54 subscribers
  • Views 1131 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: Using Serial Bootloader

Tim Harvey9
Intellectual 535 points
Part Number: CC1352P
Other Parts Discussed in Thread: UNIFLASH, CC1350, CC1352R

I'm trying to understand how to use the CC1352P Serial Bootloader. I've got an application that implements the serial bootloader API but I'm not clear where to start programming the application I'm building.

I've looked in the CC1352P datasheet and TRM and can't quite understand the memory map.

Not that it should matter but I'm starting with simplelink_cc13x2_26x2_sdk_2_40_00_81/examples/rtos/CC1352P_2_LAUNCHXL/easylink/rfEasyLinkNp which I'm building with TI's gcc:

cd ~/ti/simplelink_cc13x2_26x2_sdk_2_40_00_81/

make -C kernel/tirtos/builds/CC1352P_2_LAUNCHXL/release/gcc # rfEasyLinkNp requires the TIRTOS kernel
make -C examples/rtos/CC1352P_2_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc

cd examples/rtos/CC1352P_2_LAUNCHXL/easylink/rfEasyLinkNp/tirtos/gcc
arm-none-eabi-objcopy -S --gap-fill 0xff -O binary rfEasyLinkNp.out rfEasyLinkNp.bin
arm-none-eabi-objcopy -S -O ihex rfEasyLinkNp.out rfEasyLinkNp.hex

  • 0
    Guru 735685 points
    You can refer to www.ti.com/.../swra466a.pdf for serial boot loader
  • 0 in reply to YiKai Chen
    Intellectual 535 points
    Yes, I've looked through that document but I don't see memory map details for the CC1352P.

    For the CC1352P what is the address of the main application code and where is the Bootloader configuration address?

    Tim
  • 0 in reply to Tim Harvey9
    Guru 735685 points
    Serial boot loader of Cc1352P would write binary into address 0x0.
  • 0 in reply to YiKai Chen
    TI__Guru**** 317180 points
    Have you read the release notes on the SDK? Also see e2e.ti.com/.../767774

    If I understand the question correctly, you want to generate a hex file that you use the bootloader to flash the device with. In that case the linker file should ensure that the hex file is generated correctly.
  • 0 in reply to YiKai Chen
    Intellectual 535 points

    Thanks, this helps and I'm likely close now to my goal.

    Using the rfEasyLinkNp_CC1352P_4_LAUNCHXL_tirtos example:

    - I'm creating a bin file from the ELF object (.out) file produced by CCS with 'arm-none-eabi-objcopy -S --gap-fill 0xff -O binary output.out output.bin'.

    - I'm also setting the following in my ccfg.c 'before' the include of startup_files/ccfg.c to enable the bootloader:

    #define SET_CCFG_BL_CONFIG_BOOTLOADER_ENABLE 0xc5 // Enable ROM boot loader
    #define SET_CCFG_BL_CONFIG_BL_LEVEL 0x1 // Active high to open boot loader backdoor
    #define SET_CCFG_BL_CONFIG_BL_PIN_NUMBER 5 // DIO5
    #define SET_CCFG_BL_CONFIG_BL_ENABLE 0xc5 // Enabled bootloader backdoor

    - when I hexdump the output.bin I do indeed see a 0xc5 at 0x57fd8 as expected

    - I'm using sflash.c that I found in the Tiva Development SDK which appears to implement COMMAND_ACK, COMMAND_PING, COMMAND_DOWNLOAD, COMMAND_SEND_DATA, COMMAND_RUN, COMMAND_RESET, COMMAND_GET_STATUS from the Bootloader API to program and it does appear to program over the UART

    After programming rfEasyLinkNp.bin with sflash, de-asserting BL_BACKDOOR and toggling RESET# I am opening the UART (same UART that sflash uses to program the part) and expecting to see response to the EasyLink 'AT+I 00\r' command but don't see anything and am not even sure if the code on the CC1352P is running.

    Anything above you can see wrong with my steps? Is Board_UART0 that the rfEasyLinkNp example using the same UART that the Bootloader would be using?

    Thanks,

    Tim

  • 0 in reply to Tim Harvey9
    TI__Guru**** 317180 points
    Could you first confirm that you are using the correct SDK version vs the chip revision you are using?
  • 0 in reply to TER
    Intellectual 535 points
    The end product is a custom board with a CC1352P with UART0 connected to an IMX6 SoC (pinned out the same way as the CC1352P_4_LAUNCHXL).

    However, I have a CC1352R1 Development Kit (CC1352R1_LAUNCHXL) as well that may be exhibiting the same issues so lets fall back to that:
    - board: CC1352R1 Development Kit (CC1352R1_LAUNCHXL)
    - sdk: simplelink_cc13x2_26x2_sdk_2_40_00_81 SDK
    - ccs: 8.3.0.00009
    - uniflash: uniflash_4.6.0
    - example: rfEasyLinkNp_CC1352R1_LAUNCHXL_tirtos_ccs_syscfg

    If I build rfEasyLinkNp_CC1352R1_LAUNCHXL_tirtos_ccs_syscfg and flash it to the CC1352R1_LAUNCHXL using UniFlash I can not communicate with the ttyACM0 via the EasyLink AT API - the UART is not echoing characters at all or responding to 'AT+I 00'.

    Perhaps there is something wrong with the SDK as I also have a CC1350_LAUNCHXL and find that if I build rfEasyLinkNp_CC1350_LAUNCHXL_tirtos_ccs and flash it to the CC1350_LAUNCHXL the same way it works as expected - the UART echo's characters and responds to 'ATI+I 00' as expected.

    Tim
  • 0 in reply to Tim Harvey9
    Guru 735685 points

    To use simplelink_cc13x2_26x2_sdk_2_40_00_81 SDK, you should use rev.E CC1352R1 and CC1352P. Make sure you use rev.E chips.

  • 0 in reply to YiKai Chen
    Intellectual 535 points

    YiKai Chen said:

    To use simplelink_cc13x2_26x2_sdk_2_40_00_81 SDK, you should use rev.E CC1352R1 and CC1352P. Make sure you use rev.E chips.

    Ok, using simplelink_cc13x2_sdk_2_30_00_45 'does' resolve the issue I have when using the CC1352R1 Launchpad that has the CC1352R revC and I'm also now able to get code running on the CC1352P on my custom board when programmed with the bootloader.
    Why on earth does the most recent SDK not support the earlier rev silicon? It was even difficult for me to find the older versions of the SDK.
  • 0 in reply to Tim Harvey9
    Guru 735685 points

    For chip revision explanation, you can refer to and you should be able to download different version of SDK from Resource Explorer.

  • 0 in reply to YiKai Chen
    Intellectual 535 points

    Ok, this still doesn't explain 'why' TI will no longer suport Rev C silicon.

    However my original question is now answered.