Mesh UART-DFU fail with "Abort event. Reason: 0x4"

[frank_c]

Hi,

We base on the light switch example to include the dfu process into it.

Device FW information is as follows:

Mesh sdk: v4.2.0
SoftDevice: s113_nrf52_7.0.1_softdevice.hex
bootloader: mesh_bootloader_gccarmemb_nrf52832_xxAA.hex
device page: device_page_nrf52832_xxAA_s113_7.0.1.hex

Testing environment:
1. PC <-UART-> 52832 DK

Build a DFU-sender program with c code (just like the nrfutil works) in PC to send the bin and dat data to 52832DK.
The 52832DK with pre-compile bootloader,soft device, application FW and device page can be dfu updated successfully via UART.

 0> <t:    4266661>, serial_bearer.c,  394, frank: C8
 0> <t:    4266667>, serial_bearer.c,  394, frank: A
 0> <t:    4266673>, serial_bearer.c,  394, frank: 40
 0> <t:    4266680>, serial_bearer.c,  394, frank: D
 0> <t:    4266682>, serial_bearer.c,  212, ----frank---  end_reception
 0> <t:    4266684>, serial_bearer.c,  141, ----frank---  serial_process
 0> <t:    4266688>, nrf_mesh_dfu.c,  502, 	DFU segment rx: 9623/9623
 0> <t:    4266693>, nrf_mesh_dfu.c,  656, 	TIMER set: 30000000us delay (@1696209137)
 0> <t:    4266697>, nrf_mesh_dfu.c,  581, 	RADIO TX! SLOT 1, count 3, interval: exponential, handle: FFFC
 0> <t:    5249733>, nrf_mesh_dfu.c,  351, Timeout fired @1696209137
 0> <t:    5264814>, nrf_mesh_dfu.c,  367, Write complete (0x2000FD38)
 0> <t:    5264818>, nrf_mesh_dfu.c,  376, Flash idle.
 0> <t:    5264891>, nrf_mesh_dfu.c,  372, Erase complete (0x7E000)
 0> <t:    5264899>, nrf_mesh_dfu.c,  367, Write complete (0x7F000)
 0> <t:    5265033>, nrf_mesh_dfu.c,  367, Write complete (0x7F004)
 0> <t:    5265041>, nrf_mesh_dfu.c,  367, Write complete (0x7F048)
 0> <t:    5265044>, nrf_mesh_dfu.c,  367, Write complete (0x7F054)
 0> <t:    5265048>, nrf_mesh_dfu.c,  367, Write complete (0x7F060)
 0> <t:    5265051>, nrf_mesh_dfu.c,  367, Write complete (0x7F06C)
 0> <t:    5265054>, nrf_mesh_dfu.c,  367, Write complete (0x7F080)
 0> <t:    5265057>, nrf_mesh_dfu.c,  367, Write complete (0x7F088)
 0> <t:    5265060>, nrf_mesh_dfu.c,  367, Write complete (0x7F0E0)
 0> <t:    5265132>, nrf_mesh_dfu.c,  372, Erase complete (0x7F000)
 0> <t:    5265140>, nrf_mesh_dfu.c,  367, Write complete (0x7E000)
 0> <t:    5265275>, nrf_mesh_dfu.c,  367, Write complete (0x7E004)
 0> <t:    5265283>, nrf_mesh_dfu.c,  367, Write complete (0x7E048)
 0> <t:    5265286>, nrf_mesh_dfu.c,  367, Write complete (0x7E054)
 0> <t:    5265289>, nrf_mesh_dfu.c,  367, Write complete (0x7E060)
 0> <t:    5265292>, nrf_mesh_dfu.c,  367, Write complete (0x7E06C)
 0> <t:    5265295>, nrf_mesh_dfu.c,  367, Write complete (0x7E080)
 0> <t:    5265298>, nrf_mesh_dfu.c,  367, Write complete (0x7E088)
 0> <t:    5265301>, nrf_mesh_dfu.c,  367, Write complete (0x7E0E0)
 0> <t:    5265304>, nrf_mesh_dfu.c,  376, Flash idle.
 0> <t:    5265306>, nrf_mesh_dfu.c,  520, 	DFU END!
 0> <t:    5265310>, dfu_init.c,  152, ----- NRF_MESH_EVT_DFU_END...
 0> <t:    5265314>, nrf_mesh_dfu.c,  527, 	DFU BANK AVAILABLE
 0> <t:    5265317>, dfu_init.c,  159, ----- NRF_MESH_EVT_DFU_BANK_AVAILABLE...
 0> <t:    5265374>, nrf_mesh_dfu.c,  367, Write complete (0x2000FD38)
 0> <t:    5265378>, nrf_mesh_dfu.c,  376, Flash idle.

