Hello,

During EMC (electromagnetic compatibility) testing of my device based on the ESP32-S3, a very unusual and difficult-to-explain event occurred. I would like to ask for help from the community and Espressif engineers, especially from anyone who might have encountered something similar.

Description of the event

During the EMC test, the device was connected to a PC over USB, with a terminal open (CDC/USB-UART).
Under normal operation, the firmware periodically transmitted simple diagnostic text messages — exactly as programmed.

At some point, during strong electromagnetic interference:
1. The ESP32-S3 unexpectedly reset (not triggered by firmware).
2. After the reset, it stopped sending the normal application data.
3. Instead, it began transmitting NMEA frames over USB — repeatedly and cyclically — including frames that contained what looked like GPS coordinates of the device (its “own position”).
4. This was not a single corrupted packet; it was a continuous NMEA-like data stream, just like a GPS receiver.
5. The strange output did not stop even after the EMC field disturbance ended — it continued until I manually power-cycled the device.
6. After restarting, the device worked normally again. I have not been able to reproduce this behavior since.

Main questions
1. What operating mode of the ESP32-S3 generates NMEA GPS frames?
Does the ESP32-S3 have any system, factory, diagnostic or undocumented mode that:
- generates NMEA-structured messages,
- outputs GPS-like coordinates,
- and sends them automatically over USB?

I cannot find any such mode in the documentation (hardware, ROM, bootloader).

2. Where did the GPS-like location data come from?
- Is it possible that some internal Espressif process or peripheral:
- obtains location data from the PC,
- accesses any hidden/geolocation service,
- stores diagnostic/environment metadata somewhere,
- or outputs random memory content that just happens to resemble NMEA frames?

3. Could the ESP-IDF framework or flashing tools store location data in the chip during compilation/programming?
Is there any mechanism in ESP-IDF or tooling that might:
- embed environmental metadata (such as the PC’s geolocation, OS metadata, timestamps, etc.),
- store this data inside flash or internal structures,
- or cause the bootloader/ROM to emit such data under certain conditions?
This seems unlikely — but I would like to rule it out explicitly.

4. Could a strong EMC disturbance force the chip into a factory/ROM/test mode?
Has anyone observed that under heavy EMI:
- the ESP32 enters undefined or factory test states,
- the ROM loader switches to unexpected behavior,
- or some hidden diagnostic protocol becomes active?

Additional facts

- The firmware contains zero code related to GPS, NMEA, location, or anything similar.
- The hardware contains no GPS module.
- USB operates as a standard CDC-ACM interface; no GPS, no composite devices.
- After a normal reset, everything works perfectly.
- The issue happened once, only during the EMC test.
- I have been unable to trigger it again.

Efuse dump (espefuse v5.1.0)
(Provided because Espressif Support requested it - problem not solved)

espefuse v5.1.0
Connecting....
Detecting chip type... ESP32-S3

