Web IDE bricked v2 watch with "firmware update"

Just clicked the glowing yellow button to update firmware on brand new v2 watch and immediately bricked

Probably requires immediate action to prevent mass-bricking by disabling the "update" button

Scenario:

Disabled BT on android phone
BT device appeared in Chrome/Windows 11
Clicked Pair
Clicked firmware update
Followed instruction to hold button, release while indicator moving on watch screen
Clicked next button
ERROR on device screen & web (can't remember which)
Device screen says press button to reboot
Button pressed, bootloop with error BANK0 INVALID

Context:

Received device yesterday, brand new, installed a couple of apps, paired to both PC and android.

Debug info:

Loading https://www.espruino.com/json/BANGLEJS2.­json
index.js:92945 Board JSON loaded
blockly_espruino.js:114 Blockly.setBoardJSON  Object
index.js:92945 Firmware >1.43 supports faster writes over USB
index.js:92945 Set Slow Write = false ('Throttle Send'='Auto')
index.js:92945 FIRMWARE: Current 2v19, Available 2v20
index.js:92945 New Firmware 2v20 available
index.js:92945 [notify_info] New Firmware available (2.19 installed, 2v20 available)
index.js:92945 Device found {"portName":"Bangle.js c684"}
index.js:92945 [success] Connected to Web Bluetooth, Bangle.js c684
index.js:92945 >>> Connected to Web Bluetooth, Bangle.js c684
index.js:92945 Downloading https://www.espruino.com/binaries/esprui­no_2v20_banglejs2.zip
index.js:92945 >>> Downloading binary...
index.js:92945 >>> Done.
index.js:92945 BT> Disconnected (gattserverdisconnected)
index.js:92945 Disconnect callback... {"port":"Web Bluetooth","portName":"Bangle.js c684"}
index.js:92950 [notify_warn] Disconnected from Web Bluetooth, Bangle.js c684
(anonymous) @ index.js:92950
index.js:92945 >>> Disconnected from Web Bluetooth, Bangle.js c684
index.js:92945 stepFlashNordicDFU:  Object
index.js:92945 [success] Initialising...
2index.js:92945 >>> Initialising...
index.js:92945 connected to gatt server
index.js:92945 found DFU service
index.js:92945 found 2 characteristic(s)
index.js:92945 [success] Updating application: espruino_2v20_banglejs2_app.bin...
2index.js:92945 >>> Updating application: espruino_2v20_banglejs2_app.bin...
index.js:92945 connected to gatt server
index.js:92945 found DFU service
index.js:92945 found 2 characteristic(s)
index.js:92945 found packet characteristic
index.js:92945 found control characteristic
index.js:92945 enabled control notifications
index.js:92945 transferring init
index.js:92945 >>> Uploading...
index.js:92945 crc32 not found, skipping CRC check
index.js:92945 written 146 bytes
index.js:92945 transfer complete
index.js:92945 transferring firmware
index.js:92945 crc32 not found, skipping CRC check
index.js:92945 written 1900 bytes
index.js:92945 notify: Error: The state of the DFU process does not allow this operation

Also created ticked with more screenshots at https://github.com/espruino/EspruinoWebI­DE/issues/292

Don't upderstand where to go from here. It says

SW RESET
DFV 2V19

CHECK STORAGE
NO NEW FW
BANK0 INVALID
BTN1 = REBOOT

I have experience with soldering, have a couple of RPIs for potential UART'ing but no idea where to go from here...

Happy to be in the community btw and thanks for the great product that I hopefully will get up and running again!

I was able to un-brick the device by holding down the button till it enter BT flashing again, and then following same update procedure on a Steam Deck after following instructions at https://www.espruino.com/Quick+Start+BLE­#linux

There is also an "Android" based flashing which I did not use but would have probably worked too.

This is a windows problem.

There is also firmware update app that skips this DFU procedure. It uploads new firmware as file to watch storage, reboots watch and the bootloader check for it and does the update from the file.

So you do the firmware update from gadgetbridge app manager by selecting Firmware Update app.

Glad you got it sorted - I'll look into this a bit more and continue to update on the issue you'd filed on: https://github.com/espruino/EspruinoWebI­DE/issues/292

Related idea - Bangle 2 could do a backup of current firmware into SPI storage file before attempting DFU. Maybe it would be useful also in other cases - you could keep older fw images in SPI storage and go quickly back if you don't like newly updated fw even via Firmware Upgrade app.

Not sure how current procedure works (firmware file is deleted after flashing?) but it could be done via two files - one with firmware data and one with just the name of firmware to flash (=metadata), then only the small metadata file could drive the update and point to right fw file.

In this specific case the DFU update in IDE could trigger backup to file and then could point to it as if it should be upgraded. If DFU fails the recovery would find the bank is invalid and use the file to recover. If bank is valid and fw is same (or older) version it would be skipped.

In normal cases (when nordic DFU is not used) the Firmware Upgrade web app (or on device app) could manage firmware files in storage and schedule some for upgrade. This would save relatively long upload of previous FW when going back or switching between few versions.

On slightly related note I tried to enable this SPI storage flashing also for Bangle 1 as recently I found a way to save about 800 bytes in bootloader (by reducing interrupt vector table as per comment) but sadly no, still does not fit with this feature enabled :-(

arm-none-eabi/bin/ld: region `FLASH' overflowed by 480 bytes

EDIT: oh, combined with "-nostartfiles" linker flag I am now at

region `FLASH' overflowed by 161 bytes

so maybe with some further optimisations it could fit

Just got this sorted - I hope. The IDE now redirects users to the app loader, but even when doing a firmware update with the IDE, it now detects the flashing failure and retries automatically at a slower speed, which appears to fix the issue at least on the one PC I have with the problem.

Storing the old firmware is possible I guess - although the bluetooth DFU is a Nordic protocol so we'd have to extend it somehow to do a backup first. And as I recall it was pretty tight getting the bootloader in the assigned space, so we might have to use more pages for it.

I feel like it's probably not a huge deal though - I mean, sure, it feels bad if the upload fails and you can't boot, but your device isn't actually bricked, and assuming you find https://www.espruino.com/Firmware+Update­#nrf52 there are a bunch of apps on different platforms that can re-upload the firmware for you in a minute or two.

Storing the old firmware is possible I guess - although the bluetooth DFU is a Nordic protocol so we'd have to extend it somehow to do a backup first.

I meant that the IDE could do it before starting DFU - would be feature of espruino or even dynamic js code uploaded via IDE - set up correct flat/native string pointing to the firmware and just write it to file - almost a one liner. Same could be done by some firmware managing app or in app loader - to make backup of current firmware before upgrading.

but your device isn't actually bricked

I am an engineer and I can hypothetically un-solder the chip, connect power and SPI and re-flash. And I've done it in the past.

But if the device fails to boot into UI after a documented regular user procedure, it IS bricking.

I'm still very satisfied with the product, just making sure user voice is heard ;)

Well, you can of course call that state in any way you like :-)

However you really don't need to be engineer and unsolder any chips.
You even don't need to take it apart.
You even don't need to use SWD dongle to upload firmware via 3 pins on the back.
The watch has display and button working and advertises over BLE.
You recovered it over Bluetooth by using web browser.
I think we are still not living it times when regular bricks can do all that (but it is near :-))
I would describe the state as 'being stuck in firmware update mode' waiting for you to upload zip file.
BTW, maybe we could show date and time in this mode so one can still use it as a basic watch - some sort of BSOD watchface :-)

