350ms Booting Time nRF53840

[Flaschenpost]

Hi,

I try to create a one-button minimal "smart watch" based on a small nRF52840 module (register button press) and a second nRF52840 'central station' (receiving and converting it to multimedia play/pause).

My goal is to press a small button on the watch that powers the "sender" up, this sends a message (gazell or ESB) to the stationary main station and goes back to sleep. There is no place for a real power switch, and the device is needed once in a week for around 10 actions, so this "power on, fire, power off" seemed perfect. The power is only on as long as the button is hold.

The problem is that my main loop is entered only after hundreds of ms. I think a button press time of ~ 100ms is fine for the whole process and should be reachable. But holding it for 500 ms is not good. As a first step I used two ProMicro (Nice!Nano) modules, which have an actual boot loader (but is too big).

*** Booting nRF Connect SDK v2.6.99-46f6922cce98 ***
*** Using Zephyr OS v3.6.99-25fbeabe9004 ***

I started with the ESB examples esb_ptx and esb_prx and stripped the ptx down to a minimum. 
I compile with 

`west build -p -b nrf52840dongle/nrf52840 . -DCMAKE_BUILD_TYPE=Release`

and copy as uf2 to the device (double reset). The config is attached below.

I would expect it to take 20-50ms to enter my user main function. Is there a way to get my code running earlier in the process? Should I switch to gazell instead of ESB?

Could I define a function that is called before the initialization is finished but still able to send ESB or Gazelle Package?

(I measure the time with int64_t uptime_start = k_uptime_get(); as first line of main() and send it 
in the first ESB message, but it's not much shorter than the boot time of the central station with uart and serial and logging)

CONFIG_NCS_SAMPLES_DEFAULTS=y
CONFIG_ESB=y
CONFIG_DK_LIBRARY=y
# CONFIG_SOC_NRF54H20_CPURAD=y
CONFIG_ESB_FAST_SWITCHING=y
CONFIG_BUILD_OUTPUT_UF2=y
CONFIG_BUILD_OUTPUT_UF2_FAMILY_ID="0xada52840"
# Basic kernel settings
# CONFIG_MAIN_STACK_SIZE=1024
# CONFIG_SYS_CLOCK_HW_CYCLES_PER_SEC=16000000

# Reduce logging and debugging overhead
CONFIG_PRINTK=n
CONFIG_UART_CONSOLE=n
CONFIG_CONSOLE=n
CONFIG_LOG=n
CONFIG_SERIAL=n
CONFIG_SHELL=n

CONFIG_HW_CC3XX=n
CONFIG_ENTROPY_CC3XX=n
CONFIG_ENTROPY_NRF5_RNG=y
CONFIG_CC3XX_BACKEND=n

CONFIG_POWEROFF=y

CONFIG_NO_OPTIMIZATIONS=n
# CONFIG_SIZE_OPTIMIZATIONS=n
CONFIG_SPEED_OPTIMIZATIONS=y

# Disable USB device stack
CONFIG_USB_DEVICE_STACK=n

# Disable specific USB classes
CONFIG_USB_CDC_ACM=n

# Disable USB drivers
CONFIG_USB_DRIVER_LOG_LEVEL_OFF=n

# Disable stack canaries (safety feature to detect stack overflows)
CONFIG_STACK_CANARIES=n
# Disable assertion checks
CONFIG_ASSERT=n

# Disable unused features
CONFIG_NETWORKING=n
CONFIG_BT=n
CONFIG_NET_BUF=n

# Enable minimal ESB support
CONFIG_ESB_MAX_PAYLOAD_LENGTH=32

# Reduce application init priority
# CONFIG_APPLICATION_INIT_PRIORITY=0

[Vidar Berg]

Hello,

Do you have an external J-Link debug probe you can use to program the module without using the bootloader? I don't know the exact startup time for this bootloader, but the boot time would be significantly reduced if you could remove it. 

You can also try adding CONFIG_SYSTEM_CLOCK_NO_WAIT=y to your prj.conf. This will make a big difference if your are using the crystal oscillator for your 32KHz clock.

Best regards,

Vidar

[Flaschenpost]

Thanks! I will try this CONFIG_SYSTEM_CLOCK_NO_WAIT=y.

I would like to use a faster bootloader, but I am a bit afraid to brick my module. I don't have a JLink, but I could use an STlink2 or I have read that there is a blackmagic firmware for the small and cheap "bluepill" stm32 module (which lays around and waits for a usage since years).

Which Bootloader would you suggest? I really only need to send one successful ESB message and then poweroff, no bunch of OTA Update and USB update, just any one method to update my program (double-reset + uf2 right now).

I could not find a good documentation about different bootloaders.

Best regards, 

Marco

[Vidar Berg]

Hi Marco,

Bootloader implementations often focus more on features such as integrity checks of the application and DFU rather than on booting as quickly as possible. Is that something you need for your application?

Best regards,

Vidar

[Flaschenpost]

Hi Vidar,

I hope to have only one button on the "clock". The whole process of booting, sending a message and shutdown shall happen in the time of the button press. The only uptime is the button press time.

I think 100 ms is ok.

But Plan B is to have light sleep or deep sleep and then use reset, but the "clock" is only used every 2 weeks for 2 hours, I have no place for an extra real power switch, and to be powered off all the other time would be the perfect scenario.

I still have to wait for the smaller modules (E73) to arrive and I still have to check your suggestion.

Thanks for all your help!

Best regards, 

Marco