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

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

Hung Bui — Thu, 21 Jan 2021 10:50:57 GMT

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.

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

frank_c — Thu, 21 Jan 2021 02:19:21 GMT

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

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

Hung Bui — Wed, 20 Jan 2021 10:50:18 GMT

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 ?

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

frank_c — Wed, 20 Jan 2021 05:22:57 GMT

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

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

Hung Bui — Fri, 15 Jan 2021 14:48:22 GMT

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.

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

frank_c — Fri, 15 Jan 2021 05:35:23 GMT

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).

devzone.nordicsemi.com/.../bootloader_5F00_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

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

Hung Bui — Thu, 14 Jan 2021 11:31:58 GMT

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.

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

frank_c — Thu, 14 Jan 2021 10:27:33 GMT

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

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

Hung Bui — Thu, 14 Jan 2021 10:11:04 GMT

Hi Frank,

Yes you would need to match the company_id and application_id. In addition, you need to have the application_version of the new image > the application_version of the current application. So if you try to update one image twice it won't work.

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

frank_c — Thu, 14 Jan 2021 05:17:41 GMT

Hi Hung,

Please check the logs as follows:

devzone.nordicsemi.com/.../test_5F00_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

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

Hung Bui — Wed, 13 Jan 2021 16:12:18 GMT

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.