Different SDK levels for Application and Bootloader

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Fri, 27 Mar 2020 13:10:43 GMT

Thank you!

[quote userid="18108" url="~/f/nordic-q-a/59543/different-sdk-levels-for-application-and-bootloader/242091"]When that was working, the space was so constrained on the application that the peer manager was failing trying to init fds. This was the curve ball as to why it worked when I tested individually, but failed on a merge.[/quote]

Maybe not what happened in your case, but FDS may fail to re-claim pages during init if they have been completely or partially overwritten during the DFU process. It is important to make sure the NRF_DFU_APP_DATA_AREA_SIZE matches the FDS_VIRTUAL_PAGES setting used by the application to prevent this.

RE: Different SDK levels for Application and Bootloader

brett_anderson — Fri, 27 Mar 2020 12:45:36 GMT

I've done a few of these, at quite a few sdk levels. They all have their quirks, but I think you guys have done a good job of improving things over time.

While I'm not 100% certain what was wrong, I did just start the project over from scratch using 16. I was able to find a few things that were probably wrong in the earlier one. I think the MBR was written wrong, and I was missing the populate call. When that was working, the space was so constrained on the application that the peer manager was failing trying to init fds. This was the curve ball as to why it worked when I tested individually, but failed on a merge. Why it sometimes worked after a power off, I have no idea. going to put this one to rest and move on.

Since the original question was about mixing SDK levels, I'm going to mark as solved with those answers. Thank you for your support! You guys are great.

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Fri, 27 Mar 2020 07:52:09 GMT

Very interesting that it behaves differently depending on the reset source(Reset behavior). I cannot think of anything that could explain this behavior. The program should also not get stuck in the crc32_compute() function. So maybe it's going in a reset loop and the crash is really happening after the checksum calculation.

I know the bootloader can be a bit tricky to debug as the compiler optimization has to be enabled, but was this more of an Eclipse problem? Do you have an eclipse project for the bootloader, or is it built directly with makefiles? Segger Ozone (quick to setup and use) / GDB can be good alternatives if you just want to debug existing executables (.out/.elf).

RE: Different SDK levels for Application and Bootloader

brett_anderson — Thu, 26 Mar 2020 14:36:36 GMT

I can't debug the bootloader, as it never seems to get there when I try. I've had poor luck using Eclipse for bootloader debug.

The dissassembly shows that to be inside of crc32_compute()

It is interesting. From a power off to on, it works. If I try a nrfjprog --reset or --pinreset, it does not.

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Thu, 26 Mar 2020 14:21:19 GMT

Assume the current program counter (PC: 0x0002793C) in your bootloader's address range? If it is, do you know how to look up the address and see which function you have at this location (disassembly view in IDE, addr2line, etc)? I don't see anything else that's wrong.

RE: Different SDK levels for Application and Bootloader

brett_anderson — Thu, 26 Mar 2020 13:54:13 GMT

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

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Thu, 26 Mar 2020 13:43:04 GMT

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.

RE: Different SDK levels for Application and Bootloader

brett_anderson — Thu, 26 Mar 2020 13:31:08 GMT

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

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Thu, 26 Mar 2020 13:29:45 GMT

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?

RE: Different SDK levels for Application and Bootloader

brett_anderson — Thu, 26 Mar 2020 13:06:48 GMT

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.

RE: Different SDK levels for Application and Bootloader

Vidar Berg — Thu, 26 Mar 2020 12:18:57 GMT

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