Unable to use HSE external crystal with STM32WLE5CCU6

[Martdur]

I'm working with the stm32WL series trying to use the HSE clock instead of the tcxo for the lorawan communication.

I've managed to make it works on the nucleo-wl55jc board by removing the following line:

dio3-tcxo-voltage = <SX126X_DIO3_TCXO_1V7>;
tcxo-power-startup-delay-ms = <5>;

and activating the hse clock :

&clk_hse {
	status = "okay";
};

But when I use the same code on my custom board with a STM32WLE5CCU6 this doesn't work and the mcu seems to not boot up at all.

When I disactivate the hse clock I get this infinite wait :

[00:00:00.001,000] <dbg> sx126x: sx126x_lora_init: Initializing sx126x
[00:00:00.001,000] <dbg> sx126x: SX126xReset: Resetting radio
[00:00:00.031,000] <dbg> sx126x: SX126xIoIrqInit: Configuring DIO IRQ callback
[00:00:00.031,000] <dbg> sx126x: SX126xWakeup: Sending GET_STATUS
[00:00:00.031,000] <dbg> sx126x: SX126xWakeup: Waiting for device...

Which make sense because no hse is activated.

But I don't understand why the uC doesn't log anything when the HSE is on.

If someone has any idea on the subject.

[Martdur]

I've tried some config mentioned here 37260 but nothing changed.
Maybe you have some input on this @erwango.

[sense-Jo]

When I tried different clock configurations on a STM32WLE around one and a half year ago, I also recognized that many of them did not really work.
Is there a reason you want to use the HSE for the CPU clock?
For us, using the MSI (at 4 MHz) is working fine, and I think it would also consume less power then the HSE.
Nevertheless, for RF (e.g. LoRa), you'll still need to have the HSE on the board, since the radio requires it.

[Martdur]

And how your lorawan node is defined ?
Mine is as follow :

&subghzspi {
	status = "okay";
	lora: radio@0 {
		compatible = "st,stm32wl-subghz-radio";
		status = "okay";
		tx-enable-gpios = <&gpioc 4 GPIO_ACTIVE_LOW>; /* FE_CTRL1 */
		rx-enable-gpios = <&gpioc 5 GPIO_ACTIVE_LOW>; /* FE_CTRL2 */
		//dio3-tcxo-voltage = <SX126X_DIO3_TCXO_1V7>;
		//tcxo-power-startup-delay-ms = <5>;
		power-amplifier-output = "rfo-hp";
		rfo-lp-max-power = <15>;
		rfo-hp-max-power = <14>;
	};
};

My code run when not using lorawan and with hse disactivated but when I want to use lorawan the stack just get stuck at the start.

On which board are you running this code ? Do you have a external Xtal or a external tcxo ?

Edit : I'm on the main branch, don't know which commit but I updated it no later than last month

[sense-Jo]

I am working with a custom board, it has an external xtal. What is on your board?
My radio node definition in the device tree is basically the same, a difference is that I'm using the lp rfo.

[Martdur]

I'm using two external Xtal, one for lse and one for Hse.
I have no load capacitance for hse as it is not needed in our uC.

[Martdur]

Apparently when hse is activated it get lock at:

Finished reading symbols from nm: Time: 426 ms
z_arm_reset () at C:/Users/dev/zephyrproject/zephyr/arch/arm/core/cortex_m\reset.S:119
119	    movs.n r0, #_EXC_IRQ_DEFAULT_PRIO
Program stopped, probably due to a reset and/or halt issued by debugger

while calling :

__STATIC_INLINE uint32_t LL_RCC_HSE_IsReady(void)
{
  return ((READ_BIT(RCC->CR, RCC_CR_HSERDY) == (RCC_CR_HSERDY)) ? 1UL : 0UL);
}

Otherwise with Hse desactivated :

 received signal SIGINT, Interrupt.
0x08014a38 in LL_SPI_IsActiveFlag_TXE (SPIx=<optimized out>) at C:/Users/dev/zephyrproject/modules/hal/stm32/stm32cube/stm32wlxx/drivers/include/stm32wlxx_ll_spi.h:918
918	  return ((READ_BIT(SPIx->SR, SPI_SR_TXE) == (SPI_SR_TXE)) ? 1UL : 0UL);

while calling :

#else /* CONFIG_SPI_STM32_INTERRUPT */
	do {
		ret = spi_stm32_shift_frames(cfg, data);
	} while (!ret && spi_stm32_transfer_ongoing(data));

[Martdur]

I saw that erwango is in vacation, so maybe you can give me some help on this @martinjaeger ?

[Martdur]

We found the issue, it was hardware related so sorry for the inconvenience.

The issue is that VDDRF was not connected to VDD as we based out hardware on the reference design MB1720 and MB1848.
This post still can be useful to indicate that in both st reference design MB1720 and MB1848 VDDRF and VDD are not connected as they should be.

Thanks a lot for your help @sense-Jo.