wdt

[faydinp]

Yes, I had a while loop without calling vTaskDelay or any other freeRTOS function. Then I learnt that freeRTOS threads are different than POSIX threads. (yes I'm new to freeRTOS )

So I first tried to feed the wdt with esp_task_wdt_feed() function. I called it in the beginning of task function, and then called it in while loop. But the result was same.

Then I tried calling vTaskDelay (for 1msec) at the end of loop. But still same.
Lastly I tried calling taskYIELD macro at the end of loop. Still same.

As I said before, if I remove the ble init functions in app_main, the warning disappears. That's why I wonder whether esp_ble_gatts_app_register function causes something.

[ESP_Sprite]

Can you post your task code here?

[faydinp]

Here is the task code:
(I commented out the lines I have tried, and enumarated them.)

Code: Select all

void speedCalInit(void * arg)
{
	ext_int_gpio4_init();
	tg0_timer0_init();
		
	int old_ext_isr_counter = 0;
	
	//esp_task_wdt_feed();  //(1)
   
	//const TickType_t xDelay = 1 / portTICK_PERIOD_MS;   //(2)
   
	while(1)
	{
		if (ext_interrupt_noise_flag == 1)
		{
			if (ext_isr_counter != old_ext_isr_counter)
			{
				printf("EXT ISR COUNT = %d ---- ", ext_isr_counter);
				old_ext_isr_counter = ext_isr_counter;
				printf("time interval = %d ---- speed = %d\n", ext_interrupt_interval, speed);
				
			}
			
			if (timer_1ms_clock > ext_interrupt_time + 85)
			{
					ext_interrupt_noise_flag = 0;
			}
		}
		
		if (timer_1ms_clock > ext_interrupt_time + 2500)
		{
			speed = 0;
			bleData = (totalDistanceKm << 16) | speed;
		}
		
		
      
		//esp_task_wdt_feed(); //(1)
      //vTaskDelay(xDelay); //(2)
      //taskYIELD(); //(3)
	}
}

[ESP_Sprite]

Basically, with everything commented out, your task does spin in a while loop without giving lower tasks the chance to run. With the yield command in place, your task will essentially tell the scheduler to re-evaluate the task priorities and execute the one with the highest priority... which is your task, so it will just schedule that again and it will keep on running like the yield isn't there. The vTaskDelay line is a better solution... if you would wait a bit longer. The default tick time is 100Hz, so the (1/portTICK_PERIOD_MS) equals to 0.1.. rounded down to 0. vTaskDelay with an argument of 0 acts like a yield... bringing us back to the same situation.

That leaves the attempt to feed the watchdog. The watchdog you're trying to feed actually is the *task* watchdog, and it is responsible for watching if certain tasks still are run. By default, it checks just both idle tasks, as you have experienced. By feeding it in your own task, you actually explicitely tell it to also start watching your task. This may be a good thing, but it will not stop the watchdog from watching the idle task, and you cannot feed the watchdog on behalf of the idle task, so in this case it will still lead to a watchdog timeout.

Try re-enabling the vTaskDelay with a delay >10mS and I think you'll find that the WDT won't get triggered anymore.

[jesseb]

I get a similar problem sometimes but the only tasks that miss feeding the watchdog are idle tasks.
Here's the output:

Task watchdog got triggered. The following tasks did not feed the watchdog in time:
Tasks currently running:
CPU 0: IDLE
CPU 1: IDLE
Aborting.
abort() was called at PC 0x400d127b on core 0
Guru Meditation Error: Core 0 panic'ed (abort)

Here's the sdkconfig lines for wdt:
# CONFIG_INT_WDT is not set
CONFIG_TASK_WDT=y
CONFIG_TASK_WDT_PANIC=y
CONFIG_TASK_WDT_TIMEOUT_S=10
# CONFIG_TASK_WDT_CHECK_IDLE_TASK is not set