=== Run "summary" command ===
EFUSE_NAME (Block) Description = [Meaningful Value] [Readable/Writeable] (Hex Value)
----------------------------------------------------------------------------------------
Calibration fuses:
K_RTC_LDO (BLOCK1) BLOCK1 K_RTC_LDO = -44 R/W (0b1001011)
K_DIG_LDO (BLOCK1) BLOCK1 K_DIG_LDO = 24 R/W (0b0000110)
V_RTC_DBIAS20 (BLOCK1) BLOCK1 voltage of rtc dbias20 = -56 R/W (0x8e)
V_DIG_DBIAS20 (BLOCK1) BLOCK1 voltage of digital dbias20 = 48 R/W (0x0c)
DIG_DBIAS_HVT (BLOCK1) BLOCK1 digital dbias when hvt = -32 R/W (0b11000)
ADC2_CAL_VOL_ATTEN3 (BLOCK1) ADC2 calibration voltage at atten3 = 108 R/W (0b011011)
TEMP_CALIB (BLOCK2) Temperature calibration data = -1.6 R/W (0b100010000)
OCODE (BLOCK2) ADC OCode = 88 R/W (0x58)
ADC1_INIT_CODE_ATTEN0 (BLOCK2) ADC1 init code at atten0 = -52 R/W (0x8d)
ADC1_INIT_CODE_ATTEN1 (BLOCK2) ADC1 init code at atten1 = -40 R/W (0b101010)
ADC1_INIT_CODE_ATTEN2 (BLOCK2) ADC1 init code at atten2 = 104 R/W (0b011010)
ADC1_INIT_CODE_ATTEN3 (BLOCK2) ADC1 init code at atten3 = -16 R/W (0b100100)
ADC2_INIT_CODE_ATTEN0 (BLOCK2) ADC2 init code at atten0 = -180 R/W (0xad)
ADC2_INIT_CODE_ATTEN1 (BLOCK2) ADC2 init code at atten1 = -16 R/W (0b100100)
ADC2_INIT_CODE_ATTEN2 (BLOCK2) ADC2 init code at atten2 = 76 R/W (0b010011)
ADC2_INIT_CODE_ATTEN3 (BLOCK2) ADC2 init code at atten3 = 108 R/W (0b011011)
ADC1_CAL_VOL_ATTEN0 (BLOCK2) ADC1 calibration voltage at atten0 = -8 R/W (0x82)
ADC1_CAL_VOL_ATTEN1 (BLOCK2) ADC1 calibration voltage at atten1 = -28 R/W (0x87)
ADC1_CAL_VOL_ATTEN2 (BLOCK2) ADC1 calibration voltage at atten2 = 464 R/W (0x74)
ADC1_CAL_VOL_ATTEN3 (BLOCK2) ADC1 calibration voltage at atten3 = -68 R/W (0x91)
ADC2_CAL_VOL_ATTEN0 (BLOCK2) ADC2 calibration voltage at atten0 = 372 R/W (0x5d)
ADC2_CAL_VOL_ATTEN1 (BLOCK2) ADC2 calibration voltage at atten1 = 160 R/W (0b0101000)
ADC2_CAL_VOL_ATTEN2 (BLOCK2) ADC2 calibration voltage at atten2 = 192 R/W (0b0110000)

Config fuses:
WR_DIS (BLOCK0) Disable programming of individual eFuses = 0 R/W (0x00000000)
RD_DIS (BLOCK0) Disable reading from BlOCK4-10 = 0 R/W (0b0000000)
DIS_ICACHE (BLOCK0) Set this bit to disable Icache = False R/W (0b0)
DIS_DCACHE (BLOCK0) Set this bit to disable Dcache = False R/W (0b0)
DIS_TWAI (BLOCK0) Set this bit to disable CAN function = False R/W (0b0)
DIS_APP_CPU (BLOCK0) Disable app cpu = False R/W (0b0)
DIS_DIRECT_BOOT (BLOCK0) Disable direct boot mode = False R/W (0b0)
UART_PRINT_CONTROL (BLOCK0) Set the default UART boot message output mode = Enable R/W (0b00)
PIN_POWER_SELECTION (BLOCK0) Set default power supply for GPIO33-GPIO37; set wh = VDD3P3_CPU R/W (0b0)
en SPI flash is initialized
PSRAM_CAP (BLOCK1) PSRAM capacity = 2M R/W (0b10)
PSRAM_TEMP (BLOCK1) PSRAM temperature = 85C R/W (0b10)
PSRAM_VENDOR (BLOCK1) PSRAM vendor = AP_3v3 R/W (0b01)
PSRAM_CAP_3 (BLOCK1) PSRAM capacity bit 3 = False R/W (0b0)
BLOCK_USR_DATA (BLOCK3) User data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_SYS_DATA2 (BLOCK10) System data part 2 (reserved)
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Flash fuses:
FLASH_TPUW (BLOCK0) Configures flash waiting time after power-up; in u = 0 R/W (0x0)
nit of ms. If the value is less than 15; the waiti
ng time is the configurable value. Otherwise; the
waiting time is twice the configurable value
FLASH_ECC_MODE (BLOCK0) Flash ECC mode in ROM = 16to18 byte R/W (0b0)
FLASH_TYPE (BLOCK0) SPI flash type = 4 data lines R/W (0b0)
FLASH_PAGE_SIZE (BLOCK0) Set Flash page size = 0 R/W (0b00)
FLASH_ECC_EN (BLOCK0) Set 1 to enable ECC for flash boot = False R/W (0b0)
FORCE_SEND_RESUME (BLOCK0) Set this bit to force ROM code to send a resume co = False R/W (0b0)
mmand during SPI boot
FLASH_CAP (BLOCK1) Flash capacity = None R/W (0b000)
FLASH_TEMP (BLOCK1) Flash temperature = None R/W (0b00)
FLASH_VENDOR (BLOCK1) Flash vendor = None R/W (0b000)

