I’m facing a recurring issue with the LSE (Low-Speed External) oscillator on several new Wio-E5 modules used in my custom PCB design, and I’d like some help verifying if this is a hardware or firmware-level change in recent production batches.
I have designed a custom PCB based on the Seeed Studio Wio-E5 reference design (RHF0M0E5-HF22-BOM20211111).
This design was successfully used in a LoRa application, where several boards from an earlier batch of Wio-E5 modules worked flawlessly — no issues with clock startup or LoRa communication.
Recently, I procured a new batch of Wio-E5 modules and assembled the same PCB design.
However, all of these new boards (3 tested so far) consistently fail during LSE initialization.
Observed Behavior
When running the firmware (based on the Seeed Wio-E5 GitHub repo: danak6jq/Seeed-LoRa-E5), the code consistently gets stuck in:
while (LL_RCC_LSE_IsReady() == 0U)
{
if ((HAL_GetTick() - tickstart) > RCC_LSE_TIMEOUT_VALUE)
{
return HAL_TIMEOUT;
}
}
This results in an LSE timeout — the LSERDY bit never gets set.
I also attempted to switch to LSI as the RTC clock source, but even then, the MCU seems to get stuck in the same section of the initialization routine (HAL_RCC_OscConfig()).
What I’ve verified:
- PCB layout and passives are identical to the working design.
- LSE drive set to high, backup domain access OK.
- CubeMX configured for LSE crystal, PC14/PC15 mapped correctly.
- Added diagnostic flags — confirms
LSEONset butLSERDYnever ready. - Tested multiple units — all new modules fail, old ones OK.
Any insights from Seeed engineers or anyone who has experienced similar behavior with newer Wio-E5 batches would be greatly appreciated.
Thanks in advance!