What are the checkpoints to successfully power HSE32 TCXO?

[Ziga S.]

Some facts:

LoRaWAN_Init reports no errors, seems that calibration went through OK...?

(RadioError result = 0)

After trying out different power-modes(LDO/SMPS) and

trying to put the Radio into StandBy(to measure the voltage on TCXO_VDD pin)

RadioError becomes more pessimistic:

for example: XoscStart = 1

I would expect that if, Radio is in StandBy would leave HSE32 powered on.

Seems that Radio.Send()/SUBGRF_SetStandby(STDBY_XOSC)

after-all reported proper state of the peripherals.

Does anybody have a clue how to troubleshoot?

Any advice highly appreciated.

Thanks and BR

[Tesla DeLorean]

>>Does anybody have a clue how to troubleshoot?

Aren't there specific API paths to turn it on/off, and delays?

Perhaps directly instrument that stuff, and the methods by which it decided to turn off, perhaps using a timeout to determine inactivity vs turn on delay expectations.

[Ziga S.]

There are many paths, but only few can pass the success 🙂

Hardware internals look alike this:

My first thoughts were not in Radio component, but in communication with it.

Seems that this is working with SPI 4MHz and 2MHz and 512kHz correctly.

Calibration delay is also quick, somewhere in docs I have read few milliseconds.

I would say that calibration should not tolerate defunct TCXO.

But it goes through, as I experience it.

Maybe for calibration it is enough the internal 13MHz clock... don't know

Does not matter, I know, the path where it should turn on is missing something.

Maybe not in the init, maybe not in code but in procedure.

There are many layers of software.

I guess this piece of code should prove it:

MX_LoRaWAN_Init();
 
// No complaints, No low-power enabled yet
 
RadioError_t re;
re = SUBGRF_GetDeviceErrors();  // <- re = 0
SUBGRF_SetStandby(STDBY_XOSC); // Should stay powered on?
re = SUBGRF_GetDeviceErrors(); // <- XoscStart = 1

On STM32WL-Nucleo I really had no problems sending LoRa payloads.