SoftDevice 6.0.0 to 6.1.X migration

[josh-m]

Hello,

I'm trying to update the SoftDeivce used on our product from s140 v6.0.0 to 6.1.1, but am running into issues. Per the release notes it sounds like no updates / recompilation of our application code should be necessary for this upgrade. However, when I erase our chip and flash either 6.1.0 or 6.1.1 onto the device, and then flash our application code, I get a "SOFTDEVICE: ASSERTION FAILED" message in the log shortly after the system starts up. I don't believe the SoftDevice is throwing any errors during init, everything seems to be working the same as it did before the attempted SoftDevice upgrade..

We are running FreeRTOS on the device, and using a lot of the peripherals, but I thought we were in good shape as far as obeying all of the resource limitations imposed on the app code when the SD is enabled. Were there any changes to what SoC resources the SoftDevice uses between 6.0.0 and 6.1.X? I looked through the SD Spec document's revision history and didn't see anything obvious that jumped out at me. 

Our application is fairly mature and the code is pretty stable, so I'm not really sure what else it could be. Any thoughts on what I might be missing?

Thanks,

Josh

[BinderT]

Just a shot in the dark.
Have you enable the compiler debug flag (CFLAGS += -DDEBUG) with NRF_SDH_BLE_LOG_ENABLED 1 in the sdk config. This will tell you if the SD requirements need to be adjusted in the linker.
Provided the following is set correctly in the sdk config.

NRF_SDH_BLE_PERIPHERAL_LINK_COUNT
NRF_SDH_BLE_CENTRAL_LINK_COUNT
NRF_SDH_BLE_TOTAL_LINK_COUNT
NRF_SDH_BLE_GAP_EVENT_LENGTH
NRF_SDH_BLE_GATT_MAX_MTU_SIZE
NRF_SDH_BLE_GATTS_ATTR_TAB_SIZE
NRF_SDH_BLE_VS_UUID_COUNT
NRF_SDH_BLE_SERVICE_CHANGED

Good rule of thumb I found when using FreeRTOS on the NRF52s is to chuck 32K at the TOTAL_HEAP_SIZE and reduce when application is done.

[josh-m]

We have the -DDEBUG flag set, and I flipped on NRF_SDH_BLE_LOG_ENABLED for a build and didn't see any new warnings/errors at compile or build time. We're already throwing over 50 kB at the heap, so I don't think that's the issue. If it was, I don't think things would fail so consistently.

I traced a bit further into things, and it seems like the PC passed into the error handler is always 0x14a3a (for SD 6.1.0). Hoping someone from Nordic can provide me a hint based off of what might be going on in the SD at that address.

I also noticed that things seem to be pretty consistently failing at a freeRTOS app_timer_stop() call. Not sure what to make of that, the exact same logic causes no issues when running against the 6.0.0 SD. The timer is definitely properly initialized, I tired a build with a bigger max timer queue size and timer task stack size (FreeRTOSConfig.h) and it didn't make any difference.

Thanks,

Josh