Is there a way to identify fake MCU's?

[BTrem.1]

 I have a test board that works but the board layout for manufacturing does not boot load. I used ST-LINK to program the application memory and it appeared to run but when I reset the chip it no longer ran. Is there a way to examine bootloader memory to see if the is a bootloader on this device?

[TDK]

> I used ST-LINK to program the application memory and it appeared to run but when I reset the chip it no longer ran.

How is the BOOT0 pin connected?

> Is there a way to examine bootloader memory to see if the is a bootloader on this device?

You can certainly connect with STM32CubeProgrammer and view any memory you wish.

[Tesla DeLorean]

In most STM32 BOOT0 needs to be pulled LOW to start user code from FLASH

[BTrem.1]

The BOOT0 is set high during boot and the NRST is toggled low then. high. A few msec later a 0x7F pattern is sent on the MCU Rx line. Sometime later I see a response back on a good board with 0x79. Then with BOOT0 at GND I can reset the MCU and it boots. On the new board layout I do the same sequence and see the 0x7F being sent but there is no response back on the MCU Tx line.

I'm in the process of going through the steps in this ST video to see if I have an issue during Booting; https://www.youtube.com/watch?v=kTMjjED8ErA

[thundertronics.com]

I've just read AN2606 and "Table 2. Bootloader activation patterns" possibly may explain your problem:

Use ST-Link utility and make screenshots of option bytes configuration and each bank beginning address content, compare them. Try to erase chip and reset all option bytes to their default state and repeat 0x7F experiment for both boards. I haven't used BFB2 bit, but as seen from this table you can't get to embedded bootloader in some cases (flash not empty, different option byte values). Probable cause may be that chips was already programmed before (de-soldered chips, pre-programmed chips).

[BTrem.1]

I will check out the option bytes, but the part I'm using is a STM32G431 which uses pattern 15:

 

[Uwe Bonnes]

I do not expected that clone G432 exist. A fake G431 would only have the G431 label faked, but a different hardware inside. So recheck you setup, as the fault is with great probability on your side!

[BTrem.1]

One more thing off the list. I did use the STM32CubeProgrammer with ST-LINK and read all the Flash Option bytes. The address read is 0x1FFF7800 length 48 bytes. I think this is the correct procedure ...

[BTrem.1]

I may have found the problem but not 100% certain yet. I was able to program through the SW interface using ST-LINK. The code "sort of runs" but my watchdog time is blinking an LED at a very fast rate instead of the normal use 1 sec rate. When I press on the MCU package or bend the board slightly in the area of the MCU the code starts working normally. I can connect through a UART and send commands. My suspicion is the UFQFPN48 package may have an unsoldered exposed pad. I won't know until we can x-ray some parts, or replace them.

Even when quasi working I cannot program through the same UART port using BOOT0 and NRST. STM32CubeProgrammer returns error "cannot connect". I suspect this may be related to the potential soldering problem. I can see the 0x7F being sent to the MCU but there is no response back.

Anyone with experience on this type of problem? I'd be interested to hear.

[BTrem.1]

I did verify the flash option bytes match the ST MFR default values. I did this using ST-LINK & STM32CubeProgrammer to examine memory locations.