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

Hello I'm trying to update an NRF52810 over a STM32 via an UART, I've the following error "nrf_dfu_validation: Hash verification failed." at the end of the process when sending the execute command.

Seems to be the same problem than case "Case ID: 231115" but the ticket went private so I couldn't see the final solution. 

I also notice that the data written in flash on the nordic microcontroller is filled with 0xFF in order to be a 256 byte block. So the firmware I'm sending is not written correctly which could explain the hash problem, but why are these 0xFF added ?

Best regards, 

Coralie

Parents
  • Hi Coralie, 
    In the ticket you pointed to the customer found the issue in their code that they found an issue in their code when reading SD Card that the same packet was transferred again and again. 

    Regarding your question about "flash on the nordic microcontroller is filled with 0xFF" as far as I know by default the whole flash after you erase the chip will be all 0xFF. The bit changes from 1 to 0 when you write to it. So the area that you don't write anything will remain as 0xFF. 

    Could you give more information about when you get the error ? Do you see the error when sending init packet or when you finish sending the image ? How did you generate the init packet and the hash ? Have you tried to compare it with what the nrfutil generate ? 

  • Hi Hung,

    I got this error when sending the image. The answer to the last execute command is 0x040B0C which is "The hash of the received firmware image does not match the hash in the init packet.".
    By sniffing the UART, I know that the frames sent by the SMT32 are the right one, but only the first part (~63bytes) of a block of 4096 bytes is store in the nRF52810 memory. The other frames seems to be dumped so not written in flash until the start of the next block. 

    I'm thinking that there is some kind of synchronization fail but I cannot found where. 

    I use 19200 as baudrate. 

    Here an extract of the memory once written. We can see that some part have been written and other not. 

    I use nrfutil generate to generate the hash and the init packet (it's working over BLE). I then unzip the files and load them to a ftp server in order to download them on the STM32. 
    I compare the generated files and to the frame sent to nrf52810 and they match. 

  • Hi Coralie, 
    I assume the application image is larger than 4069 bytes. So how about other block of 4069 bytes (other objects) did they get stored properly ? Or do they also only have the first 63 bytes written ?

    Coralie said:
    By sniffing the UART, I know that the frames sent by the SMT32 are the right one, but only the first part (~63bytes) of a block of 4096 bytes is store in the nRF52810 memory.

    If you have sniffed the UART communication and find that the communication has the exact same content then I don't see why the nRF52810 couldn't save the image. 

    The storing of the image to flash is handled inside on_data_obj_write_request() in nrf_dfu_req_handler.c . You may want to add some log there and check if there is something wrong. Maybe compare to when you do DFU update via nrfutil ? 

    A while ago I have made a DFU master firmware that can run on a nRF52 to update another nRF52 via UART. Maybe you can take a look and give it a try ? 
    https://devzone.nordicsemi.com/guides/short-range-guides/b/software-development-kit/posts/getting-started-with-nordics-secure-dfu-bootloader#h108sjziaxo3m81rkgr1has5r1d72qtu

    I'm not so sure if it works out of the box, you may need to test it with SDK v14.2 

Reply Children
Related