NRF52 boot sequence problems when adding S132

Question

I have been developing my application using gcc on an NRF52 by putting the text section at 0. This was convenient to get going quickly. We initially weren't going to launch with any BLE support but now we need it - quelle surprise. 
 Now I've flashed in the S132 BLE stack in at address 0 (I see nrfjprog flash it up to 0x20000). I changed the starting address of my application to 0x20000 and rebuilt. I haven't flashed in the bootloader but the S132 device should boot and see the UICR is unprogrammed (0x10001014 magic bootloader location is all 0xFFs) and just boot to 0x20000. Is that a correct assumption or do I need to do anything else to get that simple step working? 
 I would think that getting the S132->application boot sequence should be easy. I've tried putting the bootloader in but it makes no difference.

msglamarca · Accepted Answer

I'll answer my own question instead of closing it just in case someone else finds it useful (thanks for the comment, Bjorn). 
 It turns out that while I was placing the text correctly after the Soft Device at 0x20000, I was using all of the RAM (ORIGIN = 0x20000000, LENGTH = 0x10000) which was probably crushing the S132 Soft Device's background RAM usage. I found the RAM area used by a BLE peripheral app's linker file: 
 RAM (rwx) : ORIGIN = 0x20002168, LENGTH = 0xde98 
 Even though I'm not using any BLE functionality, I'm guessing the nrf52 still goes back into the S132 periodically regardless. My application may have initialized correctly but the first time it went to the S132, its memory was hosed and it never came back.

NRF52 boot sequence problems when adding S132

Top Replies