Dear Support Team,
I'm working on a BLE application and the most stuff works well but now I had a spurious application crash at "src\ll_lm.s0.c: 1038". Could you please check what kind of assertion has been failed here? I was using the 6.0.0.1-alpha S110 softdevice.
Thank you in advance, Peer.
Do you have an application that consistently triggers this assert? If so, I'd be happy to have a look at the source code and trying to replicate it. If you don't want to share the source code here in public, feel free to post a support case and include it there. Any code submitted there is handled in confidentiality.
If this issue only occurs seldom, this could already be covered by a recent fix for a race condition, that will be included in an upcoming softdevice release.
The problem occured only twice within two weeks (one time with the usb breakout board and once with my custom board. Currently I'm not able to reproduce it all. It occured after a relatively long time of successfully operation with only a few BLE attribute changes / connect / disconnect events from host side.
If I understood you correctly there is a chance that the most recent version of the Softdevice already fixes this (issue)? If you wan't I could share the my sources. (In a non-public way). Please tell me where to submit the stuff. 'P
This fix is unfortunately not yet included in a public release. However, if you can, please submit your code in a support case here: https://www.nordicsemi.com/eng/supportcase/create
Ok, the problem occured reproducable in a bit different manner: src\ll_lm.s0.c: 783 Code: 48879 Occurs everytime when I delegate an irq handler (UART0) to a c++ method like: gpApp->mainMCUService.isrUARTRcv(NRF_UART0->RXD);
The line numbers are sometimes different in src\ll_lm.s0.c. I also use c++ delegates together with the timer framework (app_common/timer.c) without no problems or do you see there can be a association with the previous error? The c++ methods are very small (and fast). Maybe a stack problem?
Ok, the problem occured reproducable in a bit different manner: src\ll_lm.s0.c: 783 Code: 48879 Occurs everytime when I delegate an irq handler (UART0) to a c++ method like: gpApp->mainMCUService.isrUARTRcv(NRF_UART0->RXD);
The line numbers are sometimes different in src\ll_lm.s0.c. I also use c++ delegates together with the timer framework (app_common/timer.c) without no problems or do you see there can be a association with the previous error? The c++ methods are very small (and fast). Maybe a stack problem?
