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]

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?

[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

[Naeem Maroof]

Hello,

Is there any update on your end?

I don't have any good suggestions except that it is not a good idea to make changes to the sdk files, including the dfu and bootloader files, while we know that the sample/application is working on some boards and the issue points to the direction of h/w issue.

[Juliusc]

Hey Naem, no real update I didnt find the source of the problem unfortunately. 

I understand that writing the bootloader is unsafe so I agree. Just maybe a way to ask if theres actually a firmware available that can be started instead of asserting would be a good idea, dont you think?

[Juliusc]

actually I noticed one thing, I am using SDK 15.3 and flashed the firmware with bl-settings version 1 although version 2 is recommended. I changed this now but could this be a cause for such behavior?

[Naeem Maroof]

Hi Julius,

Are you intentionally generating with bl-setting version 1? Why?

Did you change to recommended version and see if it makes difference.

I can see is that "Even though bootloaders compiled from an nRF5 SDK 15.3.0 or later can only use version 2, they can be configured to support a version 1 settings page. When a new bootloader with a version 1 settings page boots, the bootloader translates the settings page to version 2 before booting."

Also, if you want to change the files, then you can remove the assert statement, or do the conditional compilation (if condition then do assert, or the other way around). You can also see if you could / should disable the assertion (as in this ticket). 

BR, Naeem

[Juliusc]

no i didnt do it intentionally, I overread the recommendation.

[Juliusc]

Hey Naeem if you could help me once more please, Ive not really focused on this problem as it didnt always happen but do you think the bl-settings might be the reason why this would happen?

imma lad you through my debugging process once more so that maybe you can tell if this is it or not (I am using bl-settings currently and didnt run into the problem again but this doesnt seem to be 'proof' that its the solution.

so if I debug a 'broken' sensor, it will go go like this:

//jump into this:
nrf_bootloader_fw_activate();

//then here it will give a 1 (VALID APP) although it should be 0, so thats where the problem actually starts
switch (p_bank->bank_code)

//then go into this.
ret_val = app_activate();
//and this is where the assert happens:
ret_val = image_copy(target_addr, src_addr, length_left, NRF_BL_FW_COPY_PROGRESS_STORE_STEP);
   
    

so what I gather from this is that the p_bank->bank_code is actually wrong and I cannot do anything about it bc this bankcode comes from the bootloader settings page (as far as I can see)

so if this is the case, and if I used the wrong bl_settings (version 1) this might have an effect on the bootloader reading out the s_dfu_settings struct right? and thats where it goes wrong, I couldnt think of anything else triggering this process. 

what do you think?

I also thought about using a costum assert but honestly it doesnt seem like a great idea bc so many things could break that I cant see and also the problem appears to happen earlier so it doesnt really make sense to fight this 'symptom'