ESP32-S3 started outputting NMEA GPS location frames after EMC disturbance — what mode is this?

[fonsztefyn]

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)

Code: Select all

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.

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?

Thank you in advance for any insights or directions.

[Sprite]

The -S3 does not have any GPS functionality; even if it did, you would certainly notice the antenna it uses in order to receive it (if we had the ability to receive GNSS using the dinky WiFi antenna, we'd have a world first on our hands). ESP-IDF also doesn't do anything with NMEA, you can grep the sources for it if you want. Can you dump the flash of the ESP32-S3? You can use this command to do so, replace PORT with your serial port and 4M with the amount of flash your chip has (if not equal to 4 megabytes):

Code: Select all

esptool -p PORT -b 460800 read-flash 0 4M flash_contents.bin

If you're okay with posting it, we can have a look. If not, perhaps opening it in a hex editor and looking for NMEA strings can give us an indication where it came from.

In general, can you tell us a bit more about your hardware? Can you post a schematic? Does it have other connectivity, e.g. a 4G module? Also about the machine it was connected to; what USB devices does it have, was it a laptop with an internal 4G/5G module perhaps?

[mikemoy]

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”).

Come on man! How could you even consider that it can receive GPS coordinates ?!?!?
The next logical step for you would have been to pop those so called NEMA frames to see what the coordinates were. Had you done that you would have learned quickly that its not at all what you think it was.

[fonsztefyn]

Thank you for your replies and involvement.

I would like to clarify several technical points and respond to the questions asked.

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, $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:

Code: Select all

$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

I can provide selected hardware schematic sections (without revealing the full design).

If you have suggestions on which ROM/bootloader areas to inspect or how to reproduce a similar state, I will gladly try it.

P.S. How can I attach a file/image directly to a post?

[fonsztefyn]

https://www.dropbox.com/scl/fi/yawh3v77 ... u4k7g&dl=0

https://www.dropbox.com/scl/fi/leeupdj6 ... 072e4&dl=0

https://www.dropbox.com/scl/fi/ptkaune5 ... h83uc&dl=0

https://www.dropbox.com/scl/fi/zf2mfhf3 ... g9ws9&dl=0

[Sprite]

Sorry, I don't know what to tell you then. The ESP32 does not have any test routines that can output this in ROM, and if it did, it would not output a date close to today (I assume 11 oct is when you made the measurement) or a location that is somewhere in Poland (you'd likely see the coordinates of one of our offices there). This means the only place it can come from is either some other firmware that was still in flash rom, but if your flash dump doesn't show any fragments of that hypothetical firmware, we can exclude that as well.

If you are indeed located where the coordinates place you and the time and date in the NMEA messages is correct, then the only thing I can conclude is that somehow your PC got connected to an actual GNSS receiver. If you can exclude that as well, sorry, I have no ideas left.

I do note that you haven't answered if the host PC has anything like a 4G/5G cellular data thing connected to it or integrated in it. That could still be something to look into: a lot of those chipsets also include GNSS functionality (even if it ends up not being used in the end product) and output the data from it on a port very similar to the ESP32S3s USB-serial-JTAG port.

[fonsztefyn]

My computer does not have any GNSS, 4G, or 5G modules, so the coordinates definitely were not received from any GPS receiver.
The most likely explanation is that the location data was read from the Windows system itself (for example, from Windows location services or other system metadata) and then somehow transmitted through the Espressif framework during compilation or programming of the device.

In other words, the NMEA values did not come from any external GNSS hardware, but were taken from Windows and indirectly injected by the Espressif tooling.

For now, I can only hope that perhaps another user has encountered a similar situation and will be able to provide additional insight.
Unfortunately, because this is specialist equipment intended for the mining industry, the entire production rollout had to be halted, and all further work on the project has been suspended, as such unexplained and suspicious behavior originating from an external module violates our company’s internal security policies.

The matter is urgent and serious for us. I have also posted similar threads on other forums around the world in hopes of finding any similar case that could help explain this incident.

[JoeSensoric]

Just an additional information:
To get your current position the IDs of a WLAN network and an Internet access are sufficient. A browser can access databases of WLAN access points worldwide, you can check it here:

https://www.w3schools.com/html/html5_geolocation.asp

Just click "Try it yourself" and "Run" and you will see your coordinates (or some nearby). So at least for the PC it's possible to have coordinates without any GNSS device or mobile network connected. I could verify this also on large company areas without any public road nearby.

But this cannot explain the data coming for the ESP32.

[fonsztefyn]

I’m of the same opinion — a computer can determine an approximate location just from nearby Wi-Fi networks and internet access, but in the case of the ESP32, this still doesn’t explain the NMEA frames. The question remains: how did this data end up in the ESP32 if it isn’t present anywhere in the compiled .hex code?

[Craige Hales]

When I used OTA updates, there was a function call to accept the new upload or revert to the old code. EMI testing that triggers a reset might glitch at just the right time to select old code in a different partition. Is there any possibility the previous user of the device might have had different code in it?

It would be really interesting to see the messages at the beginning of the boot!

I also remember it was possible to erase the entire ROM, wiping partitions, which would zero out old code, but takes extra time. Then partitions had to be recreated.