Author Topic: Announcing: Bluepill Diagnostics ... V1.62 (Read 9035 times)

techman-001 · « **on:** April 08, 2021, 01:31:08 pm »

V1.6 is a major change as I’ve found that collecting and analyzing the Device electronic signature is pointless as the same codes are used by genuine and clone mcu’s alike. Thank you to those that emailed me their XML ID dumps.

V1.62 uses three tests to determine if a MCU is a genuine STM32F103C8. It can't tell if a chip is a clone, only that it's NOT a STM32F103C8, which is much the same thing especially if the chip markings claim it is.

Exploit a silicon bug in genuine STM32F1xx chips where the BGMCU_IDCODE cannot be read from within the MCU without a SWD or JTAG interface connected.
Verify the Flash Size Register = 64KB
Verify that the MCU has a hidden second 64KB flash block as most STM32F103C8 chips do

.

Already I have what appears to be an unknown clone found by a user in India, full pics and details in the link below.

Please note: V1.6 it uses a jumper between GPIOA-0 and 3.3V to select a Swdcom terminal instead of the usual USB virtual comport and user menu, so if your board has something on GPIOA-0 it could cause problems at boot.

Please see this URL for more details and the downloadable zipfile with source. https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html

All discussions of clones found by V1.62 welcomed as are bug reports.

rcbuck · « **Reply #1 on:** April 10, 2021, 04:50:34 pm »

Is there any documentation that tells how to use this program and how it connects to the bluepill?

techman-001 · « **Reply #2 on:** April 11, 2021, 01:55:35 am »

Quote from: rcbuck on April 10, 2021, 04:50:34 pm

Is there any documentation that tells how to use this program and how it connects to the bluepill?

How to use Bluepill Diagnostics V1.6
------------------------------------
1. Download https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/bluepill-diagnostics-v1.6.zip
2. Flash the bluepill-diagnostics-v1.6xx inside the above zipfile to your Bluepill/Maple Board with OpenOCD or whatever you normally use. Basically you flash this binary exactly as you would flash any STM32Fxx binary.
3. Plug in a USB cable to the “Blue Pill” board and run a serial terminal program on your PC. This will also power the board.
4. Connect the serial terminal program to the "Mecrisp STM32F10x Forth Serial Port" USB device now created on your PC. Any speed is ok, I use 460800 Baud myself.
5. Press the "m" key on your keyboard to bring up the bluepill-diagnostics user menu.

Algoma · « **Reply #3 on:** April 11, 2021, 03:06:47 am »

If the binary can run the diagnostics, why not simply flash a result pattern on the onboard LED... slow flash=genuine, Rapid flash=fake.

techman-001 · « **Reply #4 on:** April 11, 2021, 05:41:22 am »

If the binary can run the diagnostics, why not simply flash a result pattern on the onboard LED... slow flash=genuine, Rapid flash=fake.

1. It's not that simple, human intervention is still needed in areas such as running the second flash block test. Codes are written to every memory location and these are read after writing to ensure every bit is tested. This should be a operator decision as the flash does have a limited write life.

2. Having a fake doesn't mean the Bluepill is total junk depending on the type of fake or clone. This also should be a operator decision.

3. I need user feedback to continue to improve this program and I won't get that from a blinking led.

4. Fakes can be very hard to spot and the fakers will try to work around the detection methods because they work covertly in the shadows unlike Open Source Software. This is a battle of wills and I'm not making it any easier for the fakers.

5. Arduino uses a serial terminal so everyone with a Bluepill is already familiar with them. This one uses the Bluepill USB so it's also a good test to see if the USB does work, given the history of bad Bluepill USB resistors etc.

techman-001 · « **Reply #5 on:** April 11, 2021, 08:15:45 am »

Announcing another BIG improvement that does detect the type of clone/fake thanks to Andre's work on the F103 JDEC codes at https://www.blaatschaap.be/32f103-comparison-part-3/

V1.631 uses four tests below to determine if a MCU is a genuine STM32F103C8.

1. Exploit a silicon bug in genuine STM32F1xx chips where the BGMCU_IDCODE cannot be read from within the MCU without a SWD or JTAG interface connected.
2. Verify the Flash Size Register = 64KB
3. Verify that the MCU has a hidden second 64KB flash block as most STM32F103C8 chips do.
4. Verify that the MCU Jdec manufacturer id is that of STMicroelectronics.

