Problem migrating existing setup from SoftDevice S110 v6.0.0 to S110 v8.0.0.

[apolcari]

I have an existing working application running on a board with a Nordic Semiconductor NRF51822-QFAA CPU on it. The CPU is already programmed with (1) a SoftDevice S110 v6.0.0 (BLE stack) and (2) application software that allows monitoring using BLE. I need to migrate to a newer version of the BLE stack (SoftDevice S110 v8.0.0) to allow new features (firmware upgrade via BLE). Using nRFgo studio, I tried erasing the part, then flashing the new SoftDevice (S110 v8.0.0), then flashing the updated application (I made changes to the application to support the new SoftDevice). I could not get my setup to work. I can run the application using the debugger, but just flashing the application (after loading the SoftDevice) doesn't work. My question is whether my setup should work. Or, will I need to start with a CPU that has NOT been programmed with an earlier version of a SoftDevice. Thx.

[Stefan Birnir Sverrisson]

Hi apolcari

What changes have you actually performed to make your application fit with the new softdevice? S110 8.0.0 has different size and therefore you need to change the iROM start address and size of the application accordingly. You don't need to change iRAM settings if you intend to continue using QFAA with 16kB RAM.

The S110 8.0.0 also has different API than S110 6.0.0, so you need to go through the release notes and/or softdevice migration guides for S110 7.0.0 and S110 8.0.0 to realize the changes that have been made between S110 6.0.0 and S110 8.0.0 and what modifications need to be made in your application to cope with those changes. Only some of the API changes might effect your application, depending on what modules your application is using. You must replace the BLE header files in your application with S110 8.0.0 header files that reflect the S110 8.0.0 API. You will find the header files in the \s110_nrf51_8.0.0\s110_nrf51_8.0.0_API\include\ folder in the S110 8.0.0 softdevice archieve.

[Stefan Birnir Sverrisson]

If the problem is only present when not debugging I suspect there is a race condition of some sort in your application. Execution timing may be slower when running in debugger. You could try to run the application with printing messages on the UART, to identify when the problem occurs when not in debug mode. In SDK 8, tracing is enabled only if ENABLE_DEBUG_LOG_SUPPORT is defined in the project, see the SDK 8 documentation