Arduino-esp32: eTaskGetState() Always returns 1 (ready) even when task is active

[euquiq]

Weird thing:
I declare a task handle:

TaskHandle_t h_gsm_loop;

Then on my loop() I start a task:

xTaskCreate(gsm_taskloop, "gsm_taskloop", 2000, NULL, 0, &h_gsm_loop);

The task itself outputs it's ongoing work over Serial Port, and I can see it is working.

But on the loop() each 500ms I query the task status with:

Serial.println("L" + (String)eTaskGetState(&h_gsm_loop));

And I still get 1 as result (task ready) instead of task running ...

Furthermore, I add the same printout inside the task itself, and from the actual task, running, I also get a 1 (task ready) value in return, instead of 0 (task running).

I think eTaskGetState() is just a dummy function ? Or most probably, I must be doing something lamely wrong.

Regards,

Enrique

EDIT

AS @chegewara points out on a replay below, on IDF,

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/freertos.html?#_CPPv213eTaskGetState12TaskHandle_t

You should pass handle by value not by reference to function.

BUT

If I take the "&" in front of the handle and try:

Serial.println("L" + (String)eTaskGetState(h_gsm_loop));

Then I get this error when reaching that line code:

/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c:1510 (eTaskGetState)- assert failed!
abort() was called at PC 0x4008dcd9 on core 1

Backtrace: 0x40090068:0x3ffb1ee0 0x4009023d:0x3ffb1f00 0x4008dcd9:0x3ffb1f20 0x400d6595:0x3ffb1f40 0x40150d38:0x3ffb1fb0 0x4008c011:0x3ffb1fd0

Rebooting...

Hence this may be an actual bug ...

[chegewara]

One quick question:
when you print to serial from loop(), how do you think which task is active at this very moment? Is it loop taks or is it the other task? If both tasks are running on the same core then the other task cant be in running state when loop is performing print to serial.

[euquiq]

The loop() launches this gsm_taskloop() once per minute, to check gsm modem status.

if ((millis() - mspasadosmin) > millisxmin) {           //TIMER: EACH ONE MINUTE
    Serial.println("L" + (String)eTaskGetState(&h_gsm_loop));
    xTaskCreate(gsm_taskloop, "gsm_taskloop", 2000, NULL, 0, &h_gsm_loop); //Check connection
}

That actual serial print before starting the task should (and does!) show "1" (task ready) since the task has not yet started ...

But then there is another "handmade" timer inside the loop() which runs each 500ms, with the same Serial.print, which also shows 1 as return EVEN if I can SEE the task running because it is outputting the GSM commands it sends into the GSM modem.

And also there is a Serial.print inside the task, which shows 1 as return for eTaskGetState(&h_gsm_loop)

The task itself is somewhat quick (less than 1 minute of life) So it is always one instance of this task running, for part of the ongoing minute.

This task performs a series of checks and issues a series of commands on hardware serial port 2, taking about 30 seconds, and then "kills itself" with vTaskDelete(NULL);

[chegewara]

Just put this line in your gsm_taskloop:
Serial.println("L" + (String)eTaskGetState(&h_gsm_loop));

[euquiq]

@chegewara yes, as I state at my first post, such line IS there, and returns 1 (task READY) instead of 0, task Running ... which is the weird part

[chegewara]

https://docs.espressif.com/projects/esp-idf/en/latest/api-reference/system/freertos.html?#_CPPv213eTaskGetState12TaskHandle_t

You should pass handle by value not by reference to function.
Unless its different in arduino.

[euquiq]

@chegewara Yes I already seen that, for IDF. If I take out the "&" ... the code crashes with this error:

/Users/ficeto/Desktop/ESP32/ESP32/esp-idf-public/components/freertos/tasks.c:1510 (eTaskGetState)- assert failed!
abort() was called at PC 0x4008dcd9 on core 1

Backtrace: 0x40090068:0x3ffb1ee0 0x4009023d:0x3ffb1f00 0x4008dcd9:0x3ffb1f20 0x400d6595:0x3ffb1f40 0x40150d38:0x3ffb1fb0 0x4008c011:0x3ffb1fd0

Rebooting...

... when reaching the eTaskGetState(h_gsm_loop) ... So I would think it is different in Arduino, (or wrongly implemented, and thus, a bug, hence this issue may be a true one)

[me-no-dev]

I think that you should post this in IDF's issue tracker :) better chance to get a proper response/fix for this.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale[bot]]

This stale issue has been automatically closed. Thank you for your contributions.