The core of the problem
I am not claiming that the ESP32 “received GPS data.”
The problem is that after a strong EMC disturbance, the chip entered a state in which it was generating valid, coherent, and continuous NMEA frames that:
are not present in the flash memory,
are not generated by the application firmware,
are not described by any known or documented ROM / bootloader functionality.
In my assessment, the most likely explanation is the existence of an undocumented firmware or system-level component whose purpose may be:
collecting environmental data,
temporarily storing such data,
and potentially sharing it with the manufacturer (e.g., for diagnostic, statistical, or service purposes).
The EMC disturbance most likely caused the ESP32 to transition into this additional, undocumented operating mode, resulting in the transmission of location-related data over USB in NMEA format. Importantly, after the EMC test ended, this data continued to be transmitted in a stable and continuous manner until the power was manually disconnected.
This state could not be reproduced, and Espressif officially claims to have no knowledge of it.
If any users have encountered similar behavior with the ESP32 (or any other SoC)—particularly in the context of EMC testing or electromagnetic interference—I would be very grateful if you could share your experience. This matter is urgent and serious for us, as the deployment of the device (specialized equipment for the mining industry) had to be halted, along with further work on the project.
Additional important information
Due to the lack of a clear and technically credible explanation for this incident, the project has been completely abandoned within the company, and further use of ESP devices (including the ESP32-S3) in this and other projects has been suspended.
Such unexplained and difficult-to-predict behavior—especially involving the autonomous generation and transmission of location-related data—is incompatible with the company’s security policy and cannot be accepted in devices intended for industrial and specialized applications (including mining).
Until a technically sound and complete explanation is provided:
the project remains closed,
the ESP platform has been excluded from further design considerations,
and the issue is being treated as a potential systemic risk.
Thank you to everyone who has taken an interest in this issue and provided suggestions or insights.
ESP32-S3 started outputting NMEA GPS location frames after EMC disturbance — what mode is this?
-
fonsztefyn
- Posts: 6
- Joined: Thu Nov 13, 2025 9:17 pm
-
MicroController
- Posts: 2661
- Joined: Mon Oct 17, 2022 7:38 pm
- Location: Europe, Germany
Re: ESP32-S3 started outputting NMEA GPS location frames after EMC disturbance — what mode is this?
Bummer. Now we'll never know where in the test setup the NMEA data actually got injected into the chain.
Unfortunately that was the premise you started with, which pretty much precluded the search for other more plausible causes.the most likely explanation is the existence of an undocumented firmware or system-level component
-
fonsztefyn
- Posts: 6
- Joined: Thu Nov 13, 2025 9:17 pm
Re: ESP32-S3 started outputting NMEA GPS location frames after EMC disturbance — what mode is this?
I understand this point of view, however I would like to clarify one important issue. The hypothesis about the existence of an undocumented component was not the starting assumption, but rather a conclusion reached after eliminating all more obvious and “classic” causes.
The flash memory contents were inspected, the presence of any GNSS receiver on the host side was ruled out, and the measurement chain was limited exclusively to a USB connection visible in the system as a COM port. The NMEA data was generated continuously and consistently even after the EMC test had ended, until the power to the device was completely disconnected, which makes it difficult to classify this as a one-time artifact or an accidental data “injection” somewhere in the test chain.
I agree that, in an ideal scenario, one should be able to clearly identify the exact point in the setup where the data entered the signal chain. Unfortunately, the nature of the event — a one-time occurrence that could not be reproduced — made this impossible. This does not change the fact that the observed behavior remains unexplained in light of the available technical documentation.
I am not claiming that this is the only possible explanation, but at this stage it is the only one that does not contradict the observed facts. This is precisely why the case was described publicly — in the hope that someone else has encountered a similar phenomenon or can offer a technically coherent explanation.
The flash memory contents were inspected, the presence of any GNSS receiver on the host side was ruled out, and the measurement chain was limited exclusively to a USB connection visible in the system as a COM port. The NMEA data was generated continuously and consistently even after the EMC test had ended, until the power to the device was completely disconnected, which makes it difficult to classify this as a one-time artifact or an accidental data “injection” somewhere in the test chain.
I agree that, in an ideal scenario, one should be able to clearly identify the exact point in the setup where the data entered the signal chain. Unfortunately, the nature of the event — a one-time occurrence that could not be reproduced — made this impossible. This does not change the fact that the observed behavior remains unexplained in light of the available technical documentation.
I am not claiming that this is the only possible explanation, but at this stage it is the only one that does not contradict the observed facts. This is precisely why the case was described publicly — in the hope that someone else has encountered a similar phenomenon or can offer a technically coherent explanation.
Who is online
Users browsing this forum: No registered users and 5 guests