XIAO BLE unstable when 32KHz clock source is crystal

Products & Technology XIAO
1

Hello everyone,

I’ve been using the XIAO BLE nRF52840 for a few months now, and I’ve had great success. This forum has been incredibly helpful in resolving various issues, including battery management.

Thank you for this great community.

I programmed the board using Zephyr OS and have been successfully utilizing Bluetooth Low Energy features, including pairing and all other functionalities. I’ve also been working with GPIOs, PWM, ADC, the Watchdog timer and various other features.

However, I’ve encountered a significant issue. The board occasionally stops functioning for 20 minutes to multiple hours. During these periods, the firmware fails to boot, but the bootloader remains operational. After a random amount of time, sometime after several hours, the board will reboot itself, and everything will work magically again.

  • This problem was present in my firmware with Zephyr OS, as well as in a Zephyr OS blink example.
  • Interestingly, the UF2 bootloader was not affected by this issue. The remote drive appears on my computer, the LED works, and everything else functions correctly.
  • Additionally, an Arduino Code blink example using the Arduino IDE was also free from this problem.

I can now say that it is likely that my own C code is not the culprit.

Given these observations, the question now arises: why does Zephyr OS occasionally and unpredictably fail to boot?

I’ve discovered a potential solution, and I’m 90% certain it works. However, due to the intermittent nature of the issue, I’m waiting to gather more data to confirm the fix definitively.

Using the internal RC clock instead of the external 32Khz crystal seems to fix the problem.

To address this issue, I made the following changes in my prj.conf file.
These configurations instruct Zephyr OS to use the RC oscillator as the clock source (instead of crystal oscillator). They specify that the RC oscillator is precise to 500 ppm (as per the nRF52840 datasheet) and enable automatic calibration of the RC clock.

# Clock (the external crystal is instable. Use the internal RC.)
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y
CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC_CALIBRATION=y
CONFIG_CLOCK_CONTROL_NRF_CALIBRATION_LF_ALWAYS_ON=y

I’m not an expert in electronics crystal oscillators, but I understand they’re highly sensitive and can cause erratic behaviors.

Does anyone here have more knowledge about this issue? Is there a more reliable solution than relying on the internal RC clock of the chip? How can I fix the external crystal?

Maybe the problem is something else. In theory this bug shouldn’t exist, otherwise the problem would be known.
So, most probably the problem is something else unrelated.
Debugging these bugs is quite hard.

I appreciate all your help.

Some facts:

  • When I refer to “board,” I mean the XIAO BLE nRF52840 black PCB that has been soldered onto another PCB with various components.
  • The bug appears at different times on different boards. I’m not sure how to interpret this.
    • Some boards have never shown the bug.
    • Some boards show the bug once every two weeks.
    • Some boards show the bug once every day.
    • Some boards show the bug once every hour.

Perhaps our soldering process has damaged the board? It would be surprising because the soldering process is quite quick and painless. Alternatively, the flux I use to solder boards might infiltrate the shield and cause damage.

2

Hi there,

SO, You are building the firmware with boot loader then?
I’m pretty sure NO board file exists for the Xiao in Zephyr it’s NOT in the Boards in-lined in the repo. So more than Likely you used what you think is a good board file. I would look there, :v:

Seeed NEVER submitted one to the Project and verified it’s maintained to be accepted. Thus coming up SHORT. It and they relies on the NRF_SDK board definitions to build from.(IMO that’s half-ass) Maybe installing that would fix it somehow but YMMV.

HTH
GL :slight_smile: PJ :v:

What is the name you use to build it with the West commands?

3

Thank you for your answer!

SO, You are building the firmware with boot loader then?

No, I found a potential fix by changing the clock source from external crystal to internal RC. (I tried to explain it in my first post) So I build the firmware seperate from the bootloader as “usual”.

I’m pretty sure NO board file exists for the Xiao in Zephyr it’s NOT in the Boards in-lined in the repo. So more than Likely you used what you think is a good board file. I would look there, :v:

Yes a board file exist for the Xiao BLE in Zephyr right in their official repo. Here is the link.

https://docs.zephyrproject.org/latest/boards/seeed/xiao_ble/doc/index.html

I use that to compile my project to UF2.

Here is your “official” doc on Zephyr.

What you are saying is that I should review the board definition and maybe there is an error in the crystal definition in there?

Thank you so much for your help!!

I am just using west build with the nRF Connect SDK in VSCode. The configuration is: Board: xiao_ble, qualifiers: nrf52840/sense

4

Hi there,

Well some good news,:+1: I checked your link. WOW. they must be listening to the complaints… LOL :grin:
There never was a Zephyr Board defined , I see they got there act together finally.

  • Previously, Zephyr did not officially support the Seeed Xiao nRF52840.
  • Developers had to use Nordic’s nRF SDK device tree and a custom board definition.

SO now, with 3.6 (2024) there is an official board definition! GREAT !

  • This means that Zephyr now has official support for the Seeed Xiao nRF52840!
  • However, this board definition was added recently and may still rely on some Nordic nRF52840 defaults.

Also if you are using 3.6+ the name changed to
west build -b seeed_xiao_nrf52840

I suspect it’s in the build. You will need to test more or debug using an external Jtag/SWD probe and see what is crashing it or corrupting it or making it sleep?

Good Stuff, fun to troubleshoot. I am suspect of the recently added board file FWIW :wink:

HTH
GL :slight_smile: PJ :v:

Do you have the Nrf_sdk installed ? would be curious to know. I can build it in West no issue’s, apps run in flash AOK no lockups or stopage’s other than my partitions for the DFU and MCUBoot still have an error when I try to add the bootloader to the build. YMMV :crossed_fingers:

I see also they added the Expansion Dev board & round display, Awesome.

1 Like
5

I use nRF Connect SDK, which ships with Zephyr OS, yes!
It works perfectly out of the box, wich generate an UF2 binary etc.
I didn’t try MCUBoot.

There is a catch when building, we must disable sysbuild from the build configuration. Otherwise the compiled UF2 binary doesn’t run.

Thank you for your insight, I will take a look on the nRF52840 defaults I guess.

Our PCB doesn’t have exposed SWD headers so I have to find a smart way.

Thank you very much for your help!!

This clock stuff really is giving me nightmares :joy:

6

Hi there,

Sure, Thing… seems to me it’s a board file issue or overlay but more than likely the board file, after looking more into it. The Zephyr actual board file does not have the same definition as the SDK so there is still an issue with that, either the naming convention is incorrect or they have both the BLE and Sense versions mixed. The Main line repo for Zephyr has it different than the LINK so WTH? Looking through the Boards folder in the Seeed file.

the sysbuild is primarily used when building bootloaders (MCUBoot) and application images together.

no your situation wouldn’t require it.
I would almost bet the EXTernal Crystal stuff isn’t in there.
or if so it’s wack. Debug will get you in :+1:

HTH
GL :slight_smile: PJ :v:

1 Like