HASH problem during DFU of Bootloader

RE: HASH problem during DFU of Bootloader

Yosi.stx — Wed, 01 Aug 2018 12:07:14 GMT

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.

RE: HASH problem during DFU of Bootloader

Hung Bui — Mon, 30 Jul 2018 16:23:58 GMT

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.

RE: HASH problem during DFU of Bootloader

Yosi.stx — Sun, 29 Jul 2018 16:44:27 GMT

Some clarification:

The reason that DFU of application was successful is that by chance the test application that we used was with size aligned to 128 bytes.

that mean we have the same HASH problem also when performing DFU of application FW.