2.other MCU <-UART-> 52832 module

Build a DFU-sender program with c code (just like the nrfutil works) in "other MCU" to send the bin and dat data to 52832 module.
The 52832 module with the same FW as above (pre-compile bootloader,soft device, application FW and device page) can get the bin+data data successfully with no errors (correct event,op-code and status) from "other MCU" via UART. But it shows "the Abort event. Reason: 0x4".

 0> <t:    3850853>, serial_bearer.c,  388, frank: A3
 0> <t:    3850859>, serial_bearer.c,  388, frank: 7E
 0> <t:    3850862>, nrf_mesh_dfu.c,  502, 	DFU segment rx: 9622/9623
 0> <t:    3850867>, nrf_mesh_dfu.c,  581, 	RADIO TX! SLOT 1, count 3, interval: exponential, handle: FFFC
 0> <t:    3854159>, serial_bearer.c,  388, frank: 19
 0> <t:    3854164>, serial_bearer.c,  388, frank: 78
 0> <t:    3854170>, serial_bearer.c,  388, frank: FC
 0> <t:    3854176>, serial_bearer.c,  388, frank: FF
 0> <t:    3854181>, serial_bearer.c,  388, frank: 97
 0> <t:    3854187>, serial_bearer.c,  388, frank: 25
 0> <t:    3854193>, serial_bearer.c,  388, frank: 1
 0> <t:    3854198>, serial_bearer.c,  388, frank: 0
 0> <t:    3854204>, serial_bearer.c,  388, frank: 0
 0> <t:    3854210>, serial_bearer.c,  388, frank: 0
 0> <t:    3854216>, serial_bearer.c,  388, frank: 5A
 0> <t:    3854221>, serial_bearer.c,  388, frank: 14
 0> <t:    3854227>, serial_bearer.c,  388, frank: 81
 0> <t:    3854233>, serial_bearer.c,  388, frank: BD
 0> <t:    3854238>, serial_bearer.c,  388, frank: 15
 0> <t:    3854244>, serial_bearer.c,  388, frank: 8D
 0> <t:    3854250>, serial_bearer.c,  388, frank: 59
 0> <t:    3854256>, serial_bearer.c,  388, frank: 8D
 0> <t:    3854262>, serial_bearer.c,  388, frank: D2
 0> <t:    3854267>, serial_bearer.c,  388, frank: D1
 0> <t:    3854273>, serial_bearer.c,  388, frank: A4
 0> <t:    3854279>, serial_bearer.c,  388, frank: 6F
 0> <t:    3854284>, serial_bearer.c,  388, frank: C8
 0> <t:    3854290>, serial_bearer.c,  388, frank: A
 0> <t:    3854296>, serial_bearer.c,  388, frank: 40
 0> <t:    3854301>, serial_bearer.c,  388, frank: D
 0> <t:    3854305>, nrf_mesh_dfu.c,  502, 	DFU segment rx: 9623/9623
 0> <t:    3854310>, nrf_mesh_dfu.c,  656, 	TIMER set: 30000000us delay (@1171624207)
 0> <t:    3854314>, nrf_mesh_dfu.c,  581, 	RADIO TX! SLOT 1, count 3, interval: exponential, handle: FFFC
 0> <t:    4837350>, nrf_mesh_dfu.c,  351, Timeout fired @1171624207
 0> <t:    4852242>, nrf_mesh_dfu.c,  431, 	Abort event. Reason: 0x4
 0> <t:    4852246>, dfu_init.c,  151, ----- NRF_MESH_EVT_DFU_END...
 0> <t:    4852250>, nrf_mesh_dfu.c,  581, 	RADIO TX! SLOT 0, count 255, interval: periodic, handle: FFFE
 0> <t:    6047382>, serial_bearer.c,  388, frank: 55
 0> <t:    6047387>, serial_bearer.c,  388, frank: 7
 0> <t:    6047393>, serial_bearer.c,  388, frank: 32
 0> <t:    6047399>, serial_bearer.c,  388, frank: 1
 0> <t:    6047404>, serial_bearer.c,  388, frank: 0
 0> <t:    6047410>, serial_bearer.c,  388, frank: C7

Could anyone help it?

Thanks,
Frank

[Hung Bui]

Hi Frank, 

Please post the whole log. 
You mentioned that it  "can get the bin+data data successfully with no errors" . When exactly you received  "Abort event. Reason: 0x4" ? 

