• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 1 answer
  • Subscribers 51 subscribers
  • Views 338 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.

CC2340R5: BLE Module Flashing via UART on Linux using SBL tool Succeeds but No BLE Advertising

Aman Yadav
Prodigy 100 points
Part Number: CC2340R5
Other Parts Discussed in Thread: UNIFLASH

Tool/software:

Hi TI team,

I'm working with a custom BLE module based on the CC2340R5 and attempting to flash it via UART using the cc2340-bsl.py script (Linux SBL tool: https://github.com/Shuyang-z/cc2340-bsl). While the script reports a successful flash and CRC verification, the module does not start BLE advertisement, which it is supposed to do after flashing.

Setup:

MCU: CC2340R5N0RGER (blank chip)

Host OS: Debian 11.11 

Flashing tool: cc2340-bsl.py 

Firmware file: .hex, built from BLE Peripheral example in the SIMPLELINK-LOWPOWER-F3-SDK v8.10.01.02

UART port: /dev/ttyUSB0

Baudrate: 115200

Connection method: USB-to-UART adapter (works fine with UniFlash and launchpad cc1252p7-1)

Flash command: python3 cc2340-bsl.py -p /dev/ttyUSB0 -b 115200 -e -w -v /home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex


Output:

python3 cc2340-bsl.py -p /dev/ttyUSB0 -b 115200 -e -w -v /home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex
Opening port /dev/ttyUSB0, baud 230400
Reading data from /home/ops/Downloads/basic_ble_LP_EM_CC2340R5_freertos_ticlang.hex
Firmware file: Intel Hex
Connecting to target...
Performing mass erase
Erasing all main bank flash sectors
Erase done
Write 64 bytes at 0x4E0207C0C8
Write CCFG done
Write 16 bytes at 0x0007FFF098
Write main flash done
Verifying by comparing CRC32 calculations.
Main flash verified (match: 0x21006695)
CCFG verified (match: 0x22ca400f)

Bootloader Entry and Reset:

DIO21 is pulled LOW before powering the module to enter bootloader mode (verified by acknowledgement upon sending 0x55 0x55)

After flashing, DIO21 is released (pulled HIGH with 10k resistor).

The RESET is done by the script, and I’ve also tried toggling it manually — still no BLE advertisement.

What Works: 

Flashing the exact same .hex file via UniFlash on Windows (using launchpad cc1352p7-1) results in correct BLE behavior — the device starts advertising immediately.

The script completes flashing and verification without any errors.

I doubt that the script writes the firmware on some address it is not supposed to.

I already checked the ccfg_address, ccfg_size, flash_size and page_size and they match in both the script and the firmware; and the script fails  if i change the addresses. 


Any guidance is appreciated — thank you!

  • 0
    TI__Expert 4340 points

    Hello,

    Thank you for reaching out! We will take a look at your issue and get back to you by Monday (5/18)

    Best Regards,

    Tarek

  • 0
    TI__Expert 4340 points

    Hello,

    Thank you for your patience! Quick question, have you been able to get another application working using the same flashing process? Also, if possible, could you attempt this with the newest SDK or the 8.40 SDK?

    Answering these questions will help us with pinpointing the issue.

    Best Regards,

    Tarek

  • 0 in reply to Tarek D
    Prodigy 100 points

    Hi,
    Thanks. I attempted it with SDK v8.40.02.01. The hex file was flashed successfully and my device is now advertising as intended. However, I wanted to ask you why the flashing wasn't being done when the same hex file was generated using the previous versions of the SDK. Most of our projects are built on the earlier version of the SDK so we want the SBL tool to work with those projects as well.

  • 0 in reply to Aman Yadav
    TI__Expert 4340 points

    Hello,

    I'm glad to hear it's working! I'm not completely sure why this was happening on the 8.10 SDK, could be for any number of reasons. If this is an issue that is preventing you from moving forward in your development/ production process I can attempt to look into it.

    However, I would always recommend migrating to a newer SDK, as that will include fixes to a lot of the bugs seen in earlier versions. If you'd like help migrating to the 8.40 SDK, please refer to our User's migration guide section:

    https://dev.ti.com/tirex/explore/node?a=58mgN04__8.40.00.61&node=A__AJK4IB6.SQXkn4DIcgE1hA__com.ti.SIMPLELINK_LOWPOWER_F3_SDK__58mgN04__LATEST

    I hope this helps!

    Best Regards,

    Tarek

  • 0 in reply to Tarek D
    Prodigy 100 points

    Hi,
    We have some devices which are already in production, the firmware for which has already been developed on the previous versions of the SDK. We also have to ship them out to our clients on an urgent basis. While we will ensure to use the latest SDK version for our upcoming projects, it would be really nice of you if you could let us know what was causing this issue in the first place.
    Thank you so much for your guidance.

  • 0 in reply to Aman Yadav
    TI__Expert 4340 points

    Hello,

    I will look into this and let you know ASAP!

    Best Regards,

    Tarek