Xiao BLE long boot-up time

Products & Technology XIAO
#1

Hi all! I have seen some old posts regarding long boot-up time, but not related to nrf52 board. Hence I am starting a new topic (my apologies if I missed an existing thread).

I have a xiao ble board which i have uploaded (using Arduino IDE) with a simple sketch:

void setup() {
}

void loop() {
  delay(5000);
}

I hooked up GND and 3.3V pin to Nordic PPKII to trace the current consumption. What I notice is that it takes about 500ms for the boot-up to complete. I also traced the state of the RST pin - almost immediately after power up the pin is pulled low for about 1.6ms.

Is this the expected behavior? I am trying build a sensor that is powered by a small energy-harvesting module (with a 1F supercap) and in this case I looking to reduce energy consumption (the board is shut off and woken up periodically)… Thanks for any hints and pointers :slight_smile:
PS: I am not able to attach screenshots of the power profiler in the post - any tips on how to do this? Thanks!

#2

Hi there,
No the PPK should be connected to the Battery Pads if you want to Test the True Power consumption, Using the 3.3v pin , Seems odd the long delay though.
Also if you have the USB connected it will check the Battery for charge and that too adds to the boot time.
Msfujino has several posts on it that include the PPK wave forms and callout. Look to those also., and perhaps he will comment.
HTH
GL :slight_smile: PJ
:v:

#3

are you connected to the USB at the same time? The USB port may be negotiating with the computer or power bank during this time?

#4

Thanks for the replies. I am have not connected the board to usb while measuring the power. I uploaded the sketch via usb, removed the cable, and then connected the ppk2 to 3.3v pin. I tried the battery pads : timing-wise the results are same; i.e 500ms for startup. The reason i use the 3.3v pin is that i achieve 0.8uA current in system off sleep. With the battery input it is about 4uA. I will also check other posts to see if I am doing something wrong. Have a nice day/evening :slight_smile:

1 Like
#5

Hi Ganesh_R,
During the 500mS startup period after power-up, I believe this is setting up the clocks, peripherals, and lots of registers to get the sketch ready to run. It is a setting for everyone, so there may be many settings that your sketch does not need.
DeepSleep has very low current, but requires a large current for 500mS when it wakes up. LightSleep, however, consumes a little more current but does not require a 500mS wakeup period.

I have never used it, but if you use Nordic’s development tools and write only the necessary settings, the startup time may be reduced.

1 Like
#6

Agreed… like when booting old computers that had to do a ram test … its like a Bios thing
By bios i mean prior to when the OS takes over

#7

Thanks for the tips. I was able to dig a bit deeper in to this. The 500ms delay is caused by the DFU_DBL_RESET_DELAY that is used to recognized if the bootloader reenters in 500ms. While hunting this down, I also found that Adafruit has built an escape route to avoid DFU (by setting NRF_POWER->GPREGRET register to DFU_MAGIC_SKIP). This did the job! The „real“ boot-up time is varying between 5-10ms which is comparable to a „pure“ nrf connect-base app. I will do some more tests to ensure that the dfu skipping does not break something else.

2 Likes
#8

Ganesh_R,
Thank you very much for the very interesting information.
Is 500mS the time to detect if the “2 resets” put the device into DFU mode? If so, does it also enter DFU mode when skipped with DFU_MAGIC_SKIP?
Could you please point me to the relevant link on Adafruit site so I can read it?

edit
I found “check_dfu_mode(void)”. I will read it in detail.
If the effect of “DFU_MAGIC_SKIP” is limited to a single wakeup, it could be used successfully.

1 Like
#9

@msfujino The GPREGRET register survives only warm restarts (also confirmed in the Nordic forum).
Something which is worth mentioning is that it is not possible to directly write to the register (causes memory overwrite exception). The right way is to use the register write function:

void deepSleep(){
  flashTransport.runCommand(0xB9);
  flash.end();
  sd_power_gpregret_set(0, 0x6D); //Set GPREGRET0 to 0x6D (DFU_MAGIC_SKIP)
  systemOff(PIN_WAKEUP, HIGH);
}

So far I am really happy with the results (boot-up time ca. 4ms !). But then my ultimate goal is to enable the “dfu magic” selectively even across cold restarts (in my project I use the TLP5110 to power up the NRF). To the best of my understanding so far, I will need to create a custom bootloader. I am planning to steer the DFU behaviour using a GPIO. I will update this thread with the results.
Thank you all for your inputs and suggestions!

1 Like
#10

Ganesh_R,
I am very interested in your project and will continue to follow your thread. What power supply are you using?
I think “sd_power_gpregret_set(0, 0x6D)” will have a great effect in DeepSleep and Wakeup applications without TLP5110. I will test the effect.

edit
I tried, but it stays at 500mS and not 4mS. I think something is missing. Could you please show me your sketch?

#11

@msfujino, I am using the BQ25570 energy harvester chip which obtains power from an AM1801 PV array (appox 60uW @200 lux). I am using a 0.22F capacitor to store energy. This blog page has some practical hints about using the BQ25570 board available in aliexpress.

The TLP5110 wakes up periodically (in my case every 10s) and wakes up the xiao ble board (I would like to change this to power up). The TLP has very low quiescent current of about 60nA. There is also an SHT41 temperature+humidity sensor. If the measured storage voltage is above 2.2V, then I initialize the sensor, measure, and do a single BLE advertisement. At the moment the sleep current of xiao ble is hovering around 1.2uA (if I dont use the pin wake-up and instead do a shutdown then the current is 0.8uA).

I am working on a custom version of the bootloader where the DFU is enabled only if a pre-defined pin is held high during startup. I will keep you posted :slight_smile: Have a nice day!

#12

Ganesh_R,
Thanks for the info on the power supply.
I am trying to see if the magic “sd_power_gpregret_set(0, 0x6D)” you taught me can reduce the boot time to 4mS, but it is still 500mS. I think I am missing something, can you show me a sketch to get it to 4mS?

#13 
//sd_power_gpregret_set(0, 0x6D);
NRF_POWER->GPREGRET = 0x6D;

The startup time could be reduced to 4mS.

#14

@msfujino Thanks! Its interesting - in my case I had sporadic crashes due to writing directly to the GPREGRET. I guess it has to do something with the exact bootloader version on the board? I will check this out.

#15

A short update on my experiments:

  1. It is possible to get rid of the 500ms “double click” wait time in the bootloader by customizing the code. But this will incur providing an alternative method to enter the serial bootloader (in my case I used a pre-defined pin).
  2. That said, there is a very delicate balance when it comes to deciding a full shutdown vs system-on sleep. The overhead of initializing uart, i2c, ble etc. can override the benefit of ultra-low current achieved by system-off.
  3. In the current state of tinkering, I have been able achieve a battery-less T+Rh sensor (as BLE peripheral) which uses the AM-1801 PV module (with 0.22F cap) powered by indoor lighting (approx 200 lux) and measures every 5 seconds.

In summary, I still think being able to program using Arduino framework is a great advantage for explorative work. i.e. in comparison to ramping up with Zephyr, NRF Connect & Co. :slight_smile:

1 Like
#16

It would be interesting to compare the current consumption of “shutdown → cold start” and "System on Sleep → Wakeup with the measurement interval as a parameter.