[Solved] Trouble performing BLE DFU update on Bangle.js

I tried following the instructions at https://www.espruino.com/Bangle.js#firmware-updates to put my Bangle.js in BLE DFU mode.
For a fraction of second I can read on the watch screen DFU STARTED, but just after the main screen for the watch reappears (the screen with the default watch) and the time gets reset.
Additionally, when connecting to the watch using nRF connect on my smartphone I get this error message when asking to perform DFU: We're sorry, but this device does not support Nordic DFU.

Did someone successfully managed to perform a BLE DFU update with his Bangle.js?
Is there a special screen for the watch that mentions that the watch entered successfully DFU mode?

Thank you for your feedback.

For a fraction of second I can read on the watch screen DFU STARTED

Had you pressed any buttons after that point? Pressing BTN1 causes it to exit and run the watch firmware again which is as you described, but if no buttons are pressed it should sit there and be fine.

Maybe you could record a video to show what happens?

when connecting to the watch using nRF connect on my smartphone I get this error

That's because you have to connect when the watch is in DFU mode

Did someone successfully managed to perform a BLE DFU update with his Bangle.js?

yes, I know there are a bunch of people (me included) that do it often. The Espruino firmware was actually loaded onto your watch wirelessly via that exact bootloader so I'd be pretty suprised if it was broken.

Is yours a Nodeconf Bangle.js?

Is there a special screen for the watch that mentions that the watch entered successfully DFU mode?

yes, it says something like:

DFU STARTED
BTN1 = REBOOT

I'm also having some issues, but not exactly the same as Sebi.
My (nodeconf) watch is in DFU started, the exact same screen as you shown, Gordon.

On my Android phone, I select the latest firmware, then my bangle ECDB device, and I hit the upload button (see attached screenshot)

While uploading, nothing happens on the Bangle.
After a while, I'm receiving a notification on the phone (it's too quick to take a screen shot):

Upload failed: GATT ERROR

1 Attachment

• Screenshot (4 déc. 2019 18_26_19)

This is what I do to for Firmware Updates

1 Attachment

@Gordon:

Had you pressed any buttons after that point?

No.

Maybe you could record a video to show what happens?

See enclosed video.

That's because you have to connect when the watch is in DFU mode

Indeed.

Is yours a Nodeconf Bangle.js?

😕 not exactly ...it is the F watch my nephew got for his birthday I hacked.
I built the firmware using command make clean && BOARD=BANGLEJS RELEASE=1 make, removed the flash protection and uploaded Espruino using SWD onto the watch.

Sorry for that Gordon: I just couldn't resist installing your software onto the watch (I do own a a Pico, a Puck.js and your book though).

1 Attachment

• BangleJS_entering_DFU_mode.mov

So there is no bootloader at all in your watch, did you just flash soft device and the app?
What output of peek32(0x10001014).toString(16) shows?

Make sure you get the Bangle.js into "DFU Started" mode like in (1)

Thanks all for the support.
In fact, the firmware was applied, I can tell by the booting screen.

I'm just confused with one thing: on the Android DFU app, I don't have DfuTarg option, but Bangle ECDB instead. Is it ok?

Check around 00:18, BTN1 is pressed too long and Bangle.js reboots.

When ==== shows, just release BTN2 and short after that BTN1

@fanoush:
The output of peek32(0x10001014).toString(16) is ="7a000".

When compiling the firmware the log displays:

python scripts/hexmerge.py --overlap=replace
.../s132_nrf52_3.0.0_softdevice.hex
bootloader_espruino_2v04.264_banglejs.hex
espruino_2v04.264_banglejs.app_hex
dfu_settings.hex
-o espruino_2v04.264_banglejs.hex

...so I was thinking that the bootloader was merged together with softdevice, the app and dfu settings into espruino_2v04.264_banglejs.hex.

I only flashed this latest as this process worked correctly on my Puck.js as I was able to perform BLE DFU upgrade after installing the generated firmware using SWD onto it.

@MaBe:
I can read on the screen DFU Started for a fraction of second (see video of my previous message), but just after I get your screen n°5. I don't get your screen n°1 exactly as the screen with DFU Started doesn't remain still and BTN1 = REBOOT doesn't show.

