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.

[apolcari]

For the application, I followed the s110_nrf51 migration document to make changes to the application. The result was the code compiled and when running in the debugger (after loading SoftDevice 8.0.0) it works. I am using IAR Embedded Workbench IDE for the application. I changed the linker file to a ROM start address of 0x18000. I left the end address at 0x3EFFF (for a size of 0x26FFF). I did not change the RAM settings (start address 0x20002000, end address 0x20003FFF (for a size of0x1FFF). I used IAR to build a hex file. I then used nRFgo to: 1) erase all, 2) flash SoftDevice 8.0, 3) flash application (hex file generated by IAR).

Per nRFgo Studio, the original device appears to have the SoftDevice 6.0.0 in Region 0 with an allocated space of 80 kB (max address 0x14000) and the application in Region 1 with an allocated space of 176 kB. My changes are trying to put the SoftDevice in Region 1 with an allocated space of 96 kB (max address 0x18000) and the application also in Region 1 with an allocated space of 160 kB. I point this out because I'm wondering if there's an issue related to the original SoftDevice using Region 0.

[Stefan Birnir Sverrisson]

Im glad that you can run your application with the new softdevice.

I dont however understand your latter question. What is your motivation to place the S110 8.0.0 in code region 1? Softdevice should be in code region 0 and the application should be in code region 1.

[apolcari]

Well, my original problem still exists. I can only run the application when using the debugger. If I flash the device and then try to run, it does not work. I did change the SoftDevice to be in code region 0 and the application in code region 1, but it still does not work. Any suggestions?

[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