bootloader doesnt start application

[Juliusc]

there is some weird behavior on my XIAO nrf52840. Im developing omn skd 15.3 am using a secure bootloader.

all of my dfu OTA processes work well but I noticed that some of my chips wont start the application from the bootloader. to be precise I can debug the bootloader up to this pont: 

ASSERT((dst_addr % CODE_PAGE_SIZE) == 0);

in the nrf_bootloader_fw_activation.c file (line 81)

after this line the bootloader goes back to its start. this doesnt happen on every chip though so I dont know whats happening at all. 

The flash readings of a chip that works and one that doesnt are identical for my firmware.

[Naeem Maroof]

Hi Julius,

Thank you for contacting DevZone at NordicSemi.

As you have mentioned that only some of the chips would not start as expected, it could be due to issues in the hardware board.

I am not sure what could be wrong here, as you have successfully tested it previously.

[Juliusc]

do you know what could possibly happen in the hardware that such an issues would occur? it seems like a software issue at first glance, but obviously I know that two chips Ive tested should have the same flash contents. 

[Naeem Maroof]

Honestly, I have never used that board before. 

You can also read the chip contents and compare both hex files to confirm that. 

[Juliusc]

ok understand. I did do a readcode comparison, the firmware is identical, the differences are the following:

can I work something out from this? bootloader settings seem different but I couldnt tell why if i downloaded the same firmware and also OTA'd the same firmware after

[Naeem Maroof]

Can you check two working chip firmware as well to see it everything is identical?

Are there any differences in flashing the firmware to the chip? 

[Juliusc]

there is no difference in two working chips.

flashing no, dfu some with android some with iOS but besides that no difference. 

[Naeem Maroof]

Depending upon the nature of the code, and other configurations & tools, there could be differences in the hex file output of different builds. However, I am assuming that you are flashing the same hex file (no rebuilding) to all of your boards, and also using the same procedure and platform (e.g. from the same PC and using the same method etc.).

And then after flashing you have some good boards and some not working good.

Good working boards have identical firmware when read-back

Not working boards have some discrepancies when firmware read-back

This would typically be the case that there are some issues with the boards, not with the software and tools, but with the hardware.

Can you test your "not good" boards with other samples, starting from basic ones that does not include DFU and then see whether the firmware read-back is same or not.

[Juliusc]

yeah exactly its the same hex file, same pc, only difference in the DFU is android vs iOS, this might actually output a difference so I will try both and compare the hex files afterwards.

so no general issues with the XIAO are known to you until now - I thought it might be that this board in particular has an issue.

though it never had any issues after a normal flash just after at least one DFU process, something might be up there.

now I at least need to consider to work with this assert, how would you go and use the line of code that I presented in the beginning to kickstart the application while ignoring this assert?

[Juliusc]

no differences after OTA with ios and android but for now both work also (as I said in the beginning it doesnt happen every time but rather in 10 percent of all cases)

[Naeem Maroof]

can you send me:

1) actual hex file that you programmed

2) good firmware readback hex file

3) not good firmware readback hex file

to look more into it.

[Juliusc]

I will send this to you today.

question is, is there a way to recover from such a situation? I cant seem to find the source of the problem so what I need to do is use the assert to jump into dfu-target mode or something. Do you have a recommendation for this?