Showing results for 
Search instead for 
Did you mean: 

Antenna doesnt transmit in STM32WL55 Generic node based on Lorawan_End_Node

Associate II

Hi All,

I am working with the STM32WL55 MCU in a project-based between Generic Node and MB1389 (Nucleo board). my code is using Lorawan_End_Node.

Everything seems to be working well but the radio part is not transmitting (checking it with AIRSPY an a SDR device). We can see the LoRaWAN messages debug logs and it tries to connect to the network but no radio at all.

Things we have seen:

  • VDD1V5 is around 2V.
  • PB0_VDD_TCXO is around 0.7V.

I did all the steps from this tutorial:

the hardware design is

 Our design main difference is that we are using 32MHz HSE TCXO with 3.3 VDD, we modified TCXO_CTRL_VOLTAGE from TCXO_CTRL_1_7V to TCXO_CTRL_3_0V in radio_conf.h

I checked the voltages in PB0_VDD_TCXO is 0.756 V (always), it must be arround 3.0 V... and VFBSMPS is 1.945v and it must be maximum 1.62 (datasheet).

Firmware shows as it is transmiting properly (i am only testing Phy layer, not Lorawan):

###### OTAA ######
###### AppKey:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
###### NwkKey:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
###### ABP  ######
###### AppSKey: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
###### NwkSKey: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
###### DevEui:  00-00-00-00-00-00-00-00
###### AppEui:  00-00-00-00-00-00-00-00
0s046:TX on freq 868100000 Hz at DR 0
2023/05/29 12:49:15: 4s072:MAC txTimeOut
###### = JOIN FAILED
2023/05/29 12:49:21: 10s073:TX on freq 868500000 Hz at DR 0
2023/05/29 12:49:25: 14s098:MAC txTimeOut
###### = JOIN FAILED
2023/05/29 12:49:31: 20s073:TX on freq 868100000 Hz at DR 0
2023/05/29 12:49:35: 24s098:MAC txTimeOutt

Any help is welcome

Best Regards,


Associate II


hello, did you resolve your problem?

I have the same problem with my custom board.

but voltage VDDRF1V55 = 1.5V

all other 3.3V

and I don't receive any interrupt from the SUBGHZ module and doesn't anything transmit

Associate II

Hi @Yevhen​ ,

Thanks for your response, but i did not resolve my problem. My code is the same and firmware looks like it is working but antenna is not transmiting (checked with Gateway properly working and SRD tool)

Associate II

Does interrupt from subGhz work?

Associate II

@RPaja.1 check the 32 mhz quartz. My was wrong solder, and after fix it - subghz module is working good

Associate II

Thanks @Yevhen​ , i will check it and let you know. Regards


This is one of the first search results for "MAC txTimeout", so I thought I would document my experience and solution.

"MAC txTimeout" is a generic error printed by OnRadioTxTimeout() in Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c. It occurs when the SubGHz PHY times out during a transmit. That is, the SubGHz PHY did not notify the application that the transmit was completed (the error does not mean that the transmission failed to be acknowledged by the LoRa gateway). If you're experiencing this error, it's likely that the SubGHz PHY interrupt is not working properly (SUBGHZ->NVIC Settings->Enable interrupt must be ticked; validate that the interrupt is being processed correctly).

In more detail:

The timeout referred to in the error message (4 seconds aka 4000ms, hard coded) is defined in Middlewares/Third_Party/LoRaWAN/Mac/Region/RegionEU868.c (or the relevant file for your configured region). The value is passed to a timer, which fires a timer interrupt when it expires.


657: Radio.SetTxConfig( modem, phyTxPower, 0, bandwidth, phyDr, 1, 8, false, true, 0, 0, false, 4000 );


Increasing this timeout will probably not help, because it's not a timeout on the time to get a response from the LoRa gateway, it's a timeout on the modem hardware completing the packet transmission. 4000ms is plenty for a 24-byte packet at DR_0.

The modem notifies the application that transmission is complete by firing an interrupt. This interrupt is handled by RadioOnDioIrq() in radio.c and control eventually passes to one of the first three callback functions below, all in Middlewares/Third_Party/LoRaWAN/Mac/LoRaMac.c. The two timeout callbacks are triggered by a timer, not from the radio interrupt.


    MacCtx.RadioEvents.TxDone = OnRadioTxDone;         // triggered by SUBGHZ interrupt
    MacCtx.RadioEvents.RxDone = OnRadioRxDone;         // triggered by SUBGHZ interrupt
    MacCtx.RadioEvents.RxError = OnRadioRxError;       // triggered by SUBGHZ interrupt
    MacCtx.RadioEvents.TxTimeout = OnRadioTxTimeout;   // triggered by Timer interrupt
    MacCtx.RadioEvents.RxTimeout = OnRadioRxTimeout;   // triggered by Timer interrupt
    Radio.Init( &MacCtx.RadioEvents );


OnRadioTxDone is key, because (through an indirect path) it calls ProcessRadioTxDone(). This is the function that puts the modem into receive mode (after a 5s or 6s time interval proscribed by the LoRa protocol) and listens for the Join-Accept packet, or any downlink messages.

So, if the radio interrupt never fires, all that is left is OnRadioTxTimeout, which prints the "MAC txTimeout" error message, and the modem will never be placed into RX mode.

Other potential gotchas

  1. As others have noted, the STM32WLE is a special case when you use a crystal oscillator on the HSE32 input - capacitors are built in to the chip, and you must not include your load capacitors for the crystal. This is discussed briefly in the reference manual (RM0453 section 5.4.2) and in AN5042.

    It's critical that the HSE32 32MHz clock be very, very close to 32MHz, because otherwise the LoRa transmit frequency will be wrong and the gateway will ignore you. A spectrum analyser and a near-field probe was useful to measure the clock frequency, and you can adjust the built-in capacitor value by changing XTAL_DEFAULT_CAP_VALUE in LoRaWAN/Target/radio_conf.h (you can also just calculate the correct capacitor values for your crystal in the usual way, and set this variable appropriately if you do not have a near-field probe). Note that this variable is overwritten by STM32CubeIDE when you generate code.

    Alternatively, consider using a TCXO instead of a crystal, as the frequency accuracy matters.

    In the clock configuration, it does not seem to matter which speed or source the SYSCLK runs from (though more accurate is better for timing reasons, see #2 below) as the SubGHz PHY takes its clock directly from HSE32 regardless of SYSCLK.

  2. If your SYSCLK frequency is inaccurate (eg, you use MSI for some reason), you might schedule the receive window incorrectly and miss the gateway responses. You can increase the tolerance in the receive window by changing the line below in LmHandlerConfigure(), in LmHandler.c to a higher value.


    /* Set system maximum tolerated rx error in milliseconds */
    LmHandlerSetSystemMaxRxError( 20 );


Alternatively, a more accurate system clock is probably a better idea.

  • Double check that your Device EUI, App/Join EUI, Application Key/Network Key (usually set to the same value), Device Address (usually set to zeros, so it can be auto-assigned) values all match the backend, otherwise it will ignore you. Double check them!

  • Others have mentioned that it is possible for  LoRa node and a LoRa gateway to be too close and cause transmissions to fail - because the transmit levels are quite high and the receive path very sensitive. I didn't experience this, but consider ensuring the gateway is 10m+ away and/or installing an attenuator on the gateway antenna.


A USB SDR dongle plus software that can display the RF spectrum in a waterfall plot (eg, gqrx) is extremely useful to understand what is going on.

I hope this saves someone a week of debugging!