几天后如何调试ESP32 UDP服务器崩溃

发布于 2025-02-10 01:48:03 字数 642 浏览 3 评论 0原文

我正在使用正在执行以下操作的ESP32：

通过I2C与Ina3221电源监视传感器进行通信，以测量某些单板计算机
设置UDP服务器的电流和电压，以接受对某些单板计算机的请求，发送测量值以
可视化客户端的测量值通过I2C使用SSD1306显示的每个设备，

所有这些都在单独的线程上完成。线程像这样创建：

xTaskCreate(start_power_measurements, "ina3221_power_measurement", configMINIMAL_STACK_SIZE * 8, NULL, 2, NULL);

对于每个客户端，创建了一个线程。

我的ESP32为6个客户提供了问题

，但在2 1/2天后以某种方式坠毁。不幸的是，我不知道该如何调试。我想阅读日志以查看发生了什么，但是idf.py Monitor重新启动了ESP32，现在日志已经消失了。如果这种情况再次发生，我需要知道如何在不重新启动ESP32的情况下查看日志。他们最近在命令中添加了一个- no-reset选项，但这仅显示连接后记录的日志。我需要一种方法来查看旧日志，因为我不能连接到24/7的串行控制台。

有什么办法吗？

原文

i am using an ESP32 that is doing the following things:

communicate with INA3221 power monitoring sensors via I2C to measure current and voltage of some singleboard computers
setup udp server to accept requests for a certain single board computer, send measurements to client
visualize the current measurements per device using a SSD1306 display via I2C

All these things are done on a separate thread. The threads are created like so:

xTaskCreate(start_power_measurements, "ina3221_power_measurement", configMINIMAL_STACK_SIZE * 8, NULL, 2, NULL);

For each client such a thread is created.

The Issue

My ESP32 served 6 clients but crashed somehow after 2 1/2 days. Unfortunately i don't know how i should debug this. I want to read the logs in order to see what happened but idf.py monitor restarted the ESP32 and now logs are gone. In case this happens again I need to know how I can take a look at the logs without restarting the ESP32. They recently added a --no-reset option to the command and it works but this only shows logs that are logged after connection. I need a way to take a look at the old logs because I can't be connected to the serial console 24/7.

Is there any way?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

梦在夏天 2025-02-17 01:48:03

通过额外的ESP32解决这是一个简单的问题。

将GND和TX从您要监视的ESP32连接到GND，以及第二个ESP32上的几乎所有GPIO PIN。为第二个ESP32编写一个非常简短的程序，该程序配置了在该PIN上接收的UART1，并将收到的任何收到的内容写入Flash。问题发生后，检查第二个ESP32写的内容，您应该拥有所需的信息。

另外，您可以将第二个ESP32 log到TCP连接并运行NetCat作为系统上的服务器，该服务器将保持在线并可以从监视ESP32中访问，将其输出写入文件：

nc -l 8000 > output.txt

或将其登录到Syslog使用Syslog库。您可以根据需要将其复杂化，但是越复杂，其他可能会出现问题的可能性。在监视ESP32上登录以闪烁的闪光灯具有最少的故障模式，并且最有可能为您带来所需的东西。

作为替代方案，您可以使用核心转储来分析故障。有一些无法可靠地产生核心转储的故障模式（尤其是与硬件相关的模式），但是他们可能会发现您的问题并允许您分析它。

配置您的应用程序以生成核心转储，然后分析它需要几个步骤，这些步骤可能会随着ESP-IDF的继续而变化，因此我将链接到官方文档而不是在这里重申。

This is an easy problem to solve with an extra ESP32.

Connect GND and TX from the ESP32 you're monitoring to GND and almost any GPIO pin on the second ESP32. Write a very brief program for the second ESP32 that configures UART1 to receive on that pin and writes whatever it receives to flash. After the problem occurs, inspect what the second ESP32 wrote and you should have the information you need.

Alternatively you could have the second ESP32 log to a TCP connection and run netcat as a server on a system that will remain online and accessible from the monitoring ESP32, writing its output to a file:

nc -l 8000 > output.txt

Or log to syslog using a syslog library. You can complicate this as much as you want but the more complicated the more likely it is something else will go wrong. Logging to flash on the monitoring ESP32 has the fewest failure modes and is most likely to get you what you need.

As an alternative, you may be able to use a core dump to analyze the failure. There are some failure modes (particularly hardware-related ones) which won't reliably generate core dumps, but it's possible that they might catch your problem and allow you to analyze it.

Configuring your application to generate a core dump and then analyzing it requires several steps which may change as ESP-IDF continues to evolve, so I'll link to the official documentation rather than reiterate them here.

回复收藏 0 原文

~没有更多了~