cancel
Showing results for 
Search instead for 
Did you mean: 

Is there a way to identify fake MCU's?

BTrem.1
Senior II

 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?

12 REPLIES 12
BTrem.1
Senior II

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
Senior II

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:

0693W00000Hqz4pQAB.pngThe 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

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