The web page is the same: https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html and identical to the html readme in the zip file release at https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/bluepill-diagnostics-v1.6.zip which also includes the sourcecode.

Note: Website readme may lag behind the zipfile readme as updates can be slow at times.

rcbuck · « **Reply #6 on:** April 12, 2021, 08:10:13 pm »

techman-001, thanks for instructions. I ran several tests and got these results:

h - test second Half of the 128KB flash declared for this chip: PASSED
d - DBGMCU_IDCODE [@ 0xE0042000] = 0x20036410
a - STM32F103C8 authentication FAILED one or more tests:
----------------------------------------------------
FAIL - Declared flash not 65536
FAIL - DBGMCU_IDCODE is readable with no SWD/Jtag connected
PASS - Second 64KB flash block verified
FAIL - JDEC manufacturer id NOT STMicroelectronics

So I guess I have a fake/clone part. The bluepill works with my application so I guess I can't complain.

techman-001 · « **Reply #7 on:** April 12, 2021, 09:52:31 pm »

Quote from: rcbuck on April 12, 2021, 08:10:13 pm

techman-001, thanks for instructions. I ran several tests and got these results:

h - test second Half of the 128KB flash declared for this chip: PASSED
d - DBGMCU_IDCODE [@ 0xE0042000] = 0x20036410
a - STM32F103C8 authentication FAILED one or more tests:
----------------------------------------------------
FAIL - Declared flash not 65536
FAIL - DBGMCU_IDCODE is readable with no SWD/Jtag connected
PASS - Second 64KB flash block verified
FAIL - JDEC manufacturer id NOT STMicroelectronics

So I guess I have a fake/clone part. The bluepill works with my application so I guess I can't complain.

probably a CKS32F103CBT6 what does the 'j' menu have to report ?

szszoke · « **Reply #8 on:** April 12, 2021, 10:37:41 pm »

Does something like this exist for the Blackpill boards as well?

techman-001 · « **Reply #9 on:** April 13, 2021, 02:50:34 am »

Quote from: szszoke on April 12, 2021, 10:37:41 pm

Does something like this exist for the Blackpill boards as well?

I haven't designed a version of my Diagnostic binary for boards using STM32F4xx and have no such plans at this time.

abyrvalg · « **Reply #10 on:** April 14, 2021, 08:19:46 am »

Quote from: Algoma on April 11, 2021, 03:06:47 am

If the binary can run the diagnostics, why not simply flash a result pattern on the onboard LED... slow flash=genuine, Rapid flash=fake.

Looks like checking the core revision in ROM table (OpenOCD: dap info, J-Link: shown at connect) is enough to detect genuine/fake (r1 - genuine, r2 - fake), no need to run any code at all. More extensive testing is needed only if you want to know which fake is it.

dietert1 · « **Reply #11 on:** August 22, 2022, 10:40:21 am »

Being in Sao Paulo, i got a bluepill for a small project. The MCU is labeled STM32F103C8T6 x.
Tried to use it with the STLINK2 of a Nucleo64 L053 board, but it complains about Cortex-4 target core and can't debug with IAR.
With the STLink utility i can flash a test application and step through it, though. So i flashed the diagnostic tool, it reports:

d DBGMCU_IDCODE [@ 0xE0042000] = 0x20036410 f 131072 flash is declared in the Flash size register at 0x1FFFF7E0 j Jdec Continuation Code: 0x00 Jdec Identity Code: 0x20 JDEC manufacturer id: STMicroelectronicsi a STM32F103C8 authentication FAILED one or more tests: ---------------------------------------------------- FAIL - Declared flash not 65536 FAIL - DBGMCU_IDCODE is readable with no SWD/Jtag connected PASS - Second 64KB flash block verified PASS - JDEC manufacturer id IS STMicroelectronics

Regards, Dieter

Scrts · « **Reply #12 on:** August 22, 2022, 03:14:33 pm »

Quote from: techman-001 on April 08, 2021, 01:31:08 pm

Please see this URL for more details and the downloadable zipfile with source. https://mecrisp-stellaris-folkdoc.sourceforge.io/bluepill-diagnostics-v1.6.html

