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.

[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 ...

[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]

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]

Here is my latest update. I'm no longer concerned of a contraband part. That was just a fleeting idea.

I can program the MCU through the SW interface with the ST-LINK but I can't use the bootloader through USART3 on an erased part.. Once programmed I had difficulty getting the MCU to restart after a reset. I changed several unused (unconnected) pins from their default reset condition to 'analog' with a pull-down. Now once programmed through ST-LINK the MCU can be reset and the code will run properly after each reset.

I can also connect to the MCU through USART3 using the bootloader but only if the MCU has already been programmed. If the MCU is erased I cannot connect to the bootloader through USART3. The Programmer attempts to connect and sends the '7F' pattern but there is no response back from the MCU. I then need to program through the SW interface if I want to communicate through the bootloader on USART3.

I'm thinking it must be something about the state of a pin during boot when the chip is erased.

Any ideas?

[BTrem.1]

There are a number of pins used in boot mode that must be dealt with if those modes are not used. The following table lists the pins and their function:

The USB pin, DNP, on PA12 is a DNI pin and in user code is initialized as a analog with a pull-down. However, in boot mode it is evidently being falsely triggered. Adding a pull-up external to the board allowed the MCU to boot properly into the bootloader. In the list above the right hand column lists 9 pins which must have no toggle or be in a high state to work. This is required in boot loader mode and hence independent of how user code initializes the pins. For now, disabling the user signal dsin0 on PB12 during boot loader mode and adding a pullup on PA12 allows the bootloader to work properly.

Brian

[waclawek.jan]

Thanks for sharing this. The "don't touch" pins in bootloader is a tricky issue, and I know of no good detailed analysis of this out there.

Please select your post as "Best" so that the thread be marked as solved.

JW