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.

[brett_anderson]

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

[Vidar Berg]

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.

[brett_anderson]

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.

[Vidar Berg]

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

[brett_anderson]

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.