Identity fuses:
DISABLE_WAFER_VERSION_MAJOR (BLOCK0) Disables check of wafer version major = False R/W (0b0)
DISABLE_BLK_VERSION_MAJOR (BLOCK0) Disables check of blk version major = False R/W (0b0)
WAFER_VERSION_MINOR_LO (BLOCK1) WAFER_VERSION_MINOR least significant bits = 1 R/W (0b001)
PKG_VERSION (BLOCK1) Package version = 0 R/W (0b000)
BLK_VERSION_MINOR (BLOCK1) BLK_VERSION_MINOR = 2 R/W (0b010)
WAFER_VERSION_MINOR_HI (BLOCK1) WAFER_VERSION_MINOR most significant bit = False R/W (0b0)
WAFER_VERSION_MAJOR (BLOCK1) WAFER_VERSION_MAJOR = 0 R/W (0b00)
OPTIONAL_UNIQUE_ID (BLOCK2) Optional unique 128-bit ID
= e6 ad 1e 70 c4 a8 88 7b 7a 71 b8 31 bf 8d 63 d6 R/W
BLK_VERSION_MAJOR (BLOCK2) BLK_VERSION_MAJOR of BLOCK2 = ADC calib V1 R/W (0b01)
WAFER_VERSION_MINOR (BLOCK0) calc WAFER VERSION MINOR = WAFER_VERSION_MINOR_HI = 1 R/W (0x1)
<< 3 + WAFER_VERSION_MINOR_LO (read only)
PSRAM_CAPACITY (BLOCK0) calc as = PSRAM_CAP_3 << 2 + PSRAM_CAP (read only) = 2 R/W (0b010)

Jtag fuses:
SOFT_DIS_JTAG (BLOCK0) Set these bits to disable JTAG in the soft way (od = 0 R/W (0b000)
d number 1 means disable ). JTAG can be enabled in
HMAC module
DIS_PAD_JTAG (BLOCK0) Set this bit to disable JTAG in the hard way. JTAG = False R/W (0b0)
is disabled permanently
STRAP_JTAG_SEL (BLOCK0) Set this bit to enable selection between usb_to_jt = False R/W (0b0)
ag and pad_to_jtag through strapping gpio3 when bo
th reg_dis_usb_jtag and reg_dis_pad_jtag are equal
to 0

Mac fuses:
MAC (BLOCK1) MAC address
= 68:b6:b3:43:6f:bc (OK) R/W
CUSTOM_MAC (BLOCK3) Custom MAC
= 00:00:00:00:00:00 (OK) R/W

