nRF54L15 blinky will not return from k_msleep()

[Ryan S]

Hi, 

I am currently developing on the BL54L15 Ezurio development kit with the Nordic chip. 

I am using the Nordic v3.0.1 SDK and toolchain with the new manufacturer board files from the zephyr repository https://github.com/zephyrproject-rtos/zephyr/tree/main/boards/ezurio/bl54l15_dvk

I have tried both the blinky and button sample - but code execution seems to stop when reaching the k_msleep() function. I have not had this issue with the nRF54L15 development kit using the same SDK and toolchain.

When I try to enter debug mode (following the usual way outlined in the dev academy course) - I get the following message: 

'Unable to start debugging. GDP exited unexpectedly with exit code -3 (0xFFFFFFFD). Could not connect to target. No target voltage detected or connection failed.'

I understand that nordic is not responsible for manufacturing this board - however I was wondering if you could suggest any starting points for debugging the fault in k_msleep in case there is an error in the board files or hardware. 

Thank you very much. 

[Kazi Afroza Sultana]

Hello,

The accuracy and behavior of k_msleep() are directly influenced by the LFCLK configuration and source (e.g., RC oscillator, crystal oscillator, or synthesized clock. The default LFCLK source is the LFRC. If your board does not have an external 32.768 kHz crystal, you should explicitly set the LFCLK source to the internal RC oscillator. You can set these in the prj.conf file

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=n
CONFIG_CLOCK_CONTROL_NRF_K32SRC_SYNTH=n

Regarding this '''Unable to start debugging. GDP exited unexpectedly with exit code -3 (0xFFFFFFFD). Could not connect to target. No target voltage detected or connection failed.'' error, it may indicate the custom board is not properly powered.

You can check the power supply if it is properly powered, check the debug connections and cables. Trying with external debugger could be an alternative choice if onboard debugger does not work. In addition to there, try power cycling the board and erase the board completely before flashing.

[Ryan S]

Hi Kazi, 

Thanks for your response. 

I have just tested that there is indeed a 32kHz signal at the crystal. The user guide recommends setting internal cap to 9pF and I have done that. 

However unlike the nRF52L15-DK, the Ezurio board doesn't have an external HFCLK 32MHz. Although when I measured this X2 crystal on the Nordic DK - the weren't any oscillations. 

In my case, would the HFCLK need to be configure as internal as well? If so, could you please provide the configurations to do this?

Otherwise - if you had any other suggestions I would love to hear them. 

Thanks so much. 

[Ryan S]

Figured out the issue. 

For anyone who has the same devkit, make sure you enable the following config:

# Start SYSCOUNTER on driver init
CONFIG_NRF_GRTC_START_SYSCOUNTER=y

It seems to be missing from bl54l15_dvk_nrf54l15_cpuapp_defconfig on the current zephyr repo.

[H. Dekker]

Hi Ryan,

Thanks for sharing your findings!

I'm currently testing on the Raytac AN54L15Q-DB (raytac_an54l15q_db) and I ran into the exact same issue you described — although in my case it happened while using just the k_sleep() function. It's a bit unfortunate that this behavior and the required configurations are not better documented.

I also added the following line to my prj.conf file:

# Start SYSCOUNTER on driver init 
CONFIG_NRF_GRTC_START_SYSCOUNTER=y

After doing that, everything works perfectly on the Raytac AN54L15Q-DB!

This option is specific to the GRTC timer used on the nRF54-series (like the nRF54L15), and it's different from the system timer setups on older chips like the nRF52 or nRF53. Without explicitly starting the SYSCOUNTER, time-based functions like k_sleep(), k_msleep(), k_timer() or any other timed delay or scheduling feature may silently fail — which makes it a somewhat tricky issue to track down.

Interestingly, the official Nordic nrf54l15_dk board does work out of the box, because it includes this option in its board-level defconfig. The Raytac and Ezurio board’s BSP leaves it out, which is likely the root cause of the issue when using it as a custom board.

If you’re using this board more often, it’s probably a good idea to add CONFIG_NRF_GRTC_START_SYSCOUNTER=y directly to your board’s defconfig to avoid needing it in every project.

Just to clarify: this issue is not related to the presence or absence of an external crystal (LF or HF). The GRTC timer can run on the internal clock sources just fine, and the missing SYSCOUNTER start is purely a configuration oversight — not a hardware issue. So unless you need long-term timing accuracy or precise radio timing (e.g., for BLE), an external crystal is not required for k_sleep() or system timers to function.

Thanks again for pointing this out!

Best regards,
Herke