• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 3 replies
  • Subscribers 75 subscribers
  • Views 2727 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 211458
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

HASH problem during DFU of Bootloader

Yosi.stx

Hello,

We are using nRF5 SDK14.2.0 and soft device s132, and trying to perform DFU of the Bootloader itself.

The process fail in nrf_dfu_postvalidate() due to wrong HASH value calculated on the image written to the flash.
We read the content of the Flash after the DFU process that failed, starting from address 0x23000 with length of the image, and saved it to a binary file. After comparing it with the binary image file inside the zip package, we find them identical, hence the write of the image is done correctly!
Yet we are puzzled that the Hash calculated in the post-validation function get different 32 bytes value when comparing it to the data in the init packet.

Some comments:
1. This discrepancy happen only when trying to do DFU to Bootloader, we don't get this problem when DFU an application firmware!
2. When manually padding with 0xFF the Bootloader FW image and make its size aligned 128 bytes, we can complete the Bootloader FW DFU successfully.

Does anyone know how to solve this Hash calculation discrepancy without padding the FW image?
Does anyone have a clue to the source of the discrepancy?

Parents
  • +1

    Hi Yosi, 

    I don't think we have any requirement of application size have to be 128 byte align. Word align maybe required but not 128 bytes. 

    Could you send us an example of application hex file that you see the problem and let us test here ? Do you see the same problem when updating our example application in the SDK ? 

    We have a step by step guide here might be useful.

  • 0 in reply to Hung Bui

    Thank you for the answer.

    I have noticed that the function sha256_update() uses 64 bytes segments.
    When the last segment is exactly 64 bytes: the calculation is always good.
    When the last segment is less then 64 bytes, for example only 48 bytes, the sha256_update() function
    is leaving the extra 16 bytes from the previous segment in the vector "ctx->data[]".
    At this point when running with debugger I noticed that previous data on this RAM sector was changed
    (maybe due to stack overflow?) causing bad calculation. When the previous segment data is left
    at the end of vector "ctx->data[]" the Hash calculation returns good results.
    I need to clear that we increased the original Bootloader code by using external SPI Flash
    and before our code addition we didn't have this problem.
    I increased the stack from the example default of 0x800 to 0x1800 and for now we have good Hash calculation.

Reply
  • 0 in reply to Hung Bui

    Thank you for the answer.

    I have noticed that the function sha256_update() uses 64 bytes segments.
    When the last segment is exactly 64 bytes: the calculation is always good.
    When the last segment is less then 64 bytes, for example only 48 bytes, the sha256_update() function
    is leaving the extra 16 bytes from the previous segment in the vector "ctx->data[]".
    At this point when running with debugger I noticed that previous data on this RAM sector was changed
    (maybe due to stack overflow?) causing bad calculation. When the previous segment data is left
    at the end of vector "ctx->data[]" the Hash calculation returns good results.
    I need to clear that we increased the original Bootloader code by using external SPI Flash
    and before our code addition we didn't have this problem.
    I increased the stack from the example default of 0x800 to 0x1800 and for now we have good Hash calculation.

Children
No Data
Related
Terms of service