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.
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.
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?
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.
5. DFU fails with <warning> nrf_dfu_serial: DFU request completed with result: 0xB
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.
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
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.
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
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,
(Updated with more questions since initial posting)
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,
(Updated with more questions since initial posting)
Hi Einar,
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.
Can you share your DFU master code?
I have created one private ticket with case ID : 231391, i have uploaded source code there.
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.