• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 51 subscribers
  • Views 261 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: Stack crash on connected CC2340R5

Patrick Herborn
Intellectual 530 points
Part Number: CC2340R5

Tool/software:

Think this might be one for the TI engineers, not sure the relevant code is open source.... [based on SimpleLink Lowpower F3 8.10.1.2]

Scenario : CC2340R5 acting as a UART <> BLE bridge, MTU negotiated to allow a maximum GATT Notify payload of 244 bytes, with around 100 frames per second. The code is based upon the data_stream_UART_over_BLE example. There are no issues so long as nothing is connected to the device - it will run indefinitely, nicely toggling an LED for each frame that arrives at the UART (but then obviously doesn't have anywhere to go). When connected it continues to work fine - until the signal strength is reduced to the point it can't communicate any more. At this point the stack crashes.

The backtrace shows :

BLEAppUtil_Task()

SendUARTOverBLE()

DSP_sendData()

DSS_setParameter()

DSS_sendNotification()

icall_directAPI() [GATT_Notification() is #defined to icall_directAPI() with index 258]

ICall_abort() as a result of ICall_waitMatch() returning ICALL_ERRNO_TIMEOUT.

Of course ICall_abort() doesn't return so that effectively ends the BLE task. Increasing the signal strength again and manually allowing ICall_abort to return within the debugger does not resolve the issue, the device is still "dead" (ie no further LED activity and no advertisements, albeit FreeRTOS is still task switching).

My gut feeling is that the stack can't cope with the new data since there aren't any connection events which could drain the enqueued Notifies, but it doesn't seem to be failing gracefully. It's also not clear how to gracefully recover from this condition (returning from ICall_abort() doesn't work). For my part, it would be OK for the stack to gracefully say "nope, can't do that", ditch the Notify, tear down the connection and go back to just advertising, waiting for a new connection. Theoretically, if GATT_Notification() did return something other than SUCCESS, DSS_sendNotification() would free() the malloc()ed memory so there wouldn't be any memory leak as a result - but of course it never returns.

Any and all help very much appreciated.

Many thanks,

Patrick Herborn.

  • 0
    TI__Genius 15535 points

    Hello Patrick,

    Thanks for reaching out. I assume you are running the example over 7.40 SDK? I agree that the device should fail gracefully and in this case potentially go back to advertising. I would please suggest to migrate to the latest SDK as several improvements have been implemented around this.

    You can see the migration guides here:

    CC23xx SDK 7.40 to CC23xx SDK 8.10: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.20.00.119/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/migration-cc23xx.html

    CC23xx SDK 8.10 to CC23xx SDK 8.20: https://software-dl.ti.com/simplelink/esd/simplelink_lowpower_f3_sdk/8.20.00.119/exports/docs/ble5stack/ble_user_guide/html/ble-stack-5.x-guide/porting-guides/cc23xx/CC23XX_SDK_8.10_to_8.20.html

    BR,

    David.

  • 0 in reply to David
    Intellectual 530 points

    Hiya David!

    Many thanks for coming back to me on this and also for the linked docs and suggestion.

    For the avoidance of doubt, that SDK version is 8.10.1.2 as noted at the top of my post, but it would seem sensible, given that there looks to be an 8.20 version now, to try to upgrade to that and have another go, see if that is more stable. I think you may be right that the example was originally built against 7.40 (though I never had 7.40) - it is likely wise for me to double check that I didn't miss anything when getting it to build against 8.10.1.2, so thanks for the link. I shall study both and see if it can be persuaded to behave itself.

    Many thanks again,

    Patrick Herborn.

  • 0 in reply to Patrick Herborn
    TI__Genius 15535 points

    Hello Patrick,

    Sounds good! Just wanted to clarify with you if you are using the data_stream_UART_over_BLE as reference to port to your own project or actually you are using it out of the box: https://github.com/TexasInstruments-Sandbox/ble_examples/tree/simplelink_low_power_f3_sdk-7.20/examples/rtos/LP_EM_CC2340R5/ble5stack/data_stream_UART_over_BLE (which is not running the latest SDK version). Another question, how do you know there is a memory leak? Could you please take a look at ROV following this steps to confirm this?

    You dont see any type of disconnection issued by either of the devices? Do you happen to have a sniffer log?

    Patrick Herborn said:
    until the signal strength is reduced to the point it can't communicate any more.

    BR,

    David.

  • 0 in reply to David
    Intellectual 530 points

    Hiya David,

    Many thanks for your response. I was using data_stream_UART_over_BLE out of the box on the CC2340R5 LaunchPad to prove a point, then the project was tweaked for custom hardware. I do not recall ever using an SDK earlier than 8.10 for this, so I would have been using that even with the LaunchPad. I don't recall specifically now what I had to do to make it build against that version of the SDK (bit of a shame since I may have to do something similar for 8.20).

    With regard to a memory leak, apologies if I confused the situation. I do not believe that there is one at present (since it just crashes) - I was commenting on the fact that if it did fail gracefully then there is code in the call stack that would free() the memory it had malloc()ed so that should prevent any memory leak in the event that it was able to gracefully fail. Of course as written it cannot gracefully fail so that code can never execute right now.

    I could try to get my sniffer back up and running, it would be interesting to see what happens on the air, but in the first instance let's see what happens against 8.20...

    Many thanks again,


    Patrick Herborn.

  • 0 in reply to David
    Intellectual 530 points

    Hello again David,

    I am pleased to report that changing from the 8.10 to the 8.20 SDK appears to have resolved the issue. It does not appear to crash the stack any longer. It still needs more thorough testing but thus far I have been able to recover a connection that went out of range and then also have a connection break when going way out of range but the device continue gracefully, advertising and allowing a fresh connection.

    It was interesting that some of the breakpoints I had previously set would not longer work as the files were rather shorter than they were and hence the referenced line numbers no longer existed - clearly there has been considerable work under the hood between releases.

    Apologies for potentially wasting everyone's time with this - I should have checked if there was a newer SDK before posting - lesson learnt (and maybe this might help someone else).

    Many thanks again,

    Patrick Herborn.