MCU speed vs Task Manager

[Moldy01]

I was sure that I posted this before, but I'm not seeing it. So, I'll try again.
I've been communicating with Espressif for a couple of months and they've got no idea except that it may be in the code. So, they suggested this Blog as the Arduino Engineers my help better.

I have a device running Arduino on an ESP32, mostly written in C++ , but drawing upon the Arduino libraries greatly. This device Periodically has issues wherein it will NOT communicate with another device using the UART for longer than a few seconds. I found that it is awaiting an ACK that just doesn't seem to come. I know the code works, as for the most part, I get great communications, and everything works per Hoyle.

Unfortunately, every now and again, it goes back to a few seconds then quits (again, awaiting the ACK).

Does ANYONE know of an issue with the UART or the Task Manager which might cause this. We recently changed the compile to lock in MCU clock at 160 MHz rather than the 240 MHz that we had been using. Espressif mentioned that there was an issue with the initialization of the MESH networking if started in the 240 MHz mode. Now that I've done that, suddenly we have problems with the UART communications.

Any thoughts would be helpful. The device is "Potted" since it sits in a motor pit at the end of a swimming pool (runs the pool cover). The other device is a touchscreen keypad which sends the command to open/close the cover.

Thanks,

Mitch

[ESP_Sprite]

Any chance you can post your code, or preferably a whittled down version of the code that does the bare minimum and still shows the issue?

[pipi61]

what kind of ACK is it?
There is no ACK in UART serial data transmission, it is asynchronous data transmission between transmitter and receiver, there is transmission even if the receiver is not connected....

[ESP_Sprite]

what kind of ACK is it?
There is no ACK in UART serial data transmission, it is asynchronous data transmission between transmitter and receiver, there is transmission even if the receiver is not connected....

I read it as an ACK in the protocol overlaid on the UART. As unchecked data streams are usually not that useful for m2m communications, people often put some (usually packetized) protocol layer on top of it.

[pipi61]

Then look for the error in the protocol, not in the esp32 UART hardware

[MicroController]

they've got no idea except that it may be in the code.

And they're probably right.

clock at 160 MHz rather than the 240 MHz ... suddenly we have problems with the UART communications.

Seems to hint at some timing-related issue. This could be due to any kind of race condition which just happens to become (more) noticable at a certain CPU speed, or of course could also be something else.
I would try moving away from searching for a problem in the MCU or the OS and start to verify that the application code is actually correct, maybe beginning with checking for race conditions/improper synchronizations.