some sort of BSOD watchface

That would be super useful to show it's not "bricked", and also maybe a message "still waiting for firmware" - although it is not actually waiting in that "BANK0 error" state, it requires the long-press reboot to enter the waiting mode.

And yes, I was able to avoid an engineering kit flashing mode involving the third-party flasher app, but having me prepared for such outcome would be very handy once I click the lucrative glowing yellow button while naively expecting the shiny new firmware after that one click. But instead experiencing a setback of half an hour to figure out what just happened.

Specifically, a message "if something goes wrong, long press & repeat, if it does not help, try another computer/browser, if that does not help too, download firmware from X and use app Y on the phone"

although it is not actually waiting in that "BANK0 error" state, it requires the long-press reboot to enter the waiting mode

that looks like bug to me, espruino bootloader is based on Nordic DFU bootloader code which waits forever for DFU upload if bank0 is invalid, there is nothing better to do in this state anyway - bank0 is space for main application (=espruino javascript runtime), if that is empty=invalid what else can be done(?)
well maybe by default it has some timeout for connection and then it just reboots to do it again and we broke that loop by waiting for button after first connection timeout(?)

it requires the long-press reboot to enter the waiting mode

I believe it will automatically reboot every 5-10s or so, but it doesn't enter bootloader mode automatically - it just keeps retrying.

However, I think this is probably a non-issue now. The IDE now sends people towards the App Loader which should be more reliable, and the Web IDE firmware update is itself fixed. It should be pretty rare people enter that mode, and if they ever do I feel like a quick google should bring them to some help.

I'll make sure I mention it explicitly though in the troubleshooting docs, and ensure that if you search for BANK0 on the Espruino site you find it easily.