Security fuses:
DIS_DOWNLOAD_ICACHE (BLOCK0) Set this bit to disable Icache in download mode (b = False R/W (0b0)
oot_mode[3:0] is 0; 1; 2; 3; 6; 7)
DIS_DOWNLOAD_DCACHE (BLOCK0) Set this bit to disable Dcache in download mode ( = False R/W (0b0)
boot_mode[3:0] is 0; 1; 2; 3; 6; 7)
DIS_FORCE_DOWNLOAD (BLOCK0) Set this bit to disable the function that forces c = False R/W (0b0)
hip into download mode
DIS_DOWNLOAD_MANUAL_ENCRYPT (BLOCK0) Set this bit to disable flash encryption when in d = False R/W (0b0)
ownload boot modes
SPI_BOOT_CRYPT_CNT (BLOCK0) Enables flash encryption when 1 or 3 bits are set = Disable R/W (0b000)
and disabled otherwise
SECURE_BOOT_KEY_REVOKE0 (BLOCK0) Revoke 1st secure boot key = False R/W (0b0)
SECURE_BOOT_KEY_REVOKE1 (BLOCK0) Revoke 2nd secure boot key = False R/W (0b0)
SECURE_BOOT_KEY_REVOKE2 (BLOCK0) Revoke 3rd secure boot key = False R/W (0b0)
KEY_PURPOSE_0 (BLOCK0) Purpose of Key0 = USER R/W (0x0)
KEY_PURPOSE_1 (BLOCK0) Purpose of Key1 = USER R/W (0x0)
KEY_PURPOSE_2 (BLOCK0) Purpose of Key2 = USER R/W (0x0)
KEY_PURPOSE_3 (BLOCK0) Purpose of Key3 = USER R/W (0x0)
KEY_PURPOSE_4 (BLOCK0) Purpose of Key4 = USER R/W (0x0)
KEY_PURPOSE_5 (BLOCK0) Purpose of Key5 = USER R/W (0x0)
SECURE_BOOT_EN (BLOCK0) Set this bit to enable secure boot = False R/W (0b0)
SECURE_BOOT_AGGRESSIVE_REVOKE (BLOCK0) Set this bit to enable revoking aggressive secure = False R/W (0b0)
boot
DIS_DOWNLOAD_MODE (BLOCK0) Set this bit to disable download mode (boot_mode[3 = False R/W (0b0)
:0] = 0; 1; 2; 3; 6; 7)
ENABLE_SECURITY_DOWNLOAD (BLOCK0) Set this bit to enable secure UART download mode = False R/W (0b0)
SECURE_VERSION (BLOCK0) Secure version (used by ESP-IDF anti-rollback feat = 0 R/W (0x0000)
ure)
BLOCK_KEY0 (BLOCK4)
Purpose: USER
Key0 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_KEY1 (BLOCK5)
Purpose: USER
Key1 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_KEY2 (BLOCK6)
Purpose: USER
Key2 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_KEY3 (BLOCK7)
Purpose: USER
Key3 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_KEY4 (BLOCK8)
Purpose: USER
Key4 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W
BLOCK_KEY5 (BLOCK9)
Purpose: USER
Key5 or user data
= 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 R/W

Spi Pad fuses:
SPI_PAD_CONFIG_CLK (BLOCK1) SPI_PAD_configure CLK = 0 R/W (0b000000)
SPI_PAD_CONFIG_Q (BLOCK1) SPI_PAD_configure Q(D1) = 0 R/W (0b000000)
SPI_PAD_CONFIG_D (BLOCK1) SPI_PAD_configure D(D0) = 0 R/W (0b000000)
SPI_PAD_CONFIG_CS (BLOCK1) SPI_PAD_configure CS = 0 R/W (0b000000)
SPI_PAD_CONFIG_HD (BLOCK1) SPI_PAD_configure HD(D3) = 0 R/W (0b000000)
SPI_PAD_CONFIG_WP (BLOCK1) SPI_PAD_configure WP(D2) = 0 R/W (0b000000)
SPI_PAD_CONFIG_DQS (BLOCK1) SPI_PAD_configure DQS = 0 R/W (0b000000)
SPI_PAD_CONFIG_D4 (BLOCK1) SPI_PAD_configure D4 = 0 R/W (0b000000)
SPI_PAD_CONFIG_D5 (BLOCK1) SPI_PAD_configure D5 = 0 R/W (0b000000)
SPI_PAD_CONFIG_D6 (BLOCK1) SPI_PAD_configure D6 = 0 R/W (0b000000)
SPI_PAD_CONFIG_D7 (BLOCK1) SPI_PAD_configure D7 = 0 R/W (0b000000)

