Hello, NXP. We are currently working on a project using the S32K312 MCU.
We are writing to inquire because we encountered a defective unit in the field. During the analysis of the defective unit, we compared the dump files of a normal unit with a good unit and found differences in specific areas between the two.
The photo on the left is a normal DUMP file, and the one on the right is a high-quality DUMP file.
The failure is related to a dark current issue. When accessed via Trace32, we confirmed that the Watchdog was continuously triggering a reset during the controller's sleep process.
The image on the left shows the normal dump file, and the image on the right shows the defective dump file.
Upon checking the .map file, the issue is related to the LIN section (Mcal_LIN). Our project does not use a LIN transceiver, and LIN-related functions have been blocked.
We are considering two possibilities:
1. Data tampering caused by noise during the writing process
2. CodeFlash tampering caused by noise in the field
Is it possible that noise generated in the field due to static electricity or power interruptions could cause the CodeFlash area to be tampered with?A reset by Wdg occurs when entering Sleep mode. Is there a way to identify the cause of this Wdg reset?
Hello @jeongwoo.
This is an S-record, type S3, with a byte count of 0x25.
The record starts at address 0x0046D0E0.
Only 4 bytes differ in the data payload, at address 0x0046D0F8: 0x11 00 02 00 changed to 0x40 78 09 78, and the S-record checksum changes accordingly from 0x89 to 0x63.
What is notable is that bits are flipped in both directions — from 1 to 0 and from 0 to 1.
In NOR flash, bits can only be programmed from 1 to 0; flipping a bit from 0 to 1 requires a sector erase first.
So the 0 to 1 transitions cannot be the result of a simple programming operation.
To change bits from 0 to 1 without an erase, charge would need to be removed from the isolated floating gates, which requires both energy and a discharge path. EMI cannot provide this. ESD of sufficient energy to discharge a floating gate would almost certainly cause broader damage. Regarding SEU, we observe many bit flips across 4 separate bytes.
A more likely explanation is that the defective unit was programmed from day one with a different binary, and the flash content has never changed since initial production programming. In that case the ECC checksums stored in flash would be consistent with the data and no ECC error would be reported when the flash is read. Could you confirm this? If the content was instead corrupted after programming, reading flash at address 0x0046D0F8 should trigger an ECC error — do you see ???? displayed at this location when reading from TRACE32? Additionally, could you read DCMROD4[12]?
Regarding the watchdog reset, which watchdog do you mean? It could be the SWT, an external watchdog, or the POR_WDOG.
An SWT (or external watchdog) reset is triggered when the watchdog is not serviced, typically because execution is stuck in a loop. If this is the case, could you disable the watchdog and attach the debugger to the MCU to capture where execution is halted? If it is a POR_WDOG reset, please read registers DCMROPP1–DCMROPP4, which will provide more detailed information about it.
Regards,
Daniel
Hello, thank you for your reply.
In other words, are you saying that the 4-byte difference is likely not due to field factors? We do not currently have the original parts on hand, so it is difficult to perform the address reading and register verification you mentioned.
1. I would like to inquire if there are any similar cases in the field. If so, was it a case where multiple bytes were changed?
2. If firmware that has been modified due to noise is written during the process, could you tell me specifically what the causes of that writing noise might be?