Reason 0x04 meant NRF_MESH_DFU_END_ERROR_UNAUTHORIZED

It could be due to the signature/hash check failed. You may want to try compare what the "other MCU" sent on UART with what nrfutil sent and check what's the difference. I would start with very simple application image so I can detect the difference in the raw data.  

[frank_c]

Hi Hung,

Please check the logs as follows:

test_log.rar

"can get the bin+data data successfully with no errors" means the sender program will check the response (length+event+opcode+status)from 52832 after
sending each set of the data(bin or dat). If the response is correct, it will send the next set of data.

For example, if the sender sends one set of bin data, it will check whether 52832's response is correct (event 0x84,opcode 0x78,status 0x00).
If it does, the sender will send next sets and so on.

Is there any chance the error is caused by the device page?

I mean I use the same device_page file in the 2 testing cases (one for DK and one for module).

Do I have to change the company_id to match the module company's id in bootloader_config_default.json?

{
    "bootloader_config": {
        "bootloader_id": 1,
        "bootloader_version": 1,
        "company_id": 89,
        "application_id": 1,
        "application_version": 1,
        "public_key": "aaa1601a85e678972ec387d5fc73ab0f478e02a6e8e785890739f6b8bffb9e22beba253ebc9a24bd12e187a3a4ce4b0a47af802d3ea4a6444e7b1786c2e4aafe"
    }
}

Thanks,
Frank

[frank_c]

Hi Hung,

We do notice the company_id , application_id and application_version then we can do UART-DFU successfully in case 1 (PC <->DK).

Please check the log file above.

Thanks,

Frank

[Hung Bui]

I assume when you do MCU <-> DK you have the condition matched (company id matched, application id matched and app version > current app version). 

Error 4 meaning the signature check was failed (check dfu_mesh_timeout() in dfu_mesh.c). You may need to check if you send the correct init packet. 
I would suggest to check that, you can use a logic analyzer to compare the DFU update from PC vs from the MCU. 

You can also debug the bootloader, I have made a ses project for the bootloader here.

[frank_c]

Hi Hung,
We take reference from your 52840 ses project to create our 52832 project by using sd-s113  under the \mesh\bootloader folder. (mesh_bootloader_gccarmemb_nrf52832_xxAA.emProject).

bootloader_test.rar

We erase chip then run the debug mode but an error occurs as the picture shows.

Is there anything that needs to be modified ?

Thanks,
Frank

[Hung Bui]

Hi Frank,

Please make sure you have flashed the device page. Without that the bootloader won't work. 
Also I noticed that you located the bootloader at address 0x1c000. This may not correct.

Usually we locate the bootloader on top of the flash space. 

In our bootloader linker .ld (in linker folder) you can find the location of the bootloader should be 0x78000.

[frank_c]

Hi Hung,

We did several tests in these days and found out if we slow down the sender's speed, the successful rate for uart-dfu updated will be improved.

If we speed up the sender's speed, the device will get wrong uart-dfu data (bin data) more easily.
And it will let the dfu fail with "Abort Reason 0x4".

Besides to slow down the sender's speed, is there anything the device can be modified to decrease the uart-dfu updated time?

Thanks,
Frank

[Hung Bui]

Hi Frank, 

What's the transfer rate you are doing ? 
Please follow the delay we have in nrfutil, pushing the speed of doing DFU may risk that the DFU packet haven't reached all nodes in the network before you push the new message. 
Do you have HWFC enable ? 

[frank_c]

Hi Hung,

1.The sender sends each sets of bin data (26 bytes) and delay about 350ms then wait for the response from device.
If the delay time is too short, it can let the dfu fail.
The FW size is about 153KB and it will take about 30-40 minutes to complete the dfu updated.

2.Due to we use the CTS & RTS pin to other purpose in "other MCU", the device doesn't enable the HWFC.

3.If we just want to do one-one uart-dfu updated and don't want to use the air mesh dfu to other nodes or device, how can we do it?

We use Buad Rate 57600.

Thanks,
Frank

[Hung Bui]

Hi Frank, 

If you are planning to do only one on one uart DFU, I would suggest to have a look at the normal nRF5 SDK UART bootloader instead of the mesh bootloader. 

The only draw back is that it's not background DFU, and you have to switch to the bootloader to receive the new image. However, since it only take a very short time (depends on the size of the image, can be less than a minute) to do DFU it's feasible to do so. 
I have made an example on how to do UART update from one nRF52 to another nRF52 here. 

350ms delay sounds reasonable as it's similar to the delay we have in the nrfutil.