Usb fuses:
DIS_USB_OTG (BLOCK0) Set this bit to disable USB function = False R/W (0b0)
USB_EXCHG_PINS (BLOCK0) Set this bit to exchange USB D+ and D- pins = False R/W (0b0)
USB_EXT_PHY_ENABLE (BLOCK0) Set this bit to enable external PHY = False R/W (0b0)
DIS_USB_JTAG (BLOCK0) Set this bit to disable function of usb switch to = False R/W (0b0)
jtag in module of usb device
DIS_USB_SERIAL_JTAG (BLOCK0) Set this bit to disable usb device = False R/W (0b0)
USB_PHY_SEL (BLOCK0) This bit is used to switch internal PHY and extern
= internal PHY is assigned to USB Device while external PHY is assigned to USB OTG R/W (0b0)
al PHY for USB OTG and USB Device
DIS_USB_SERIAL_JTAG_ROM_PRINT (BLOCK0) USB printing = Enable R/W (0b0)
DIS_USB_SERIAL_JTAG_DOWNLOAD_MODE (BLOCK0) Set this bit to disable UART download mode through = False R/W (0b0)
USB
DIS_USB_OTG_DOWNLOAD_MODE (BLOCK0) Set this bit to disable download through USB-OTG = False R/W (0b0)

Vdd fuses:
VDD_SPI_XPD (BLOCK0) SPI regulator power up signal = True R/W (0b1)
VDD_SPI_TIEH (BLOCK0) If VDD_SPI_FORCE is 1; determines VDD_SPI voltage
= VDD_SPI connects to VDD3P3_RTC_IO R/W (0b1)
VDD_SPI_FORCE (BLOCK0) Set this bit and force to use the configuration of = True R/W (0b1)
eFuse to configure VDD_SPI

Wdt fuses:
WDT_DELAY_SEL (BLOCK0) RTC watchdog timeout threshold; in unit of slow cl = 40000 R/W (0b00)
ock cycle

Flash voltage (VDD_SPI) set to 3.3V by efuse.

I would like to clarify several technical points:
1. Wi-Fi/BLE connectivity
The device does not use Wi-Fi or BLE at all.
In the firmware these features are completely disabled — the network stack is never initialized, and no Wi-Fi/BLE tasks or libraries are started.

2. Flash dump — I cannot provide it
Due to company policy, I cannot publish the full flash image.
However, I performed a detailed hex analysis, searching for:
- sequences like G,G,GP, $GN,
- typical NMEA fragments (GGA, RMC, VTG, etc.),
- comma-separated fields characteristic for NMEA,
- any textual data resembling what the chip was outputting via USB.

There is not even a trace of such data in the flash — no sequences at all.
This indicates that the NMEA-like messages did not originate from any resources stored in flash and were not generated from recorded data.

3. Hardware — key elements
The device is relatively simple and includes:
- TFT LCD,
- RS485 transceiver (present but currently unused and not implemented in firmware),
- battery charger + SoC measurement IC (currently unused in firmware),
- 125 kHz ferrite antenna with a preamplifier, used only for testing proximity LF beacons (range ~20 cm).

This is not a GPS receiver or any type of navigation hardware — it is physically incapable of receiving satellite signals.
The device contains no GSM/4G/5G modem, and no radio modules other than the LF 125 kHz coil.
USB is connected directly to ESP32-S3 and works as a standard CDC interface.

