From 6259aa50ebdf148005ce237bbcc632f6f202227c Mon Sep 17 00:00:00 2001 From: David Michieli Date: Tue, 12 Oct 2021 12:07:02 +1100 Subject: [PATCH] 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. --- ports/stm32/boards/NUCLEO_WB55/rfcore_firmware.py | 10 +++++++--- 1 file 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 b5f1d0072e..0d13d24350 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.