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

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.

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

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

Children
  • 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. 

  • 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?

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

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

  • I can't tell where it crashes, but I can tell that it doesn't start the application.

    Bootloader DFU Settings:
    * File: _settings.hex
    * Family: NRF52810
    * Start Address: 0x0002F000
    * CRC: 0xDBB9F8F6
    * Settings Version: 0x00000002 (2)
    * App Version: 0x00002906 (10502)
    * Bootloader Version: 0x00000001 (1)
    * Bank Layout: 0x00000000
    * Current Bank: 0x00000000
    * Application Size: 0x0000947C (38012 bytes)
    * Application CRC: 0x94D9A66C
    * Bank0 Bank Code: 0x00000001
    * Softdevice Size: 0x00000000 (0 bytes)
    * Boot Validation CRC: 0x02D484E4
    * SD Boot Validation Type: 0x00000000 (0)
    * App Boot Validation Type: 0x00000001 (1)

    readregs:

    R0: 0xEDB88320
    R1: 0x00000001
    R2: 0xF72195D8
    R3: 0xEDB88320
    R4: 0x000223B5
    R5: 0x0002247B
    R6: 0x10001000
    R7: 0x00000000
    R8: 0x00000000
    R9: 0x00000000
    R10: 0x1FFF6000
    R11: 0x00000000
    R12: 0x00000000
    SP: 0x20005FD8
    LR: 0x0002B913
    PC: 0x0002793C
    xPSR: 0x21000000
    MSP: 0x20005FD8
    PSP: 0x00000000

Related