4. What I verified
- On the host PC side, there was no GPS-related software and no services that could send data back to the device.
- The firmware does not generate any frames or structures resembling NMEA.
- Flash contains absolutely no traces of such data.
- After a reset, the device does not reproduce the behavior.

5. Why this is puzzling
The point is not that the ESP32-S3 “received GPS”.
The issue is that — after a strong EMC disturbance — the chip:
- reset itself,
- booted into a state different from the normal boot path,
- began continuously generating lines that looked like valid NMEA frames,
- format was reasonable: $GP…, comma-separated fields, checksum,
- values were consistent and repeated,
- transmission continued even after the EMC field was removed,
- and persisted until power-cycling.

This looks like either entering some unusual ROM/bootloader mode, or incorrect code execution from RAM/ROM after EMC corruption, or something that caused the chip to output text that does not exist anywhere in flash.

(Just to note: the device schematic — like the firmware — also cannot be shared in full.)

The terminal log with the “NMEA-like” messages:

$GPGSV,3,3,10,19,26,270,26,01,085,*79
$GPGGA,070452.0,4945.204196,N,01839.239840,E,1,03,3.2,68.3,M,43.0,M,,*63
$GPVTG,71.1,T,68.6,M,0.0,N,0.0,K,A*2C
$GPRMC,070452.0,A,4945.204196,N,01839.239840,E,0.0,71.1,111025,2.5,E,A*34
$GPSV,3,2,04,09,31,........,3.3,32.0,34
$GPGSV,3,1,10,31,158,24,02,06,156,20,04,80,192,30,09,38,230,31,*76
$GPGSV,3,2,10,21,247,21,28,13,056,22,31,32,061,28,06,34,307,*78
$GPGGA,070453.0,10,19,26,270,26,01,085,*79
$GPGGA,070454.0,4945.204149,N,01839.240077,E,1,03,3.2,68.8,M,43.0,M,,*69
$GPVTG,71.1,T,68.6,M,0.0,N,0.0,K,A*2C
$GPRMC,070454.0,A,4945.204149,N,01839.240077,E,0.0,71.1,111025,2.5,E,A*35
$GPSV,3,2,04,09,31,........,3.3,32.0,34
$GPGSV,3,1,10,31,158,25,20,04,80,192,30,09,38,230,31,*77
$GPGSV,3,2,10,21,247,21,28,13,056,22,31,32,061,27,06,34,307,*77
$GPGGA,070455.0,10,19,26,270,26,01,085,*79
$GPGGA,070456.0,4945.204301,N,01839.240301,E,1,03,3.2,69.2,M,43.0,M,,*6E
$GPVTG,71.1,T,68.6,M,0.0,N,0.0,K,A*2C
$GPRMC,070456.0,A,4945.204301,N,01839.240301,E,0.0,71.1,111025,2.5,E,A*39
$GPSV,3,2,04,09,31,........,3.3,32.0,34
$GPGSV,3,1,10,31,158,24,02,06,156,20,04,80,192,29,09,38,230,32*7C
$GPGSV,3,2,10,17,21,247,23,28,13,056,22,31,32,061,27,06,34,307,*75
$GPGGA,070459.0,10,19,26,270,26,01,085,*79
$GPGGA,070500.0,4945.204516,E,01839.240516,E,1,03,3.2,69.7,M,43.0,M,,*6D
$GPVTG,71.1,T,68.6,M,0.0,N,0.0,K,A*2C
$GPRMC,070500.0,A,4945.204516,N,01839.240516,E,0.0,71.1,111025,2.5,E,A*3F
$GPSVA,2,04,09,31........3.3,32.0,34
$GPGSV,3,1,10,31,158,24,02,06,156,20,04,80,192,30,09,38,230,32*72

