2026-05-18 6:10 AM
void HAL_MRSubG_IRQ_Callback(void) {
uint32_t irq = __HAL_MRSUBG_GET_RFSEQ_IRQ_STATUS();
if (irq & MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_OK_F) {
last_rx = HAL_GetTick();
HAL_GPIO_WritePin(LD1_GPIO_Port, LD1_Pin, GPIO_PIN_SET);
if (HAL_MRSubG_GetBytesOfTransaction() <=
ring_buffer_u8_free(&radio_ring_buffer) &&
radio_packet_fifo_free(&radio_packet_fifo) != 0) {
for (uint8_t i = 0; i < HAL_MRSubG_GetBytesOfTransaction(); i++) {
ring_buffer_u8_write(&radio_ring_buffer, radio_rx_buf[i]);
}
radio_packet_t radio_packet = {
.len = HAL_MRSubG_GetBytesOfTransaction(),
};
radio_packet_fifo_write(&radio_packet_fifo, radio_packet);
}
__HAL_MRSUBG_STROBE_CMD(CMD_RX);
__HAL_MRSUBG_CLEAR_RFSEQ_IRQ_FLAG(
MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_OK_F);
}
if (irq & MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_TIMEOUT_F) {
__HAL_MRSUBG_STROBE_CMD(CMD_RX);
__HAL_MRSUBG_CLEAR_RFSEQ_IRQ_FLAG(
MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_TIMEOUT_F);
}
if (irq % MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_CRC_ERROR_F) {
__HAL_MRSUBG_STROBE_CMD(CMD_RX);
__HAL_MRSUBG_CLEAR_RFSEQ_IRQ_FLAG(
MR_SUBG_GLOB_STATUS_RFSEQ_IRQ_STATUS_RX_CRC_ERROR_F);
}
}This is my interrupt handling code. Everything initially works but after some time the radio just stops receiving the packets. The transmitter is not at fault as resetting the receiver instantly fixes the issue. Checking the radio fsm in the main function shows the state as RX (0x10) and there are no other errors reported anywhere.
2026-05-18 7:10 AM
Hello Tobias3,
This issue is known. An errata sheet entry is planned. A frequency offset can occur in the receiver when it enters the RX state. This issue can also occur at the transmitter side when entering the TX state. The frequency offset prevents the radio from receiving packets at the expected frequency.
Using RX_TIMEOUT is an acceptable workaround because it allows the radio to exit RX mode and re-enter. Does this recover communication? I assume that it does.
Best regards,
Filippo
2026-05-18 7:45 AM
Which microcontrollers are affected by this?
2026-05-18 7:50 AM
Hi Tobias3,
the STM32WL3x family.
BR,
Filippo
2026-05-18 7:54 AM
I'm understanding you correctly sending and receiving a packet from any current microcontroller from the STM32WL3x family may randomly fail and there is no workaround other than sending/receiving the packet again?
2026-05-18 8:00 AM
Hi Tobias3,
no, this one you are talking about is one workaround, I would say the easiest one to implement.
Another workaround will be explained in the next Errata Sheet document. This is preventing the frequency offset issue at RX/TX entrance so the random issue will not happen anymore.
BR,
Filippo
2026-05-18 8:04 AM
And would you mind sharing that workaround here? Or is there a set release date for when the workaround will be released? We have a finished product and just discovered this and would really like to avoid a redesign using another microcontroller.