The table "Device Info" has CKS and APM devices saying SWD='N'. It means that they are do not support any type of debug? Or no SWD, but supports full JTAG? Or not even that, i.e. flash only?

abyrvalg · « **Reply #13 on:** August 22, 2022, 11:19:34 pm »

@dietert1: a compatible CM4 could be a GD32E103. Try reading the GD-specific product id reg at 0x40022100, on GD32E103CBT6 it contains 33 43 42 48 ("3CBH").

dietert1 · « **Reply #14 on:** August 25, 2022, 08:31:39 pm »

The dump at 0x4002 2100 looks like this. Don't know what that means. Probably that bluepill module will become junk and i will recycle one of the nucleo kits instead.

Regards, Dieter

true · « **Reply #15 on:** September 07, 2022, 03:41:28 am »

What changed in the 569 versions between the prior two releases?

AlpineJoe · « **Reply #16 on:** November 03, 2022, 05:41:33 am »

I'm new to the scene and have programmed V1.640 to my STM32BluePill but my Win10 machine won't recognize it as a serial port. Googling 'Win1- Mecrisp USB driver' is not turning up anything. What driver can I use for WIn10 for your diagnostic tool?

Thanks!

bingo600 · « **Reply #17 on:** November 06, 2022, 07:42:43 am »

I'm on Linux , but a guess would be
https://www.st.com/en/development-tools/stsw-stm32102.html

Unless Mecrisp uses a different vid:pid ...

Edit:
That driver page suggests to use the "Windows Built in" for Win10

Vorlon · « **Reply #18 on:** October 18, 2023, 05:53:03 pm »

The same here. USB device Not Recognized.

Any solution?

Thanks.

flash2b · « **Reply #19 on:** August 26, 2024, 07:29:04 am »

Also uploaded bluepill-diagnostics-v1.640.bin to my STM32F103C8T8 (128k) board, but I get USB not recognized by Win10 with an invalid USB VID. I know the USB-C connector works since STM32duino bootloader also uses it and that works great.

Are there any new versions in the pipeline ?

ozcar · « **Reply #20 on:** August 27, 2024, 01:39:04 am »

Quote from: flash2b on August 26, 2024, 07:29:04 am

Also uploaded bluepill-diagnostics-v1.640.bin to my STM32F103C8T8 (128k) board, but I get USB not recognized by Win10 with an invalid USB VID. I know the USB-C connector works since STM32duino bootloader also uses it and that works great.

Are there any new versions in the pipeline ?

What tells you that the VID is invalid?

If I plug it (I mean a Bluepill programmed with the diagnostics) into a Win 10 system that has had no drivers installed, it shows up in Device Manager under Ports (COM & LPT) as "USB Serial Device (COMxx)". It is using the Windows provided usbser.inf.

The VID is 0483 and PID is 5740, but I don't think the VID matters too much. I tried butchering the VID from 0483 to DEAD in the bin file before programming it, and it still works fine, with it now showing: "USB\VID_DEAD&PID_5740" under Hardware Ids.

I do have another very old machine running Win 10 that was migrated from Win 7 at some time, and which has had all sorts of STM drivers and other stuff installed on it over time. On that system it also works, but there it shows up as "STMicroelectonics Virtual COM Port (COMxx)" and it is using using stmcdc.inf. The butchered version with "wrong" VID works there too, but due to the mismatch with stmcdc.inf it reverted to using usbser.inf.

Maybe for you Windows can't read the device description at all for some reason.

How did you program it?

flash2b · « **Reply #21 on:** August 27, 2024, 06:12:31 am »

I programmed it with a ST Link V2 and the ST Link Utility. The VID could not be read. When I flash the STM32duino bootloader both VID and PID could be read and Win10 installs it correctly. But for the Diagnostics bin-file, it does not.

Announcing: Bluepill Diagnostics ... V1.62

ozcar · « **Reply #22 on:** August 27, 2024, 10:51:42 am »

I used a ST Link V2 (clone), but with STM32CubeProgrammer. I have not used the ST Link Utility for a long time, but found that I still have it installed on the old machine, so I tried using that (GUI version), and the reprogrammed Bluepill still worked OK.

When I did that the ST Link Utility came up offering to program to location 0x08000000 and I left that untouched as that is the correct location. The bin file does not have the location information in it, and if you program it to the wrong location, then you will get trouble.

