Hash validation failure when DFU package transferred manually. nrf_dfu_validation: Hash verification failed.

[MahammadMalikRihan]

When i use nrfutil to perform DFU it is passed, but when i send it through STM32 dev kit it Hash validation failed. but however i can see the CRC is correct.

[Einar Thorsrud]

Hi,

The question is a bit short on information, but I take it you have made your own serial DFU controller implementation running on the STM32, then? It is difficult to say what is the problem, but there must be a difference in the sequence when you use your implementation and when you use nrfutil. Have you compared them? What is the difference?

[MahammadMalikRihan]

Hi Einar, 

Yes we are trying to implement DFU from STM32 to nRF. When the same package is transferred through the PC using nrfutil, it is always successful. But when the same package is transferred from STM32 i see failure. but CRC is correct. 

Soft-device : S140-V6.1.1

SDK : v15.3.0

Bootloader : "secure_bootloader_uart_mbr_pca10056_debug" example provided in SDK

Generating the Application dfu package :

nrfutil pkg generate --hw-version 52 --sd-req 0xB6 --application-version 1 --application Application.hex --key-file priv.pem AppDfuPkg.zip

Following is the procedure to send Application binary using DFU

1. Set PRN to 0, NRF_DFU_OP_RECEIPT_NOTIF_SET

2.  GET MTU NRF_DFU_OP_MTU_GET

3. Send init packet 

• Send NRF_DFU_OP_OBJECT_SELECT  
  
• Send  NRF_DFU_OP_OBJECT_CREATE
• Send  NRF_DFU_OP_OBJECT_WRITE (keep sending packets with MTU size with slip packet )
• Send  NRF_DFU_OP_OBJECT_EXECUTE

4. Send application package

1. Send NRF_DFU_OP_OBJECT_SELECT   
2. Send  NRF_DFU_OP_OBJECT_CREATE
3. Send  NRF_DFU_OP_OBJECT_WRITE (keep sending packets with MTU size with slip packet )
4. Send  NRF_DFU_OP_OBJECT_EXECUTE
5. Repeat step 2,3,4 till whole firmware is transferred

5. DFU fails with <warning> nrf_dfu_serial: DFU request completed with result: 0xB

[MahammadMalikRihan]

I checked the debug logs from nRF while performing DFU from PC and from STM, I see similar logs.

I enable verbose in nrfutil and checked and i found we're also following similar process.  

[Einar Thorsrud]

Hi,

I see. Please upload the complete logs to this case, as it will be useful. However, what I was really interested in was a raw dump of the UART traffic (assuming you are using UART as DFU transport - please confirm). Comparing the dumps should hopefully show where there is a difference, and then we know where to look closer. 

[MahammadMalikRihan]

Hi, Please find the logs attached. i have uploaded logs from both nrfutil & Stm32

/cfs-file/__key/communityserver-discussions-components-files/4/Nrfutil_5F00_logs.txt

/cfs-file/__key/communityserver-discussions-components-files/4/STM_5F00_logs.txt

[Einar Thorsrud]

Hi,

Excellent. But can you also upload dumps of the UART traffic using both tools (nrfutil and your implementation running on the other microcontroller)? Please capture the dumps in the exact same way, so that we can diff the two dumps to see the difference.

[MahammadMalikRihan]

Hi, 

I have uploaded the UART dumps from STM32 and PC(nrfutil), Please find those below 

/cfs-file/__key/communityserver-discussions-components-files/4/6763.stm32_5F00_uart.txt

/cfs-file/__key/communityserver-discussions-components-files/4/nrfUtil_5F00_pcUart.txt

[Einar Thorsrud]

Hi,

The last part of the log is:

2:NRF_DFU_OP_OBJECT_EXECUTE Complete 60 4 B

0xB is NRF_DFU_RES_CODE_EXT_ERROR, so we need to look at the next byte, which we see from the log with UART traffic:

[STM] <-- [ 96, 4, 11, 12,  ]

This is the same response (though it looks different since the numbers are decimal here), and we see that the fourth byte is 12 = 0xC = NRF_DFU_EXT_ERROR_VERIFICATION_FAILED.

I am not able to see exactly what happened though, but I will continue to look into it tomorrow.

In the meantime,

• Can you provide any more information about this issue?
• Do you always get this issue when using your DFU master implementation, or just some times?
• Can you share your DFU master code?
• Can you upload logs from the bootloader (with RTT debug logging enabled)

(Updated with more questions since initial posting)

[MahammadMalikRihan]

Hi Einar,

Einar Thorsrud said:

Can you upload logs from the bootloader (with RTT debug logging enabled)

I'm using SES, with SES it's hard to get all the logs. I'll try though.

Einar Thorsrud said:

Can you share your DFU master code?

I have created one private ticket with case ID : 231391, i have uploaded source code there.

[Einar Thorsrud]

Hi,

MahammadMalikRihan said:

I'm using SES, with SES it's hard to get all the logs. I'll try though.

You can use for instance J-Link RTT Logger to generate a log.

MahammadMalikRihan said:

I have created one private ticket with case ID : 231391, i have uploaded source code there.

Perfect. Then I suggest we continue in that case.