STM32WL LoRa issue

[BT.1]

We are using the STM32WL microcontroller on a custom board designed according to the reference schematic MB1582. There is an issue with LoRa - the message "MAC txTimeOut" is displayed as shown in the image.

Other functionalities- GPIOs, interrupts, I2C are working fine. We have used a 32 MHz crystal X2 as given in the reference schematic.

Note: 

1.We tried using an external clock source instead of the on-board crystal and LoRa worked partially - "MAC txDone" was displayed once in multiple attempts but we couldn't receive the data on the gateway side.

2.The sample STM32WL Discovery board uses a TCXO crystal as clock source and LoRa is working perfectly without any problem in that.

What has to be done to solve this issue?

[BT.1]

Solved the issue by using a TCXO crystal as clock source

[MAmiri]

Have you tried to remove the C26 and C31 in your schematic? According to the MB1389 and MB1720, both capacitors are Marked as N/C|DNF. The UM2592 has also mentioned 6.5.1 " No C30 and no C38 as those capacitors are integrated into the STM32WL MCU".

Let us know the results if possible.

[HVeer.1]

We are also facing same tx timeout in our custom designed hardware. We are using XO clock in the design and donot have option for TCXO. Please share your inputs whether STM32WL55JC1 will work with XO clock. We got struck with TX Timoeut issue.

[Tesla DeLorean]

Your thread, with imagery https://community.st.com/s/question/0D53W00001KTZlKSAX/stm32wl55jc1-lora-timeout-issue

Pretty sure you're going to have to manage the up/down of your own clock independently. ie so it's ready before you start the first transaction, and you shut it down again when all pending transactions have completed, and it's off-air.

[Tesla DeLorean]

Noting that, just seen a schematic without them. What's the anticipated pF load internally, and for the crystals used?

Mismatches there will impact if the oscillator starts, and the startup time.

As noted in another thread, the Semtech timeout timers are end-to-end, they don't care where the time is eaten, and will kill active Rx/Tx mid transfer if it takes to long, or the BW/SF etc don't account adequately for the packet size and air-time expectations.