For a test to see what could happen, I programmed it again, but to wrong location 0x08000008. Now when I plug it in, I get the message like you showed, and in the Device Manager an entry appears for "Unknown USB Device (Device Descriptor Request Failed)"

Are you sure it got programmed to the correct location?

flash2b · « **Reply #23 on:** August 27, 2024, 11:36:24 am »

File loaded and put on the correct address

Flash successful

USB does not enumerate

ozcar · « **Reply #24 on:** August 27, 2024, 11:58:23 am »

That looks the same as I see at the beginning.

However, I hope that size you show there is not all that was programmed. For me the length of the bin file is 0xED20 (and last 4 bytes of the bin file = 0xFFFFFFFF).

flash2b · « **Reply #25 on:** August 27, 2024, 12:12:57 pm »

Adjusted the Size:

Did a verification:

Got the same error.....

ozcar · « **Reply #26 on:** August 27, 2024, 09:38:18 pm »

I'm running out of ideas. I guess you have tried another USB cable, another port on the PC and even tried plugging it into another PC if possible.

Quality control for those boards is sometimes non-existent. I have had ones with shorted pins and non-connected pins, and there have been reports of incorrect resistance values. You mentioned USB C so maybe what you have is Weact "Bluepill Plus"? I don't have one of those, but other Weact boards I have seem a bit better quality than F103 Bluepill boards I have. If there is some problem with the board I don't know why the STM32DUINO USB bootloader would be OK - maybe it uses less features/resources/whatever? What about Arduino sketches loaded to the board, especially any that use USB serial, do those all work OK?

If it is only the diagnostic code that fails, maybe you would be better off asking wherever the Mecrisp-Stellaris folk hang out.

flash2b · « **Reply #27 on:** August 28, 2024, 05:54:41 am »

I have tried, all that with the same result unfortunately.

I have also installed the STM32duino bootloader on the same board, which works ok. Both DFU and normal COM work fine and my Win10 machines see the USB device with the corresponding VID/PID for those. Also flashed some sketches into the bluepill and that works fine as well including serial communication towards the USB via COM. So I my conclusion was the physical USBC was ok. I also did check the resistor you mentioned and it has the correct value of 1.5Kohm.

Since the diagnostics bin file was designed to diagnose the internals of many different flavors of boards/STM32s I assumed it would also be tolerant running on different boards from different sources. Also user "Vorlon" reported the same problem before me.

dietert1 · « **Reply #28 on:** August 28, 2024, 06:00:37 am »

Another fake MCU issue? I remember exchanging MCU on two bluepills after i found minor problems with their USB interfaces. The new MCUs were from Digikey and worked as expected.

Regards, Dieter

ozcar · « **Reply #29 on:** August 28, 2024, 07:04:36 pm »

Quote from: flash2b on August 28, 2024, 05:54:41 am

...

Since the diagnostics bin file was designed to diagnose the internals of many different flavors of boards/STM32s I assumed it would also be tolerant running on different boards from different sources. Also user "Vorlon" reported the same problem before me.

