Persistent Logging Strategies for ESP32: Capturing All Logs Efficiently

I have a certain device on ESP32 that resets itself every random number of days (1..10 days). I know the last reset reason from this function:


and it's this enum:

Unfortunately, it doesn't tell me anything specific.
I can't wait that long sitting with a laptop with a serial connected, and hunt for something interesting in the logs....
Hence my question:
- how to log every printf, every Serial.printf(), every macro logging to a file?
I read something about the LittleFS file system, the API seems quite simple, opening a file, adding something and closing it is rather trivial. But this will only take care of my own application. The libraries used in the app may log data differently, anyway I don't want to modify their code. The functions provided in the SDK itself also log something, and I won't be able to save it to a file either...

(I'm leaving aside the aspect of increased non-volatile memory usage, such a temporary cost I can accept)

What to do? How to live?

If the reason for the reboots is overheating problems and resets by the built-in Watchdog, there will never be anything in the logs. Depending on the processor load, you could expose all traffic to the UART interface, and with a separate ESP log the whole thing to the memory card, say every 10 minutes a separate file.

austriackimalarz wrote:

If the reason for the reboots is overheating problems and resets by the built-in Watchdog, there will never be anything in the logs. Depending on the CPU load you can expose all traffic to the UART interface, and with a separate ESP log the whole thing to the memory card, say every 10 minutes a separate file.

+1

The native code of another developer at a reasonable cost (CPU, RAM, number of man-hours of a brainy programmer) cannot be tracked.

Some better JVM, .NET, but this does not occur here.

I don't suspect overheating, as I know the problem was already in January, and this unit is outside the house, so cooling then was super Anyway, the CPU doesn't get tired in there. There is no moisture inside the case either. As the power supply fails, the reason for the last reset is different - but this is understandable. Therefore, I suspect that one of the libraries has messed something up. I really prefer to avoid a hardware solution, I much prefer a software solution, i.e. just permanent logging....

Mocny Amper wrote:

I can't wait so much sitting with the laptop with the serial connected, and hunt for something interesting in the logs...

But that lapek there can go without you, as long as it doesn't go to sleep.

Mocny Amper wrote:

I don't suspect overheating because I know that

Belief in bugs outside your code .... I know it ... after years it passes a bit.

Setting up a program with printfs, traps changes its semantics, it is already ANOTHER PROGRAM. Some Undefined Behaviors can hide, others reveal themselves, other variables are "overridden" by buffer overflows, macros used a second time will give a different effect.

The libraries used do not have to be wrong per-se , but the author assumed a certain way of use, just a slight misunderstanding of "how to call", go outside the "comfort space" etc
C is hugely susceptible to this.
I'm not going to bully the quality of 80% of the libraries from the fingers of electronic engineers, I have an educated opinion (thee Mr. Michael will not say that the hetman asked )

Added after 1 [minute]:

I believe in a critical review for a second pair of eyes, someone experienced who wants to get creative with the pinning (prior analysis of all warnings, some linter, there are linters for such platforms ?)