Legacy API of task watchdog used the same function esp_task_wdt_feed() to add
and feed a task. This caused issues of implicitly adding a task to the wdt list
if the function was used in shared code.
The new API introduces init, adding, feeding, deleting, deinit functions. Tasks
must now be explicitly added to the task watchdog using their handles. Deletion
must also be explicit using task handles. This resolves the issue of implicit
task additions to the task watchdog due to shared code calling
esp_task_wdt_feed().
Task watchdog is now fully configurable at runtime by calling the init and
deinit functions.
Also added functions to get the handles of idle tasks of the other core. This
helps when adding idle tasks to the watchdog at run time.
Configuring the task watchdog using menu config is still available, however
menu config will only result in calling the init and add functions for idle
tasks shortly after the scheduler starts.
Menu config also allows for using legacy behavior, however the legacy behavior
willcall the new API functions but with slight variations to make them legacy
compatible.
Documentation and example have also been updated
gcov_rtio.c headers updated to prevent error of freertos header files being
included in the wrong order.
Resolves issue TW#13265
The two task watchdog timer bugs are as follows...
1) If only a single task existed on the wdt task list, and esp_task_wdt_feed()
was only called once, the watchdog triggers but fails to print task name
2) If a single task already exists on the task wdt list, and another task calls
esp_task_wdt_feed() once, the watchdog fails to trigger
Problem stemmed from the loop responsible for resetting the watchdog timer
having incorrect loop parameters. The loop failed to traverse the full length
of the task wdt list
In release mode, switches in rtc_clk_bbpll_set would be converted to
jump tables. These tables would be placed into .rodata, which caused
rtc_clk_cpu_freq_set to be unusable while cache is disabled. This
manifested itself in crashes when exiting from light sleep:
https://esp32.com/posting.php?mode=reply&f=13&t=3089#pr14590
get IP address after connecting to the softap.
Now the default netif is station in station+softap mode. The UDP pcb of
DHCP server is binded to IP 0.0.0.0. When other device connects to softap, the
DHCP offer will be sent by softap.But because the destination IP of DHCP offer
is broadcast IP and the source IP of it is 0.0.0.0, it will be sent from default
netif, that is station interface. Other device can not receive the DHCP offer
sent from station interface. As a result, other device can not get IP address.
The resolution is that bind UDP pcb to the IP address of softap. So, the source
IP of DHCP offer is that of softap. DHCP offer can be sent from softap interface
by source IP route method.
