stm32/boards/NUCLEO_WB55: Update rfcore_firmwre for new WS.

Adds a fix to behavior occuring since WS 1.11 where the FUS returns
misleading statuses during WS upgrade.

1 files changed, 7 insertions, 3 deletions

diff --git a/ports/stm32/boards/NUCLEO_WB55/rfcore_firmware.py b/ports/stm32/boards/NUCLEO_WB55/rfcore_firmware.py
index b5f1d0072..0d13d2435 100644
--- a/ports/stm32/boards/NUCLEO_WB55/rfcore_firmware.py
+++ b/ports/stm32/boards/NUCLEO_WB55/rfcore_firmware.py
@@ -537,9 +537,13 @@ def resume():
             elif status == 0:
                 log("WS update successful")
                 _write_state(_STATE_WAITING_FOR_WS)
-            elif result == 0:
-                # We get a error response with no payload sometimes at the end
-                # of the update (this is not in AN5185). Re-try the GET_STATE.
+            elif result in (0, 0xFE):
+                # We get an error response with no payload sometimes at the end
+                # of the update (this is not in AN5185). Additionally during
+                # WS update, newer WS reports (status, result) of (255, 254)
+                # before eventually reporting the correct state of
+                # _STATE_INSTALLING_WS once again. In these cases, re-try the
+                # GET_STATE.
                 # The same thing happens transitioning from WS to FUS mode.
                 # The actual HCI response has no payload, the result=0 comes from
                 # _parse_vendor_response above when len=7.