MaxwellAlan
commented
9 months ago Hi @DarmorGamz
Thanks for reporting this issue, we can reproduce locally.
We will take high priority to fix this.
Open DarmorGamz opened 10 months ago
MaxwellAlan
commented
9 months ago Hi @DarmorGamz
Thanks for reporting this issue, we can reproduce locally.
We will take high priority to fix this.
DarmorGamz
commented
9 months ago Hi @MaxwellAlan I appreciate that. There are a few combinations of functions that cause the issue. Even after the Wifi is started, associated, etc.. The ADC will stop running for unknown reasons. The issue I'm currently debugging is
esp_http_client_perform()Setting my logs to verbose, you can see I'm printing "RAN" if the adc conversion function is called at anypoint between a 1 second interval. If I call esp_http_client_perform() the adc functionality stops. hopefully the below logs of what is being called just before failure helps.
I (13532) METER: RAN
I (13532) METER: I_MS: 618535, 786, Sensor I: 14830
I (13532) METER: V_MS: 208709, 456, 12083
I (13532) METER: W_MS: 2078
I (13532) METER: PF: 107
I (13882) wifi:<ba-add>idx:0 (ifx:0, c2:a5:11:9b:19:da), tid:0, ssn:0, winSize:64
I (13882) wifi:<ba-add>idx:1 (ifx:0, c2:a5:11:9b:19:da), tid:6, ssn:2, winSize:64
D (14382) esp_netif_lwip: esp_netif_internal_dhcpc_cb lwip-netif:0x3fcc16ec
D (14382) esp_netif_lwip: if0x3fcc1678 ip changed=1
D (14382) event: running post IP_EVENT:0 with handler 0x42043798 and context 0x3fcc1988 on loop 0x3fcb51c8
0x42043798: wifi_default_action_sta_got_ip at /COMPONENT_ESP_WIFI_DIR/src/wifi_default.c:127
D (14392) wifi_init_default: Got IP wifi default handler entered
D (14392) esp_netif_handlers: esp_netif action got_ip with netif0x3fcc1678 from event_id=0
I (14402) esp_netif_handlers: sta ip: 192.168.1.38, mask: 255.255.255.0, gw: 192.168.1.1
D (14412) event: running post IP_EVENT:0 with handler 0x42019434 and context 0x3fcc1a88 on loop 0x3fcb51c8
0x42019434: _Callback_WiFiEvents at /COMPONENT_WIFI_DIR/Wifi.c:406
V (14422) esp_adapter: thread sem get: sem=0x3fcae7c4
D (14422) esp_netif_lwip: check: remote, if=0x3fcc1678 fn=0x4203fd30
0x4203fd30: esp_netif_get_dns_info_api at /COMPONENT_ESP_NETIF_DIR/lwip/esp_netif_lwip.c:1948
D (14432) esp_netif_lwip: esp_netif_get_dns_info: esp_netif=0x3fcc1678 type=0
D (14432) HTTP_CLIENT: Begin connect to: http://{REMOVED}.com:80
D (14442) esp_netif_lwip: call api in lwip: ret=0x0, give sem
V (14452) esp_adapter: thread sem get: sem=0x3fcae7c4
V (14452) esp_adapter: thread sem get: sem=0x3fcae7c4
D (14462) event: running post IP_EVENT:0 with handler 0x42010314 and context 0x3fcc3c50 on loop 0x3fcb51c8
0x42010314: mdns_preset_if_handle_system_event at /COMPONENT_ESPRESSIF__MDNS_DIR/mdns.c:4160
D (14472) esp-tls: host:{REMOVED}.com: strlen 12
V (14472) esp_netif_lwip: esp_netif_is_netif_up esp_netif:0x3fcc1678
I (14532) METER: I_MS: 618535, 786, Sensor I: 14830
I (14532) METER: V_MS: 208709, 456, 12083
I (14532) METER: W_MS: 2078Hi @DarmorGamz
Thanks for the info.
We debuged and found that the temperature sensor module(PHY used to calibration) works with ADC modules will cause this issue.
DarmorGamz
commented
9 months ago Hey @MaxwellAlan
I applied the below fix, it seems to correct my original issue where order of Wifi_Start and Adc_Start() mattered. However, esp_http_client_perform() and similar functions still kill the adc.
int16_t phy_get_tsens_value(void)
{
// return temp_sensor_get_raw_value(NULL);
return 25;
}Using include_esp_phy_override(); and calling esp_http_client_perform() when using PS_NONE causes a system panic. The below logs is what happens before the panic
if (esp_wifi_set_ps(WIFI_PS_NONE) != ESP_OK) { ESP_LOGI(DEBUG_TAG, "Wifi PS failed to set. "); }D (14112) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:2 posted to loop 0x3fcb50c8
D (14222) esp_netif_lwip: esp_netif_get_ip_info esp_netif:0x3fcc1578
D (14242) HTTP_CLIENT: on_message_begin
D (14242) HTTP_CLIENT: HEADER=Date:Wed, 24 Jan 2024 16:56:27 GMT
D (14242) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14252) HTTP_CLIENT: HEADER=Content-Type:application/binary
D (14262) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14272) HTTP_CLIENT: HEADER=Content-Length:7
D (14272) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14282) HTTP_CLIENT: HEADER=Connection:close
D (14292) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14302) HTTP_CLIENT: HEADER=Server:Apache
D (14302) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14312) HTTP_CLIENT: HEADER=Vary:User-Agent
D (14312) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14322) HTTP_CLIENT: HEADER=Cache-Control:no-cache
D (14332) event: no handlers have been registered for event ESP_HTTP_CLIENT_EVENT:3 posted to loop 0x3fcb50c8
D (14342) HTTP_CLIENT: http_on_headers_complete, status=200, offset=187, nread=187
D (14352) HTTP_CLIENT: http_on_body zu
ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x2b (SPI_FAST_FLASH_BOOT)No good clues.
Using include_esp_phy_override(); and calling esp_http_client_perform() and not exclusively setting the PS mode doesn't cause a panic, but still causes the ADC to stop.
muexxl
commented
7 months ago WORKAROUND: reduced sample rate ??
I experienced a similar issue: The ADC continous mode stopped filling the DMA buffer when a websocket connection has been opened. When trying to reproduce the bug I found that the ADC keeps on going, when I reduce the adc_continuous_config.sample_freq_hz from 24000 Hz to 6000.
So, as a workaround I need to live with a reduced ADC Sample rate. Maybe this also works for you.
DarmorGamz
commented
7 months ago Hello @muexxl, I'm unsure what ESP-IDF version or chip you're using, however, the issue was solved in a few ways: (my sample rate is still 57K divided by 7 channels)
The IRAM IRQ function needs to be fast enough (minimal execution instructions) to empty the queue before it gets overrun after the WI-FI IRQ runs. The WI-FI will always have more priority.
Increase queue size. This doesn't matter if your IRQ is still too slow to empty it quick enough, but will slow down the failure.
Stop() and Start() ADC wrappers around any WI-FI connection related code. This is not optimal, and I don't use this; but I did prove it works.
What actually solved my issue is realizing how slow the NVS erase and write sequence is. I used the above Stop() and Start() wrappers around any flash erase() write() sequence as it should happen less often and then WI-FI related code. I lose maybe 1 second worth of Mean Square points from the ADC, but it's better than the ADC not working.
Using the above, and writing my own version of the calibration code for speed which doesn't use the calibration handle, I can also convert the digital readings to voltage inline inside the IRQ ADC function now as well. I've increase the bits from 12 to 32, but I only consider 22 bits accurate.
Hope this helps others that end up on this thread. -Darren
muexxl
commented
7 months ago Hey @DarmorGamz,
thanks for your fast response. I am not sure what function you are referring to when mentioning "IRAM IRQ function" .
What function do you refer to ? In case you are referring to the .on_conv_done callback: I am not even using this. I am just regulary checking the DMA buffer via adc_continuous_read(...)
My setup: IDF version: ESP-IDF v5.2.1-dirty Chip: ESP32S3 v0.1
Answers checklist.
IDF version.
v5.1.1
Espressif SoC revision.
ESP32-S3 v0.1
Operating System used.
Linux
How did you build your project?
VS Code IDE
If you are using Windows, please specify command line type.
None
Development Kit.
ESP32-S3 WROOM-1 DevKitC-1 | Custom Board
Power Supply used.
External 5V
What is the expected behavior?
WIFI should have no affect over ADC1, esp_wifi_start() and adc_continuous_start() should have no correlation.
What is the actual behavior?
If esp_wifi_start() is called after adc_continuous_start() the DMA stops being filled, and the adc peripheral thinks it's still running as expected. My application also calls esp_wifi_start() and esp_wifi_stop() frequently, requiring me to stop and start the adc each time.
Below is the Adc_Continuous example mixed with the Wifi example, changing the order of these two lines shown will reproduce the result.
Steps to reproduce.
Debug Logs.
esp_wifi_start() called after adc_continuous_start()