Debug Blue Pill with Stlink-V3minie

[MaurizioAndaloro]

HI!

I recently purchased some ST products, attempting to program and debug.

I initially purchased a STM32 Blue Pill (STM32f103) along with a Mini St-Link V2 (Clone). Then I purchased an STM32F3VE board.

I was able to program both boards using ST-LINKV2 (clone) and CubeProgrammer but not to debug via CubeIde, as I understand ST no longer allows debugging via cloned STlink.

Wanting to debug I purchased a STLINK-V3minie, but I can't even connect with the CubeProgrammer Software to both cards. I have checked the connections over and over again and they are correct.

I changed the firmware version of the Minie, believe me I've tried them all. I checked with the oscilloscope whether the CLOCK/Data are present, and everything is OK.

What do you think about it? Is it possible that the cards have cloned chips and therefore the minie doesn't connect? If, yes, how can I check from CubeProgrammer whether they are genuine ST or not? Looking at the ICs case/mark they look Genuine.

Thanks in advance

[BarryWhit]

> As you said StLinks check if the Chip is made by ST.

I said nothing of the kind.

It's true that the supply chain for F103 in particular is so polluted, I'd just stay away from that part number entirely.

Both it and F3 are quite old parts, and some newer offerings offer lots of peripherals while still keeping things relatively simple. I like the G4 as a starter MCU. H5/H7 are much too complicated, and even the recent U5 (although great) involved a relative step-up in complexity.

If you're doing development for any kind of commercial project then, please, by all that is good and holy, stick with reputable distributors and original products.

[BarryWhit]

ah,  Baader–Meinhof Effect, you have humbled me once more.

From Black Magic Probe Repo:

STLINK-V3 features 
[...]

The ST firmware checks the Romtable and only allows access to STM32 devices. In some
situations, Romtable access may also fail on STM32 device and so a debugger warm 
plug will fail. Cold plug should work with any STM32 device.

I'm not sure what is meant by "romtable", but my guess would be some kind of vendor ID check, and some clones may fail this. I know that some cloned F103 chips have an ST vendor ID, just one that's for the wrong chip.

But, I think this is confirmation (importantly, sourced confirmation) that the ST-LINK v3 possibly contains some countermeasures which make it incompat with fake chips.

Thanks goes to @Andrew Neil  for pointing out the BMP project in another thread, I wasn't aware of it prior.

[Andrew Neil]

---

@BarryWhit wrote:

my guess would be some kind of vendor ID check, and some clones may fail this. I know that some cloned F103 chips have an ST vendor ID, just one that's for the wrong chip.r.

---

From the  Mecrisp Stellaris  Richi's Lab pages referenced from another thread linked earlier, it does seem that some "clones" try to impersonate a genuine ST device, while others openly admit their own identity.

See: https://www.richis-lab.de/STM32.htm

That was the initial cause of the problem in this thread:

https://community.st.com/t5/stm32-mcus-products/blue-pill-stm32f1-board-gets-programmed-through-arduino-ide-but/td-p/667923

The device was openly admitting  its own (non-ST) identity, and the IDE (Keil) was correctly saying, "This is not the (ST) chip you're looking for"

Edited: corrected source of information

[BarryWhit]

Right, compatible chips are not "fake" chips. The GD32F103C8 is/was a competitor. GigaDevice is a legit company, you can find their (winbond compatible, btw) flash chips inside pricey products from big western brands.

Even for actually fake chips, I mean those that bear an ST logo but have different silicon inside, it's important to know that the chip manufacturer is probably not the guilty party. Sanding off and re-badging the chips and even repackaging old dies can be done economically in china. Meanwhile, Adafruit sells the Black Magic Probe HW board for 75$ (they also pay NYC rent).

[Uwe Bonnes]

If you want to learn more, recent STM32 CPUs have a decription of ROM tables in the reference manual. e.g. 65.4 for STM32U5. The Arm documents will also help in understanding.

If a debugger tries to autodetect the connected CPU and not require the user to tell the type of connected CPU, the debugger must have a way to distinguish the connected CPU. Reading the ROM  table is a good way to distinguish and all STM 32 have a STM32 specific entry.  STlinkV3 reads the Rom table and rejects access to any device with a non-STM ROM table.

[BarryWhit]

---

@Uwe Bonnes wrote:

If you want to learn more, recent STM32 CPUs have a decription of ROM tables in the reference manual.  

---

Thanks, I was not aware. But the F103 and F3xx are some of the oldest STM32 families and I don't think they contain such a ROM table, so an anti-counterfeit checks can't rely on them. Something else must be used, like the IDCODE. That is if the issue OP is having really is due to the STLINK-V3 introducing such measures, even for very old families. I wonder if low-cost logic analyzers contain a decoder for SWD, that could provide some reliable answers.

[Uwe Bonnes]

Every Cortex-M with some debug access has ROM Table(s).  This is what blackmagic decodes for F103:

STM32F103RB:
============
0000480:INFO:dap:DP IDR = 0x1ba01477 (v1 rev1)
0000484:INFO:ap:AP#0 IDR = 0x14770011 (AHB-AP var1 rev1)
0000489:INFO:rom_table:AP#0 ROM table #0 @ 0xe00ff000 (designer=020 part=410)
0000492:INFO:rom_table:[0]<e000e000:SCS-M3 class=14 designer=43b part=000>
0000493:INFO:rom_table:[1]<e0001000:DWT class=14 designer=43b part=002>
0000495:INFO:rom_table:[2]<e0002000:FPB class=14 designer=43b part=003>
0000497:INFO:rom_table:[3]<e0000000:ITM class=14 designer=43b part=001>
0000498:INFO:rom_table:[4]<e0040000:TPIU-M3 class=9 designer=43b part=923 devtype=11 archid=0000 devid=0:0:ca0>
0000500:INFO:cortex_m:CPU core #0 is Cortex-M3 r1p1

AP#0 ROM table #0 is what is looked for. designer 20 is STM32

[BarryWhit]

My mistake, I misread your comment. You were saying that only for recent chips is the contents of the ROM table documented - but that they all have a ROM table. That's just what I found when comparing the (old) STM32F103 and (newer) STM32U5 Reference manuals.

Thank you, I learned something today. :folded_hands: