Hello,
Through cross-validation (comparing the products that have been successfully flashed with the products that have failed to be flashed to the MCU), it is confirmed that the problem phenomenon follows the batch of the MCU, and the influence of the peripheral circuit or programmer is excluded.
Ok, so if you place the MCU into the NXP eval board, it cannot be programmed?
Or you only tested it on your custom boards.
Did you try to erase the failing micro? For example via JTAG programmer / via SW?
Neither of the two reset methods has been tested:
(1) Watchdog reset: The watchdog is configured for 1s, and when it enters the reset, it enters a while (1) loop, stops feeding the dog, and resets after timeout).
(2) Mode reset (MC_ME. MCTL. R = 0x00005AF0; MC_ME. MCTL. R = 0x0000A50F; The phenomenon is still the same
In case of failure what is the content of the of the RGM [FES/DES] registers?
It will tell you the reset reason and the fault root cause.
If you feel the micro is corrupt right away from NXP fab, you can reach out the NXP sales or follow:
https://www.nxp.com/support/sample-and-buy/how-to-buy-from-nxp/returns-and-warranty-information:WTBU...
But personally it seems little bit strange to see so many uC failing as we do the tests on each micro and guarantee 1ppm as far as I know.
Do the swap test with the NXP EVB to test the failing ones.
I also suggest to get in touch with NXP FAE/sales and consult this issue with them directly as the is not much I can do with so little information on FA shared.
Also ask person who review your design to check for possible issues.
Once you place micro into NXP EVB and program it you can exclude the uC from the root cause. I would start with this test.
Best regards,
Peter
