Recommended Practices for Firmware Fallback#

1. Always use NWP and M4 Application Firmwares from the same SDK release.

2. NWP firmware from wiseconnect SDK v3.5.2 or later must be loaded in the SiWG917, before enabling the Firmware Fallback Feature.

3. HTTP/S OTA firmware update mechanism listed in AN1431 is not supported for Firmware Fallback feature enabled devices. However, the firmware file can be downloaded to M4 application via HTTP/S connection (HTTP GET) and then M4 based Firmware Update can be performed.

4. Ensure Active NWP slot is Slot-A before performing any of the below operations:

   • Flash/Chip erase

   • Disabling Firmware Fallback Feature

   • Performing Fallback Updater OTA

5. Erasing an inactive NWP slot all at once takes approximately 14 seconds, during which the wireless operations are paused. This can lead to Access Point (AP) disconnections and protocol issues. To avoid such issues, it is recommended to either:

   • Erase the inactive slot image sector-wise (4 KB at a time).

   • Complete the erase process before initiating the wireless connection.

6. Low Power configurations should be disabled during Firmware updates, to prevent data reception failures.

7. If Anti-Rollback is enabled, if one NWP slot has higher security version (for module boards) or higher firmware version (for IC boards) than the other, and the OTP bits are burned from the higher NWP firmware, fallback to the lower version slot will not be possible. Therefore it's crucial to compare both NWP slot security/firmware versions before burning OTP.

8. Firmware data is written to the inactive slot location of Flash as chunks. When security is enabled in the device, ensure the data chunk size is 16-byte aligned.

Troubleshooting#

1. 0x16056: Valid Firmware not present

   • Possible cause: Having NWP slot-B as Active slot when Flash is erased from Simplicity Commander

   • Solution: Use sl_si91x_select_default_nwp_fw() API to select slot-A as the default NWP firmware.

2. "M4 Updater Start..." prints in loop, or M4 updater running in loop without branching to your slot applications

   • Possible cause: M4 Updater and the slot-A M4 firmware start address being same. This can be confirmed by observing the slot information prints when you run slot-A M4 application. This scenario happens when you load M4 updater via OTA.

   • Solution: Since the firmware fallback feature flow is broken, follow the steps mentioned in Initial Setup section to reestablish the fallback feature applications.

3. Application debug logs shows the OTA is successful, but the new firmware is not reflecting

   • Possible cause: After entire OTA process (Download+Verification) is completed successfully, sl_si91x_ab_upgrade_set_slot_info() API is not called in the application.

   • Solution: Ensure sl_si91x_ab_upgrade_set_slot_info() API is called after successfully completing the OTA firmware download and verification.

Limitations#

1. Firmware Fallback feature is supported on 8 MB Common Flash SoC OPNs only.

2. Combined Firmware Update listed in AN1431: SiWx917 SoC Firmware Update Application Note is not supported with Firmware Fallback feature.

3. When security is enabled for the SiWG917, both the slot firmware images must be in the same security level.

4. After enabling the Firmware Fallback feature, only host-based or M4-based Over-the-Air (OTA) firmware updates are supported. Other firmware update methods mentioned in AN1431: SiWx917 Firmware Update App Note, such as HTTP OTAF and Kermit/Simplicity Commander flashing, are not supported.