Lora-net
lr1mac task aborted by the radioplanner message clarification
Greetings. I'm developing an application using SWL2001 and at the moment I can't figure out one debug message:
lr1mac task aborted by the radioplanner
What exactly does it mean, in what cases is it displayed and how can I fix it?
I assume that it has something to do with timings, namely the time of entering power saving modes. While I was testing with SLEEP mode - I never got this message, but when I changed it to STOP2 (with reinitialization of peripherals) - it sometimes occurs.
Although it has no visible effect on stack operation - all packets reach the server, I would like to know where to look for the cause and how to fix it.
Hi, Would it be possible for you to provide the detailed logs of the failure ? Many thanks, Best regards
I honestly have no idea what exactly should I log. Here is an example:
INFO: Run modem
*************************************
* TX DONE
*************************************
Open RX1 for Hook Id = 2 RX1 LoRa at 234748 ms: freq:868900000, SF8, BW125, sync word = 0x34
Timer will expire in 989 ms
INFO: Modem engine sleep time: 20000 ms
INFO: FSM loop starting
INFO: S: AWAIT WINDOW
INFO: Sleep time was 20000, spent 6 in FSM, reducing to 19994
INFO: Run modem
lr1mac task aborted by the radioplanner
INFO: Modem event callback
Modem event callback
INFO: Event received: TXDONE
INFO: Transmission done
INFO: Modem engine sleep time: 20000 ms
My code generally resembles periodical uplink example like this:
while (1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
SMTC_HAL_TRACE_INFO("Run modem\n");
sleep_time_ms = smtc_modem_run_engine( );
sleepTime = MIN(sleep_time_ms, 20000);
SMTC_HAL_TRACE_INFO("Modem engine sleep time: %d ms \n", sleepTime);
smtc_modem_status_mask_t modem_status;
smtc_modem_get_status(STACK_ID, &modem_status);
if (sleep_time_ms > 5000 && smtc_modem_is_irq_flag_pending() == false && (modem_status & SMTC_MODEM_STATUS_JOINED) != 0) {
HAL_RTC_GetTime(&hrtc, &last_time, RTC_FORMAT_BIN);
HAL_RTC_GetDate(&hrtc, &placeholder_date, RTC_FORMAT_BIN);
/*====================*/
/* some stuff here that takes time*/
/*====================*/
HAL_RTC_GetTime(&hrtc, &curr_time, RTC_FORMAT_BIN);
HAL_RTC_GetDate(&hrtc, &placeholder_date, RTC_FORMAT_BIN);
int32_t delta_ms = rtc_diff_ms(&last_time, &curr_time, 1023);
SMTC_HAL_TRACE_INFO("Sleep time was %d, spent %d in FSM, reducing to %d\n", sleepTime, delta_ms, sleepTime-delta_ms);
sleepTime = delta_ms >= sleepTime ? 0 :sleepTime-delta_ms;
}
__disable_irq();
if( smtc_modem_is_irq_flag_pending( ) == false && sleep_time_ms > 1)
{
HAL_IWDG_Refresh(&hiwdg);
hal_mcu_set_sleep_for_ms(sleepTime-1);
}
__enable_irq();
HAL_IWDG_Refresh(&hiwdg);
}
and sleep function:
void hal_mcu_set_sleep_for_ms(int32_t milliseconds)
{
HAL_StatusTypeDef rtcStatus = HAL_OK;
if (milliseconds <= 0) {
return;
}
uint32_t delay_ms_2_tick = milliseconds * 2 + ((6 * milliseconds) >> 7);
rtcStatus = HAL_RTCEx_DeactivateWakeUpTimer(&hrtc);
if (rtcStatus != HAL_OK) {
return;
}
rtcStatus = HAL_RTCEx_SetWakeUpTimer_IT(&hrtc, delay_ms_2_tick, RTC_WAKEUPCLOCK_RTCCLK_DIV16);
if (rtcStatus != HAL_OK) {
return;
}
HAL_SuspendTick();
HAL_SPI_DeInit(&hspi1);
HAL_ADC_DeInit(&hadc1);
HAL_I2C_DeInit(&hi2c1);
HAL_I2C_DeInit(&hi2c2);
HAL_I2C_DeInit(&hi2c3);
HAL_QSPI_DeInit(&hqspi);
HAL_RNG_DeInit(&hrng);
HAL_UART_DeInit(&huart1);
HAL_UART_DeInit(&huart2);
HAL_UART_DeInit(&huart3);
HAL_CRC_DeInit(&hcrc);
__DSB();
__ISB();
HAL_PWREx_EnterSTOP2Mode(PWR_STOPENTRY_WFI);
SystemClock_Config();
PeriphCommonClock_Config();
MX_ADC1_Init();
MX_I2C1_Init();
MX_I2C2_Init();
MX_I2C3_Init();
MX_QUADSPI_Init();
MX_RNG_Init();
MX_SPI1_Init();
MX_USART1_UART_Init();
MX_USART2_UART_Init();
MX_USART3_UART_Init();
MX_CRC_Init();
HAL_ResumeTick();
hal_mcu_wait_us(10);
rtcStatus = HAL_RTCEx_DeactivateWakeUpTimer(&hrtc);
}
The thing is lr1mac task aborted by the radioplanner appears only sometimes, not always. So i don't even have an idea what task was aborted.
I am experiencing the same issue with one of the LORAWAN applications that uses SWL2001.
Hello, The message "lr1mac task aborted by the radioplanner" appears when the radio planner is instructed to execute a LoRaWAN task, but it's too late to do so. For example, Rx1 or Rx2 windows must be opened at specific scheduled times. If the radio planner is called too late to initiate the task, it will be aborted.
Can you try increasing RP_MARGIN_DELAY if the host MCU takes a long time to wake up from sleep mode ?
Best Regards
It looks like RX2 has been missed in my case. This was probably due to prints taking more time than expected, after I started using UART with DMA - the issue is gone.
But this is counter-intuitive, calling smtc_modem_run_engine( ) after RX1 returned a value clearly greater than 1000ms, even though RX2 should happen 1000ms later.
My code should be safe from timing issues by not calling any heavy processing if smtc_modem_run_engine( ) should be called in less than 5 seconds, but it turns out this is not the most reliable way to know that we are not expected to need to call a modem function and that we can run blocking code safely.
Any recommendations on how to deal with this other than moving the application to RTOS?
I found how to enable debug prints for Radio Planner, however, this doesn't clear things up much for me. Here is part of the log, could you help me understand what is going on here and why I see RP: Abort running #7 for priority #2. The debug UART here runs at 921600 baud/s, so debug prints of even 500 characters shouldn't take more than 500 µs and mess with timings. Increasing RP_MARGIN_DELAY from 10 to 18 doesn't help.
[2025-07-16 14:14:54.838] Number of missed packets = 0,
[2025-07-16 14:14:54.838] class_c_obj START (1)
[2025-07-16 14:14:54.838] RP: Task #7 enqueue with #15 priority
[2025-07-16 14:14:54.838] RP: Arbiter has been called by rp_task_enqueue and priority-task #7, timer hook #2, delay 4, now 1065520, start_time_ms 1065524
[2025-07-16 14:14:54.840] RP: Launch task #7 and start radio state 2, type 0
[2025-07-16 14:14:54.840]
[2025-07-16 14:14:54.841] RP- INFO - Radio task #7 running - Timer task #2 running - Hook ID #7 - TASK_RX_LORA - start time @1065524 - priority #15
[2025-07-16 14:14:54.847] RP: Extended duration of radio task #7 time to 1065529 ms
[2025-07-16 14:14:54.847] RP: Arbiter has been called by rp_callback and priority-task #7, timer hook #2, delay -5, now 1065529, start_time_ms 1065524
[2025-07-16 14:14:54.850] INFO: Modem sleep time: 20000 ms, between calls: 915
[2025-07-16 14:14:56.050] INFO: Run modem
[2025-07-16 14:14:56.050] RP: Extended duration of radio task #7 time to 1066733 ms
[2025-07-16 14:14:56.051] RP: Arbiter has been called by rp_timer_irq and priority-task #2, timer hook #2, delay 6, now 1066733, start_time_ms 1066739
[2025-07-16 14:14:56.052] RP: Abort running #7 for priority #2
[2025-07-16 14:14:56.054] RP: Launch task #2 and start radio state 2, type 2
[2025-07-16 14:14:56.055]
[2025-07-16 14:14:56.055] RP- INFO - Radio task #2 running - Timer task #2 running - Hook ID #2 - TASK_TX_LORA - start time @1066739 - priority #10
[2025-07-16 14:14:56.056] INFO: Modem sleep time: 20000 ms, between calls: 1303
[2025-07-16 14:14:56.100] INFO: Run modem
[2025-07-16 14:14:56.100] RP: INFO - Radio IRQ received for hook #2
[2025-07-16 14:14:56.101] RP: INFO - Aborted hook # 7 callback
[2025-07-16 14:14:56.101] lr1mac_class_c_rp_callback
[2025-07-16 14:14:56.102] --> 10
[2025-07-16 14:14:56.102] class_c_obj START (1)
[2025-07-16 14:14:56.102] RP: Task #7 enqueue with #15 priority
[2025-07-16 14:14:56.103] RP: Arbiter has been called by rp_task_enqueue and priority-task #7, timer hook #2, delay 4, now 1066785, start_time_ms 1066789
[2025-07-16 14:14:56.105] RP: Launch task #7 and start radio state 2, type 0
[2025-07-16 14:14:56.105]
[2025-07-16 14:14:56.106] RP- INFO - Radio task #7 running - Timer task #2 running - Hook ID #7 - TASK_RX_LORA - start time @1066789 - priority #15
[2025-07-16 14:14:56.107] RP: Extended duration of radio task #7 time to 1066790 ms
[2025-07-16 14:14:56.108] RP: Arbiter has been called by rp_callback and priority-task #7, timer hook #2, delay -1, now 1066790, start_time_ms 1066789
[2025-07-16 14:14:56.109]
[2025-07-16 14:14:56.109] *************************************
[2025-07-16 14:14:56.110] * TX DONE
[2025-07-16 14:14:56.110] *************************************
[2025-07-16 14:14:56.111] rx_start_target -> datarate:5, rx_window_symb:16, rx_offset_ms:-5, board_delay_ms:1
[2025-07-16 14:14:56.112] rx_offset_ms:-5, rx_timeout_symb_in_ms:16, rx_window_symb: 16, board_delay_ms:1
[2025-07-16 14:14:56.112] RP: Task #2 enqueue with #2 priority
[2025-07-16 14:14:56.113] RP: Extended duration of radio task #7 time to 1066795 ms
[2025-07-16 14:14:56.114] RP: Arbiter has been called by rp_task_enqueue and priority-task #7, timer hook #2, delay -6, now 1066795, start_time_ms 1066789
[2025-07-16 14:14:56.115]
[2025-07-16 14:14:56.119] Open RX1 for Hook Id = 2 RX1 LoRa at 1067777 ms: freq:869100000, SF7, BW125, sync word = 0x34
[2025-07-16 14:14:56.122] Timer will expire in 984 ms
[2025-07-16 14:14:56.122] INFO: Modem sleep time: 20000 ms, between calls: 50
Hi djObsidian,
An aborted task doesn't necessarily indicate a failure. In your case, it appears that Class C is running on radio planner task #7, while Class A is using task #2.
Since Class C has the lowest priority, it can be preempted by any higher-priority task. So, if Class A needs to send an uplink or open its receive windows, the radio planner will abort the ongoing Class C operation to execute the higher-priority Class A task.
Best
Thanks for the quick response. This is an issue in this case as we are currently testing FUOTA and getting packet loss on the endpoint side. Now we are waiting for the debug kit from your example (Nucleo L476RG+SX1262MB2CAS), so we cannot test FUOTA in your main_periodical_uplink.c example yet.
Nevertheless, our target platform is quite similar: STM32L431RC+sx1262. The HAL implementation is written based on your smtc_hal_l4, the program logic is the same as main_periodical_uplink.c. This code passes main_porting_tests.c with one warning, porting_test_timer_irq is 2 ms longer than expected, which is apparently due to STM32 HAL.
I attach the full log from the end node of the FUOTA update process. We would be grateful if you could help analyze this log and help us understand what is going wrong at the top level.
We are using Chirpstack Version: v4.12.1 as our Network server. There is no packet loss on the gateway side, I monitored the air with SDR, all packets were being broadcast
As previously mentioned, Class A has a higher priority than Class C. When Class A transmits an uplink or opens its Rx1/Rx2 reception windows, Class C reception (RxC) is temporarily disabled, which may result in the loss of FUOTA packets.
This behavior can be observed by monitoring the radio's power consumption and analyzing the RF link's power level using a power level detector.
So we need to disable all uplinks in class A for the duration of the class C session? Or what's good practice here?
Yes, avoiding uplink transmissions in Class A can improve the success rate of FUOTA by reducing the risk of on-air collisions.
The problem was apparently in the IC. I used LLCC68, assuming that it was fully compatible with SX1262 except for the RF front end, but apparently the differences are more severe. Or maybe I got a batch of defective ICs. I tested it on sx1262 mbed shield - no problems. In conclusion, it would be nice to add a note about the message “lr1mac task aborted by the radioplanner” to the documentation, as it is not mentioned anywhere at all, but it appears in the logs even in the examples provided in the repository, which may confuse developers. Otherwise, this issue can be considered resolved.