Extra boot time on MDBT42Q binary

[espruino-discuss]

Posted at 2019-09-28 by amandala

Hello, apologize if this is common knowledge, but I did a bit of search and not found the answer. When I use nRF52832-DK binary on MDBT42Q, the boot time is much shorter, as captured using PPK kit attached, the first block around 7mA is only under 200mS, but when I use the normal MDBT42Q binary (tested 2.01, 2.03, and 2.04), the boot time significantly extended to about 1.3 second. As I'm working on an application where limited energy available, the extra boot time is significant.
Any strapping I need to do to speed up boot time similar to nRF52832-DK binary?

---

Attachments:

• bootnRF52.png

[espruino-discuss]

Posted at 2019-09-29 by AkosLukacs

I guess it's waiting for a button press to enter DFU mode.
Check out https://github.com/espruino/Espruino/blob/master/targets/nrf5x_dfu/main.c#L111

[gfwilliams]

Posted at 2019-09-30 by @gfwilliams

I guess it's waiting for a button press to enter DFU mode.

Thanks! That's most likely it - if you have the D0 (the 'button' pin) connected to VDD it'll wait in the bootloader for you to release it.

[espruino-discuss]

Posted at 2019-09-30 by amandala

Hmm not what I found though.. Test it again with MDBT v2.00, the result is good, similar to the -DK v2.01. But going to latest MDBT, from v2.01 - 2.04, the extra 1.1sec boot time is coming back. To avoid doubt on D0 (BTN1), I put hard short to GND on that port too..
Here's the extended boot time on MDBT v2.01 onward, as attached.

Attachments:

• espruinoMDBT42Q_2.png

[gfwilliams]

Posted at 2019-10-01 by @gfwilliams

Ok, so I just tried compiling an NRF52832DK firmware both with and without the bootloader. The bootloader does appear to add a significant delay (time between when you release the RST button and LED1 flashes) and I just checked the delay comes from a check nrf_dfu_app_is_valid inside Nordic's bootloader code, which is performing a CRC on the code in flash memory.

I discovered that was being done twice when it wasn't required, and I have just pushed some changes to avoid that - but it's still pretty slow and costly, and even to get my changes would require re-updating the bootloader.

However the code itself checks first to see if there's a valid CRC, and if the CRC is set to 0 it doesn't bother checking.

So try running this code in Espruino:

E.setFlags({unsafeFlash:1})
require("Flash").write([0,0,0,0], 0x7F000+28)  

It should remove the bootloader delay pretty much completely by stopping it from performing the CRC.

[espruino-discuss]

Posted at 2019-10-02 by amandala

Thanks Gordon, that works well on MDBT binary V2.04.
In the process I think I manage to run that two line of codes on my PPK, and took me whole day to recover.

Attachments:

• bootnRF52_3.png