What I would like to understand
I am looking for:
- an explanation of whether this “mode” exists at all,
- whether ESP32-S3 or its bootloader/ROM can output NMEA-like data in any circumstances,
- whether Espressif tools could store any location data during build/flash,
- and community experience:
-has anyone seen similar behavior during EMC testing,
-can EMC glitches activate hidden ROM functionality,
-or can memory corruption create patterns resembling valid NMEA frames?

Schematics:






Thank you in advance for any insights or directions.

 

The ESP32-S3 has no documented NMEA output mode. Its bootloader documentation lists only UART and USB boot messages. EMI can corrupt RAM and cause strange repetitive outputs. The NMEA frames likely stem from corrupted code execution. They might also come from a peripheral accidentally driving USB. Host PC or USB driver interference cannot be completely ruled out. Flash inspection found no GPS strings embedded. Build tools or efuse settings did not embed location metadata. Strapping pins or plugin modes don’t produce NMEA output. Strong EMI may force undefined states in the MCU. To diagnose, scope USB D+ and D- and MCU TX pins. Isolate the host PC to verify device-origin of frames. Use a simple firmware and re-test under EMI. Monitor the 3.3 V and VBUS rails for dips or brown-outs. Ensure all unused IOs and UARTs are properly pulled. Enable brown-out detection to force clean resets. Link your scope captures and behavior to Espressif support. Add decoupling, chokes, and EMI mitigation on USB lines. Review this related reference: https://www.theengineeringprojects.com/2023/07/esp32-library-for-proteus.html. This is almost certainly a fault-mode, not intended behavior.

 

Thank you for the detailed analysis and suggestions. I would like to clarify a few important points:

Power and system stability
During the test, all voltages in the device were stable — 3.3 V and VBUS showed no dips or disturbances. No brown-outs were observed.

Test environment and host
The ESP32-S3 was connected only to a single laptop via USB, running a simple CDC terminal. There were no other devices, interfaces, or active radio modules.

Nature of the data
The NMEA frames that appeared after the EMC disturbance contained location exactly corresponding to the place, time of firmware compilation, and flashing on my computer. This suggests that the source of the data was the Windows host’s location, not any GPS receiver.

Firmware and development environment
The device was programmed using VSCode + PlatformIO with the Espressif framework (ESP-IDF). The firmware contains no code or functions capable of generating NMEA or retrieving host location data. Bluetooth/Wi-Fi are completely disabled and unused.

Questions:

• How could the host’s location data have ended up in the ESP32-S3 memory if it is not stored in flash, not received via BT/Wi-Fi, and was not acquired during the test inside the EMC chamber?
• What operating mode did the MCU enter after the EMC disturbance that caused it to send this data over USB — a mode that is not part of my firmware or the documented behavior?

Additional notes
I tried to clarify this issue on the Espressif forum, but they stopped approving my posts — effectively distancing themselves from the topic.
It is also worth noting that this behavior occurred only once and could not be reproduced in subsequent tests.

In summary, the behavior is very unusual. The frames were repeatable and fully compliant with the NMEA standard, while simultaneously indicating the exact location and time of firmware compilation. Any additional insights or interpretations from more experienced users would be highly valuable.

 

Chinese spyware embedded in the RF binary blob received the nuke war signature?

https://docs.zephyrproject.org/latest/boards/espressif/esp32s3_devkitm/doc/index.html

Binary Blobs
Espressif HAL requires RF binary blobs in order work. Run the command below to retrieve those files.

west blobs fetch hal_espressif

 

Interesting

For completeness: I tried to clarify the matter directly with Espressif — but after a few exchanges, they stopped approving my posts on the forum, effectively cutting off the discussion. Officially, they claim to “know nothing” about such a mode.

But that is not the end.
Deployment of the device — specialized mining-industry equipment — had to be halted, as well as further development of the project, because such suspicious, uncontrolled behavior of a third-party module violates the company’s security policy. The issue is serious, urgent, and has real commercial impact.

For this reason, I have posted similar topics on other forums and technical groups worldwide, searching for anyone who has experienced something similar — in order to properly explain this situation.