• State Not Answered
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 561 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 305777
Options

C# hash signature of .bin firmware file not matching with with device ios Device-manager github code. does it have to? problems confirming image. correct length of bytes in write notification?

Charles Settle

Hi,

I'm trying to implement FOTA with C#, for android and iOS.  my hash hex value is not the same as the value when I upload the same firmware image to the Nordic Device Manager app.  Questions are: Does the hash have to match exactly? If so, besides getting a sha-256 hash of the .bin firmware image, what else can I do to get these signatures to match?

In the bluetooth-write notification, I see either 10 or 14 bytes returned.  What is the correct length of bytes that denotes a packet was written successfully to the device?

If the hash can be different for my code than what is presented in the Nordic Device manager app, what is the correct payload for the initial chunk and the payload for the confirm and test commands?

referencing these 2 repos:

https://github.com/NordicSemiconductor/IOS-nRF-Connect-Device-Manager

https://github.com/NordicSemiconductor/Android-nRF-Connect-Device-Manager 

Thanks.

Parents
  • 0

    Hello,

    I'm not sure which sha256 are you referring to, so let me start from the beginning.

    When you compile an app from NCS of Zephyr with MCU mgr enabled you will get a zip file created. This zip file contains a json file with metadata and binaries (one per core). Each binary in the zip is signed using a key given in compilation. The signature, among other values is added to the binary in a header. The header consist of a "magic value" and TLV (Type-Length-Value) fields. On snape of those fields is "hash". This is the sha256 of the firmware content in this binary. This is different than the sha256 of the full bin file or the zip file.

    Current MCU manager protocol requires an image to be "tested" or "confirmed" after sending. To test/confirm an image the client sends an SMP command to Image group giving the hash obtained from the binary from TLV. This sets "pending" flag in the secondary slot and, in case of "confirm" also "permanent" flag (not the "confirmed" flag, which is set by the mcu boot later). A reset following this will cause mcu boot to swap slots.

Reply
  • 0

    Hello,

    I'm not sure which sha256 are you referring to, so let me start from the beginning.

    When you compile an app from NCS of Zephyr with MCU mgr enabled you will get a zip file created. This zip file contains a json file with metadata and binaries (one per core). Each binary in the zip is signed using a key given in compilation. The signature, among other values is added to the binary in a header. The header consist of a "magic value" and TLV (Type-Length-Value) fields. On snape of those fields is "hash". This is the sha256 of the firmware content in this binary. This is different than the sha256 of the full bin file or the zip file.

    Current MCU manager protocol requires an image to be "tested" or "confirmed" after sending. To test/confirm an image the client sends an SMP command to Image group giving the hash obtained from the binary from TLV. This sets "pending" flag in the secondary slot and, in case of "confirm" also "permanent" flag (not the "confirmed" flag, which is set by the mcu boot later). A reset following this will cause mcu boot to swap slots.

Children
Related
Terms of service