• State Verified Answer
  • Replies 11 replies
  • Subscribers 62 subscribers
  • Views 1533 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 246904
Options
Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Different SDK levels for Application and Bootloader

brett_anderson

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.

  • +1

    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."

  • 0 in reply to Vidar Berg

    Thanks Vidar,

    I want to update you that I did change the application to use SDK 15.3, and that fixed the problem. I am very surprised by this. I have a couple applications for the nRF52810. This application was created when 15.2 was current, but never had a bootloader. I have another project that was done with 15.3, and did include a bootloader. When I moved over the bootloader build on 15.3, it did not work. The soft device would just jump to a bad location. Recompiling the application with 15.3, and everything seems tow work.

    Strange, but I did nothing else. 

  • +1 in reply to brett_anderson

    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?

  • 0 in reply to Vidar Berg

    I don't mind doing some more testing. I was honeslty thinking I would just update both to 16 since I was updating.

  • 0 in reply to brett_anderson

    Ok, good. Were you able to see if the program reached the bootloader or if it crashed before that? The latter would indicate that a wrong start address had been stored in MBR/UICR so would want to exclude that possibility first. 

    A readout of the CPU registers when it has crashed may give some more clues about what is wrong. If you use nrfjprog you can run 'nrfjprog --readregs' to get all of the registers.

Related