I can read on the screen DFU Started for a fraction of second (see video), but just after I get your screen n°5. I don't get your screen n°1 exactly as the screen with DFU Started doesn't remain still with BTN1 = REBOOT displayed.

Try this:

When ==== shows, first release BTN1 and than BTN2

@MaBe:

When ==== shows, first release BTN1 and than BTN2

As soon as I release BTN1 (with BNT2 being pressed still) I can read for a short fraction of second DFU Started. But just after I get the main screen with the Bangle.js logo (keeping BTN2 pressed or releasing it).

Have a look at this clip:

1 Attachment

• img-9586-isyvthsnmov-ftqi-ejaux2itmp4.compressed.mp4

On my watch I get this result (see video).

1 Attachment

• BangleJS_entering_DFU_mode_#2.mov

@sebi ok, then you have the bootloader indeed, bad guess. If you would mass erase it (unlock flash protection like you said) and then flash just softdevice and the app it would behave like this as bootloader is optional and reboot would just restart espruino. but that would give you all FFs with that peek command.

@fanoush:
What about UICR? (Maybe address 0x10001014 has to do with it?)
I think while I was disabling the flash protection (mass erase) I did also flash bank 1 with 0xFFs.

[EDIT] I checked and address 0x10001014 is indeed UICR.BOOTLOADERADDR.
So when flashing Espruino, not only bank 0 gets flashed but bank 1 as well with the 0x7a000 value.

Hmm, how did you manage to flash 2v04.264?

Opening the watch and using the Serial Wire Debug interface (SWD).

Opening the watch and using the Serial Wire Debug interface.

I almost thought so ;-)

On my watch BTN1 doesn't feel as stiff as BTN2 and 3 (BTN1 rounded metallic pad on the white flexible PCB for buttons in the watch might be loose a little).

Could this result in a bad debouncing for BTN1 making it like the button has been pressed/released a few times?
(However I didn't notice such a bad debouncing effect when scrolling across the watch menus.)

on the Android DFU app, I don't have DfuTarg option, but Bangle ECDB instead. Is it ok?

That's odd - if you started the scan before you entered bootloader mode then that might explain it.

@sebi thanks for letting me know - the fact you built your own narrows it down a lot :)

I don't really want to get involved in supporting this too much as I need to focus my time on getting the KickStarter Bangles out. BUT...

Looks to me like the bootloader is there (as it's displaying the bootloader text), but is corrupt. This sounds like the compiler you're using is generating a bootloader binary that is too big to fit in the available memory area. It means the bootloader will get the end cut off, and will probably work well enough to boot Espruino, but not enough to actually be a bootloader.

You could check the bootloader...hex file and see if right at the end the lines go :10DFE, :10DFF and THEN :xxE00. That'll mean it's running into the next page.

The bootloader is ridiculously tight (due to the SDK11 layout it has to fit in less RAM than a normal SDK12 bootloader, plus it has to have an LCD driver). Even using the wrong compiler would have that effect. I'm using 8-2018-q4-major on mine and it fits with only about 8 bytes to spare.

If you or anyone else can find a way to get a few more bytes free in the bootloader it'd be hugely appreciated :)

(nevermind)

The bootloader is ridiculously tight (due to the SDK11 layout it has to fit in less RAM than a normal SDK12 bootloader, plus it has to have an LCD driver). Even using the wrong compiler would have that effect. I'm using 8-2018-q4-major on mine and it fits with only about 8 bytes to spare.

Indeed, tried yesteday and for me it is just three bytes. There is a check in the makefile for size so it could be reduced to 7a000-7dfff area to catch this and fail. In fact I had my own modifications there for other devices and had to build from scratch since even one added line made it too big. BTW I think you could disable bootloader and app version checking that prevents downgrade here to save few bytes.

Good call on the firmware version check - that's knocked quite a lot off. I've just committed the change.

If you get time, please could you do a PR for the modified check in the Makefile? I remember finding it was a pain because scripts/check_elf_size.py checks the elf file, and actually the DATA section could fit in but the other sections placed after (because of Nordic's SDK hacks) would still overlap

If you get time, please could you do a PR for the modified check in the Makefile? ... actually the DATA section could fit in but the other sections placed after (because of Nordic's SDK hacks) would still overlap

Maybe it can be done in linker file then, not makefile. OK, will try to look into it.