Antenna doesnt transmit in STM32WL55 Generic node based on Lorawan_End_Node

@RPaja.1​ 

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

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)

Does interrupt from subGhz work?

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

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!