Issue with Application loading after migration from SDK 14.2 to SDK 15.3

[Adam Gordon]

I am running custom firmware on a custom board using an nRF52832 chip. I have encountered an issue after migrating my project from SDK 14.2 to SDK 15.3. The issue is that my application is not starting and it occurs on two different occasions:

1. After successfully performing an OTA DFU using a secure ble bootloader, my application doesn't run. The DFU is performed successfully but after nrf_bootloader_app_start() is called, is does not load my application.
2. If my application is loaded and running on my device and the device is removed from power and then plugged back in, the application does not startup.

With that being said, if I merge the .hex files of the BL, BL settings, SD, and APP and flash them onto my device using nrfjprog, my application is loaded and runs properly. If I then remove my device from power and plug it back in, the application no longer starts. Loading the same bootloader and softdevice and then performing a DFU with my application does not successfully start my application either.

I tried both above scenarios with an example app from the SDK (blinky) which I modified to run on my custom board, and everything worked correctly. I was able to perform a DFU and have the application start, and if I power cycled the device, the app restarted.

This functionality used to work fine with my app when it was using SDK 14.2, it has only broken since migrating to SDK 15.3. Is there something that has changed that I need to be aware of?

Any help with the issue would be greatly appreciated.

[Hung Bui]

Hi Adam, 

I assume you have your own private key use with your bootloader ? You mentioned that you can do OTA DFU with your application ? 

If you want to test the flash_fds you should either generate a .zip file of the hex or generate at bootloader setting. I attached here the .zip file and the bootloader setting I used. Saw no issue with the example. 

Could you please double check what exactly return in flash_end_addr() ?  when you have the bootloader installed and the application installed. 

Especially check if you have this inside app_util.h

#define BOOTLOADER_ADDRESS      ((*(uint32_t *)MBR_BOOTLOADER_ADDR) == 0xFFFFFFFF ? *MBR_UICR_BOOTLOADER_ADDR : *(uint32_t *)MBR_BOOTLOADER_ADDR) 

The bootloader address should point to the start address of your bootloader. 

I suspect that since we don't write to MBR_UICR_BOOTLOADER_ADDR  any more it could cause an issue if you don't have correct  BOOTLOADER_ADDRESS       macro . 

flash_fds.hexbootloader_settings.hex

[Adam Gordon]

Hi Hung,

Good point, I have my own set of public/private keys that I will use with the examples to test the flash_fds app. 

As for the BOOTLOADER_ADDRESS macro, unfortunately I’m currently not in the office, but I looked into it a lot yesterday so will try to respond from memory to see if we can resolve this issue today. 

Yes we do have that macro inside app_util.h. I believe MBR_BOOTLOADER_ADDR was 0xFF8, pointing to a value of 0xFFFFFFFF. flash_end_addr() ended up returning 0x80000 because one of the lines of code has something that resembled two _sz being multiplied together. 

I’m sorry if that’s not 100% detailed or clear, I’m going off memory, but I wanted to be able to respond before you left for the day. I’m not in tomorrow and would like to get this resolved before the weekend, if possible. 

Thanks. 

[Adam Gordon]

Hi Hung,

I was able to be in touch with one of your colleagues in Anaheim today, and they helped me work through some of the details of this issue. Essentially the MBR_BOOTLOADER_ADDR loaded into memory location 0xFF8 was correctly set at 0x78000 when the softdevice and bootloader were loaded, but for some reason, when using Segger to load the application, the value in 0xFF8 was being overwritten to 0xFFFFFFFF.

However, that did not happen when the app was loaded via nrfjprog or via DFU (the value remained 0x78000). So that was significantly throwing off our troubleshooting. I am now working through the issue with that knowledge in mind to better isolate the main problem.

[Hung Bui]

Hi Adam, 

It's really strange that the application would touch the MBR area. Do you have any code that may set the attribute to the MBR address (0-0x1000) ? 

If you can provide the hex file that reproduce the problem I can have a look. 

[Daniel Veilleux]

Hello Hung, it wasn't that the application was modifying the MBR -- SES was erasing the MBR page and reflashing the SoftDevice when Adam started the debugger. Using Target -> Attach prevents SES from modifying the flash.