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]

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.

[Naeem Maroof]

You can see in the code:

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

that the assert statement is making sure the alignment of the destination address is correct.

It looks like there are no problems in the code /application but when the bootloader is copying the image then it finds some misalignments in the destination address. 

I am not sure why it has happened but looks like due to the hardware as you have the same firmware. Also, it is difficult to say anything if that is not reproducible and only happens sometimes.

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

[Naeem Maroof]

Juliusc said:

no differences after OTA with ios and android but for now both work

Did you make any changes?

Juliusc said:

as I said in the beginning it doesnt happen every time but rather in 10 percent of all cases

Yes, I understand, such situations are harder to debug.

Juliusc said:

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.

I understand that XIAO uses nrf SoC, but I have never used this board. 

It will be best if the problem could be replicated on the DK.

Juliusc said:

question is, is there a way to recover from such a situation?

What happens if you do the soft reset?

[Juliusc]

i didnt make any changes no. 

i wasnt able to replicate it on a different board than the xiao (supporting your claim that it must be hw-related)

reset does not work. I am stuck in the bootloader in an endless loop (restart on assert) -> i would like to maybe implement a case that jumps into dfu mode or tries to kickstart the application