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.
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."
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.
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)
R0: 0xEDB88320R1: 0x00000001R2: 0xF72195D8R3: 0xEDB88320R4: 0x000223B5R5: 0x0002247BR6: 0x10001000R7: 0x00000000R8: 0x00000000R9: 0x00000000R10: 0x1FFF6000R11: 0x00000000R12: 0x00000000SP: 0x20005FD8LR: 0x0002B913PC: 0x0002793CxPSR: 0x21000000MSP: 0x20005FD8PSP: 0x00000000
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.
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.
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).
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.
brett_anderson said: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.
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.