Espruino goes to DFU on cold boot on nRF52832

I have just put Espruino (2v24) on a smartwatch that has an nRF52832 on board. I determined the button GPIO and created a board file for it, that all works well. If I issue an E.reboot(), everything is fine, comes back to Espruino. Also if the Watchdog gets tripped, it boots to Espruino. If I let the battery run down to cold and plug it in however it jumps to DFU and stays there. I have to reload Espruino each time. I'll enclose the board file below. I've had issues with getting to DFU at all from other boards/watches I've worked on, this is the first time I've experienced this.
Notes: BTN1 (D28) is normally high, goes low when pressed, so I inverted it in the board file. I gathered that the IN_PULLDOWN works opposite when inverted as the pin needed to be pulled high to properly register. Works as expected when running (normally low, pressing sends it high).
Also: originally I did a full build (RELEASE=1 BOARD=M98) and used SWD to program the entire package (so it received SD, firmware, bootloader, MBR and UICR). The current UICR is all "ffffffff" except:
0x10001014: 0x78000
0x10001018: 0x7e000
Any ideas very much appreciated...

1 Attachment

• M98.py

I think the bootloader code is not very well tested on device that is not Bangle/Puck/Pixl so I think I never used the code 'as is' without few patches here an there.

Anyway, it may be a feature https://github.com/espruino/Espruino/blob/master/targets/nrf5x_dfu/main.c#L145 , not bug.

I think having BUTTONPRESS_TO_REBOOT_BOOTLOADER defined might really help you?

https://github.com/espruino/Espruino/blob/master/boards/BANGLEJS2.py#L90

Bangle.js uses this and I think it got added specifically to allow you to easily exit DFU

I think it got added specifically to allow you to easily exit DFU

These are more useful if you also have display driver and see what is happening when you press, hold, release ...

If there is no display support in bootloader the easiest is simple timeout (like 1 or 2 minutes)

But maybe in this case the bootloader was built when there was no button in board file defined yet?

I did define a BTN1 for this watch, but as I said, not sure if the fact that it's normally closed and had to invert it in software was any issue. I assume that magic happens at a lower level than the DFU main.c? I'll try the define above, since now the battery seems to be depleting overnight so I'm upgrading it regularly ;-)
BTW: the screen is a GC9A01, just like DICKENS, however it doesn't seem to display anything on cold boot despite my defining the pins in the board file. Nor does it buzz which I believe my Bangle does due to board definition?

Anyway, it may be a feature https://github.com/espruino/Espruino/blo­b/master/targets/nrf5x_dfu/main.c#L145 , not bug.

That's if you don't define a BTN1. Even so, the comment says it should exit DFU after a few seconds and boot properly... which is why I thought maybe I didn't have the right entry point defined somewhere?

That's if you don't define a BTN1. Even so, the comment says it should exit DFU after a few seconds and boot properly.

Yes, if it stays in DFU (= you see it in nrf connect for many minutes) then either the comment is not true in your combination of compile flags or you somehow has internal flash corruption happenning after cold boot which is very strange. Or maybe you somehow erased bootloader settings at the end of the flash? that would become effective at next E.reboot() or cold boot.