cancel
Showing results for 
Search instead for 
Did you mean: 

Query on .sfb Header Validation and CRC Handling in SBSFU

Vinay_Shirol
Associate II

Hi Team,

I have successfully integrated and run SBSFU with my custom application, and it is working as expected.

Currently, I am transferring the .sfb file .via USB to the DWL_SLOT. Once  the transfer is complete, I trigger a reset using    NVIC_SystemReset(), and the process works fine.

I have a few questions regarding the .sfb header. It contains fields such as:

  • FW Tag (SHA-256)

  • Header Signature

  • Firmware Size (FwSize), etc.

My questions are:

  1. Using FW Tag (SHA-256) for validation
    Is it possible to use the FW Tag (SHA-256) to validate the received image in the DWL_SLOT before performing the reset?
    If yes, could you please guide me on the correct process to implement this?

  2. Current CRC-based approach
    At present, I am calculating a CRC for the .sfb file after it is generated by the Python script. I then transfer both:

    • The .sfb file

    • A separate CRC file

    On the firmware side, I recompute the CRC from the received data and compare it with the provided value. If it matches, I proceed with the reset.

    However, this approach has some drawbacks:

    • It requires transferring two separate files.

  3. Appending CRC to the  .sfb file
    I considered appending the CRC directly to the .sfb  file. However, I am concerned that this might cause issues with SBSFU validation (e.g., mismatch in firmware size), leading to failure.
    Modifying SBSFU to accommodate this could also create maintenance challenges when updating the codebase in the future.

  4. On-the-fly CRC calculation
    I also tried calculating CRC on-the-fly during data reception. However, this method does not detect bit flips reliably. Even when I intentionally introduced bit errors, the CRC check still passed.
    I believe this is because the CRC is computed on the same incoming (possibly corrupted) data stream, making it ineffective for integrity validation.

  5. Observation from SBSFU example
    Even in the provided SBSFU example, I did not find any explicit verification of the image immediately after transfer to the download slot.
    In my case, I cannot assume that the transport layer (USB) is 100% reliable, so I would like to introduce an additional validation step before reset.

Could you please advise on the best approach for validating the received firmware image before reset, ideally without requiring multiple files or major changes to SBSFU?

Thanks and regards,
Vinay Shirol

1 REPLY 1
Jocelyn RICARD
ST Employee

Hello @Vinay_Shirol ,

I don't think there is any need for such CRC check.

USB protocol is already checking each packet 's integrity.

Also, once you have downloaded your .sfb file, if you perform a reset and an error is present, the update will simple not be installed, and you can try again the download.

If you cannot accept this, you have to add your own reliable protocol over USB, possibly generated a digest. CRC is not recommended. As you say, some errors are not detected. If you accept such errors, then you can accept that sometimes the firmware is not installed and are back to first part.

Best regards

Jocelyn