Not a genuine ST Device!

[Ukazu]

Hi

I would like to debug STM32F303RDT6 using a combination of Keil and ULINK2.

When I start debugging on the target microcontroller (STM32F303RDT6), **Not a genuine ST Device! Abort connection** is output as shown below.

We investigated the cause.

I found the following files.

**C:\Keil_v5\ARM\PACK\.Web\Keil.STM32F3xx_DFP.pdsc**

It seems that this process is failing.

```xml

        <!-- User-Defined Sequences -->

        <sequence name="CheckID">

          <block>

            __var pidr1 = 0;

            __var pidr2 = 0;

            __var jep106id = 0;

            __var ROMTableBase = 0;

            __ap = 0;      // AHB-AP

            ROMTableBase = ReadAP(0xF8) &amp; ~0x3;

            pidr1 = Read32(ROMTableBase + 0x0FE4);

            pidr2 = Read32(ROMTableBase + 0x0FE8);

            jep106id = ((pidr2 &amp; 0x7) &lt;&lt; 4 ) | ((pidr1 &gt;&gt; 4) &amp; 0xF);

          </block>

          <control if="jep106id != 0x20">

            <block>

              Query(0, "Not a genuine ST Device! Abort connection", 1);

              Message(2, "Not a genuine ST Device! Abort connection.");

            </block>

          </control>

        </sequence>

```

 Below is the keil log.

```

14:13:16:247 (05/03/2024) - START SEQUENCE "DebugDeviceUnlock", "calling sequence" - ID 19

14:13:16:251 (05/03/2024) - READ  AP  Access, AP 0, Addr 0x000000F8, Val 0xE00FF003, "SWD Read AP - Success" - ID 3

14:13:16:257 (05/03/2024) - READ  MEM BLOCK Access, AP 0, Start Addr 0xE00FFFE4, End Addr 0xE00FFFE7, "SWD Read Memory Block (32-bit accesses) - Success" - ID 4

  Item #0, AP 0, Addr 0xE00FFFE4, Value 0x00000040

14:13:16:261 (05/03/2024) - READ  MEM BLOCK Access, AP 0, Start Addr 0xE00FFFE8, End Addr 0xE00FFFEB, "SWD Read Memory Block (32-bit accesses) - Success" - ID 5

  Item #0, AP 0, Addr 0xE00FFFE8, Value 0x0000005C

14:13:57:001 (05/03/2024) - END SEQUENCE "InitTarget", "failed" - ID 20

```

pidr1 is 0x00000040

pidr2 is 0x0000005C

An error occurs because the following processing does not result in 0x20.

```

jep106id = ((pidr2 &amp; 0x7) &lt;&lt; 4 ) | ((pidr1 &gt;&gt; 4) &amp; 0xF);

```

What is the cause of this?

[Ukazu]

Help Me!!

[Tesla DeLorean]

>>What is the cause of this?

Probably counterfeit parts..

Perhaps a large, close, sharp, well focused picture of the top markings of the IC ?

[Ukazu]

Hi

 

@Tesla DeLorean 

Thank you very much.
I'm interested in your answer.

Does that mean I bought a fake?
This is a problem.

 

I would also like to hear opinions from ST microelectronics engineers! !

[Tesla DeLorean]

Ok, but they are not psychic either, so without some markings, or trace codes from the packaging, or knowing how these part(s) were sourced it's going to be hard to know.

You could try also accessing with an ST-LINK and STM32 Cube Programmer

[STOne-32]

Dear @Ukazu ,

 « When I start debugging on the target microcontroller (STM32F303RDT6), **Not a genuine ST Device! Abort connection** »

is that correct the flash programming ( Erase and write , has been done successfully first on this part) and then when starting to debug : you got this message ?  
if possible indeed to have the product Top marking on this LQFP64 package and if possible the UID - unique ID signature so we can  check it from our factory side .

Ciao

STOne-32

[Ukazu]

@STOne-32 

No, it is not possible to erase or write to flash. Therefore, debugging cannot be started.

I tried two combinations: Keil+ULINK2 and Keil+STLINK, but they were unsuccessful.

I purchased this microcontroller from an online shop. A world-famous online shop for device parts.

 

I don't have a target microcontroller at the moment, so I don't know the TOP marking.

We will contact you as soon as we know.

 

Thank you

[STOne-32]

Dear @Ukazu ,

if you can have a picture of the device marking as below :

Thank you 

[STOne-32]

Dear @Ukazu ,

We confirm the part is genuine and we shipped it to our distributor DigiKey . So it might be a connection issue  due to hardware power supply or anything else you need to investigate. If you can Try with our STM32CubeProgrammer and have the log file please .

Cheers,

STOne-32

[Ukazu]

@STOne-32 

 

Thank you for your investigation.
I was relieved that the results were genuine.

I will check again to make sure there are no problems with the circuit or wiring, etc. as advised.