Different SDK levels for Application and Bootloader

Question

Does it cause issues if the application was built with a different SDK level than the bootloader? I have a project I'm adding a bootloader to, and it isn't working. I have done over a dozen of these, yet I'm at a loss why I can't get this one working. One thing I noted that is different, is that the Application was built using SDK 15.2, while the Bootloader is currently setup to use SDK 15.3. The soft device is S112_v6.1.1. 
 
 I can obviously put them at the same level, but since the question has not been asked as far as I could find, I wanted to put the question on the forum for a real answer. This may not even be related to my issue, but I was curious.

Vidar Berg · Accepted Answer

Hello, 
 I don't foresee any problems with this as long as they are both built for the same Softevice. That said, it may be worth noting that in SDK 15.3.0 we started to store the Bootloader start and MBR parameters pages address inside the MBR (@0xff8 and 0xffc) instead of only using the UICR registers as we have done in the past. This was done to allow flash protection with BPROT/ACL, but it had the side effect that it made it easy to inadvertently erase the MBR during programming and thus "brick" the device. Have you checked if the first flash page may have erased? 
 This was fixed in SDK 16.0.0 by not including MBR data in the image, but rather writing it at runtime. From SDK release notes "Bootloader start address is now placed in UICR at compile time, and the MBR page is populated at runtime. This is to mitigate problems with flashing where the MBR was erased."

Vidar Berg · Answer

Thank you for the update. I agree that this is strange. The bootloader and app are separate programs and there are no interactions between them during boot that should have lead to any combability problems. Do you want to continue on 15.3.0, or do you want to spend some more time on finding the root cause?

Different SDK levels for Application and Bootloader

Top Replies