In another thread here (https://www.eevblog.com/forum/microcontrollers/dbgmcu_idcode-needed-for-some-stm32f103-clones-can-anyone-help/) somebody mentioned a board with APM32 that was not recognised. That turned out to be due to a bad regulator on the board which meant that it was getting no power from USB (but could still be programmed and run if powered by 3.3V from say ST link). I guess you would have noticed a problem like that though.

You did not say if it is a Weact board. I know they do make a Bluepill board with a USB C connector and there are some other differences from the original Bluepill boards (user button, boot select button instead of jumpers, LED on different pin, and provision for optional flash chip). But maybe there are other "Bluepills" with USB C. You must at least be suspicious about it, or else why are you trying to run the diagnostics?

Vorlon did not say much, so hard to know if they had the same problem (where USB works, but not for BP diagnostics).

flash2b · « **Reply #30 on:** August 28, 2024, 08:38:51 pm »

This is my board, a PC13 variant.

I was hoping to run diagnostics on this board to learn more about it. I read that the tool could determine variants of the STM32 which I was interested in to find out myself.

I see now I need to clean up the back with some IPA....

iMo · « **Reply #31 on:** August 28, 2024, 08:48:29 pm »

Where is the 1k5 resistor on your pcb? Is that the R10 wired to D+ ?

flash2b · « **Reply #32 on:** August 28, 2024, 08:49:38 pm »

That is R10 : 152 = 1.5Kohm

iMo · « **Reply #33 on:** August 28, 2024, 09:04:03 pm »

It is long time back as we messed at stm32duino forum (the old one owned by RogerC) but as I can remember the "MYS" is an indication of a fake.. Doublecheck..
https://www.stm32duino.com/

iMo · « **Reply #34 on:** August 28, 2024, 09:34:30 pm »

I searched and dietert1 wrote "MYS" is a fake as well.

https://www.eevblog.com/forum/microcontrollers/yet-another-question-about-the-stm32-clones/msg4403002/#msg4403002

flash2b · « **Reply #35 on:** August 29, 2024, 07:23:39 am »

Bummer, I see it now the F is on the second line and should be STM32F on the first line.

I have researched the WeAct pills, are they legit? They do not have a BOOT1 jumper......

ozcar · « **Reply #36 on:** August 29, 2024, 07:36:50 pm »

Quote from: flash2b on August 29, 2024, 07:23:39 am

I have researched the WeAct pills, are they legit? They do not have a BOOT1 jumper......

Weact have a reasonably good reputation over on www.stm32duino.com. It was on an earlier version of that site that the name "Bluepill" originated. There have been Bluepills, Redpills and Blackpills, all similar but with some differences in pinouts, buttons and jumpers. The lines can get a bit blurred as colour of PCB alone is probably not a real good thing to go on!

This is the board I was referring to, which Weact call Bluepill Plus:

https://www.aliexpress.com/item/1005006110046576.html

I don't have any of those, but I do have boards (genuine Weact as far as I know) which are very similar but have STM32F411CE on them, and PCBs are black. I have not had any trouble with them, but obviously I would not expect the Bluepill diagnostics to run on them, and I'm not aware of any similar diagnostic for STM32F411.

iMo · « **Reply #37 on:** August 29, 2024, 08:17:11 pm »

Yep, the old stm32duino.com forum started (RogerClark and Co.) early 2015 afaik, then it was moved under STM (perhaps end 2019). Therefore you may find various "cores" and various "bootloaders" versions there. The BluePill and perhaps a dozen of other board names originated there.

It started with Maple board and LibMaple core (plus some newer versions of it). The first company with the Maple (F103) board was company called LeafLabs.com (which finished with the Maple series in 2016) and the stm32duino.com took over its LibMaple core, adding a lot of fixes and enhancements to it in the next 4 years (I messed there a lot as well and it was a great fun!!). Also a new HAL based core version started.

At that early times there was none issue with fakes (the far-east vendors did not produce the F1xx clones at that time). Also at that time we discovered the STM32F103 (and higher) has got twice the advertised flash

In the following years the far-east producers managed the F1xx technology and the issues with BluePills started. Then the F3xx clones appeared, not sure F4xx clones are so spread, however.

The new stm32duino.com (since 2019 "owned/hosted" by the STM) moved to the HAL based STM32 core, but you will still find the older cores in the new forum.

flash2b · « **Reply #38 on:** September 15, 2024, 10:37:33 am »

I have order the board that ozcar advised me, with a STM32F103CBT6 (128Kb) chip.

The board and the chip loop Genuine and are happily recognized by the STM32 CubeProgrammer App.

So I need to changes something to the bluepill diagnostics file in order to run it on the new board since this is a PB21 and not a PC13 ?

bson · « **Reply #39 on:** September 30, 2024, 08:44:15 pm »

Quote from: techman-001 on April 08, 2021, 01:31:08 pm

[Exploit a silicon bug in genuine STM32F1xx chips where the BGMCU_IDCODE cannot be read from within the MCU without a SWD or JTAG interface connected.

Oh, I had no idea! This is actually useful. We can make all software, if it can read the IDCODE, stop and wait for a debugger to attach.

Not so useful for the fake parts, I suppose.


EEVblog Main Site	EEVblog on Youtube	EEVblog on Twitter	EEVblog on Facebook	EEVblog on Odysee

Author Topic: Announcing: Bluepill Diagnostics ... V1.62 (Read 9035 times)

Share me