• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 51 subscribers
  • Views 546 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.

CCS/LAUNCHXL-CC1352R1: BLE not advertising after a SysCtrlSystemReset()

spanky
Expert 2710 points
Part Number: LAUNCHXL-CC1352R1

Tool/software: Code Composer Studio

I'm working from the ble5_simple_peripheral_oad_offchip example code.

I want to have the cc1352 run the OAD code, or run my own code. I don't want the OAD code to always run because its a waste of resources and a huge security issue. I tried gracefully shutting down the OAD stuff, but that was a dead end. Basically it seems you can't/shouldn't bring up individual ble services and take them down arbitrarily.

So now I'm trying a much simpler approach of setting a NVS flag and entering that mode on startup (either loading the OAD task, or my own tasks). I'm using SysCtrlSystemReset() to do the reboot.

In testing I greatly simplified things to see how the BLE deals with a SysCtrlSystemReset(). I'm basically just calling SysCtrlSystemReset() after 60 seconds. I "should" see the device advertising most of the time (minus time for the actual reset). It runs fine in the first execution, but then following the SysCtrlSystemReset(), it stops advertising entirely.

Is this the expected behavior for BLE following a SysCtrlSystemReset(), or am I doing something wrong?

  • 0
    TI__Guru 58425 points
    Hi Spanky,

    Are the debugger connected to the device in question when seeing this? When active, the ICEPick can stop the device after a warm reset in order to allow the user to debug the device. If this is the case, then the reset should work as expected if running the device without the debugger connected.
  • 0 in reply to IUsedToBeARealPerson (M-W)
    Expert 2710 points
    The debugger was connected physically, but I tried it with the debugger running and with it just powered (no debug session) with the same result.

    I kindof abandoned this approach since it appears turning off services dynamically can lead to other problems. I guess I'll cross the "unauthorized OAD" bridge when I come to it. It also looks like I can get the OAD to play nice with the DMM, which was another main reason for compartmentalizing the functionality (i.e. moving from one stack to another depending on what mode the device was operating in)