FreeRTOS Triggers WDT during Joining

Hi, using the Heltech LoRaWAN Lib. and including the LoRaWAN cycle inside an RTOS Task but during the joining process the Watch Dog Timer gets triggered if the joining process was not fast.

The LoRaWAN Cycle is included inside a while(1) loop inside the Task.

Any suggestion to solve this issue?

I’t would be great if the Developer team put an Example that uses RTOS with their Library.

Thank you…

Without seeing what you have coded up, the problem is most likely that while(1) loop.
The join process can take a long time. Spinning delays or while(1) are generally not a good idea especially when multiple tasks are involved.
That tends to starve the other tasks, in this case the task responsible for kicking the watch dog timeout.

Look into the task control API’s specifically taskYield(). That should relinquish control to the other tasks while the join is progressing.
Again depends on how things are coded within the rtos tasks.

1 Like

The while(1) is ok as long as you are yielding to other tasks within the loop and not spinning forever exclusively within that loop until the join succeeds.

1 Like

Thank leroyle for your replay, i start the code again from scratch but I’ve a question about using the Yield Fn. , if I Yield the LoRaWAN Task during the joining state, isn’t that would affect the joining process & may cause it to fail as the CPU now is shifted to another Task?

Now I’m actually facing a different Error

/home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:1446 (xQueueGenericReceive)- assert failed!
abort() was called at PC 0x40086877 on core 1

as I’m trying to synchronize between tasks using the eventGroup my Tasks are as follow:

void Sensor_Task(void *Arg)
false, // Don’t Clear on Exit
true, // Wait for All Bits

  Serial.println("This is Sensr Task..");
  xEventGroupClearBits(EvtGroup, Sensors_Bit);


void LoRaWAN_Task(void *Arg)
while (true)
false, // Don’t Clear on Exit
true, // Wait for All Bits



just as soon as I comment the EventGroup lines from the code, the error goes away!!

the Error happens during the joining process also.

Before I venture further, I will defer to others as I do not have this platform, My RTOS experience is somewhat limited and with another FreeRTOS port.

RE: the taskYield(), that would be called just prior to entering the loop again as in:

while(true) {
   ... attempt join
   .. check did join happen
This was an effort to ensure the WDT kicking task has a chance to run, although the scheduler should have taken care of that depending on the scheduling algorithm, task priority, WDT timeout value.

RE: the assert, what is the assert testing for??
1 Like

BaseType_t xQueueSemaphoreTake( QueueHandle_t xQueue, TickType_t xTicksToWait )

Queue_t * const pxQueue = xQueue;

The Queue pointer was NULL…

/ Check the queue pointer is not NULL. /
** configASSERT( ( pxQueue ) );**

Assuming that the queue was created before this API was called, seems your choice could be the memory where the pointer is stored is getting trashed, or perhaps stack space is exhausted?
Can you tell if this API was ever successful for this task?, for instance the wait is ok for x number of calls before the assert?

Perhaps insert an assert up the call stack, just before where the failing API is called. Then work your way further up the stack.

1 Like

Thank you, i’m not sure exactly what was the issue but as I reduced the section of the Event flag from the whole LoRaWAN cycle to only wait before sending the Uplink the issue was solved. i suspect the sleep Function since it really works in a very mysterious way.

Why not simply feed the dog while in loop? add this in the while loop

#include "soc/rtc_wdt.h"

you can also play with the dog timer:

rtc_wdt_set_length_of_reset_signal(RTC_WDT_SYS_RESET_SIG, RTC_WDT_LENGTH_3_2us);
rtc_wdt_set_time(RTC_WDT_STAGE0, 250);

last but not least disable the dog before you start the join process and re-enable it after words.

#include "soc/rtc_wdt.h"




1 Like