STM32F103C8 diagnostic bootable binary freely available

[techman-001]

Hi All,

Announcing a bootable 52.6kB diagnostic test kit binary for the STM32F103C8 such as used in the "Blue Pill Board". The size is under 64kB so that it can be flashed by OpenOCD to a MCU claiming only 64kB of Flash in the "Flash size register".

The purpose of this kit is to physically test the "hidden" 64kB second Flash block present on many of these chips and determine if it exists and if it is reliable. It does this by flashing all the bits from one to zero and back again.

Download here: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/STM32F103C8-DIAGNOSTICS.bin/download

Usage
--------
1.   Flash the STM32F103C8-DIAGNOSTICS.bin image to your board with OpenOCD or whatever you normally use.
2.   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.
3.   Enter “?” at the prompt to obtain the menu.

Menu
-------
Enter ? for the menu

Code: [Select]

m - Menu; STM32F103R8 Test Kit
i - Device ID
b - Device Reported Flash Size in Bytes
t - TEST second 64kB Flash Memory block: 0x10000 - 0x1FFFF
d - Dump second 64kB Flash Memory block: 0x10000 - 0x1FFFF
e - Dump first  64kB Flash Memory block: 0x00000 - 0x10000
a - Author
l - License
q - Quit
Developed on a STM32F103C8 board (with the "hidden" second 64kB Flash block present) which is identical to a "Blue Pill", so it should work on all such boards.

Note: there are only three Block erasures and two Block flashes when this test is run, so the Flash wear is negligible.

A successful test looks like this:

Code: [Select]

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~
More information here: https://mecrisp-stellaris-folkdoc.sourceforge.io/stm32f103c8-diags.html#stm32f103c8-diagnostics

[fmkit]

 have you found a real 64kb C8 ?  out of 20 chips I tried all were 128kb

[techman-001]

have you found a real 64kb C8 ?  out of 20 chips I tried all were 128kb

Not yet. I only have 10 boards all with 128kB and 20 new 64 pin flatpack chips but with no ZIFF socket I won't be trying them for a while.

The reason I made the test image is because no one is sure whether the extra 64kB is ok or not, i.e. whether there may be a bad bit in there or not.

This test will find a bad bit.

[ebclr]

Did you make this bin in FORTH ?

[fmkit]

Flash size can be read at  0x1FFF F7E0

[rhodges]

I am using minicom on a Raspberry PI. First thing is to change the serial port from /dev/ttyUSB0 to /dev/ttyACM0.

Testing a CPU marked STM32F103C8T6:

Code: [Select]

stm32id
Die xy coords: 107806545
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00485478  | H T x
Lot_num ascii encoded [55:24]: 0x67244344  | g $ C D

Flash Size Register = 65536 Bytes

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~

My first test, though was accidentally a CKS CS32F103C8T6 that an ebay seller sold as the ST part.
EDIT: The part number is actually CKS32F103C8T6.

Code: [Select]

stm32id
Die xy coords: 16917299
Wafer Number: 50
Lot_num ascii encoded  [23:0]: 0x004D3712  | M 7 .
Lot_num ascii encoded [55:24]: 0x004E4B43  | . N K C

Flash Size Register = 65536 Bytes

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
FAILTEST: $10000  Data = $8C
FAILTEST: $10001  Data = $03
... all the way to
FAILTEST: $1CDE5  Data = $BD
FAILTEST: $1CDE6  Data = $00
FAILTEST: $1CDE7  Data = $00
blank check FAILTEST
It looks like the binary I just flashed. Apparently this chip reads the second 64K from the first.

[techman-001]

Did you make this bin in FORTH ?

Yes I did.The binary is a complete Mecrisp-Stellaris Cortex-M3 Forth.

[techman-001]

I am using minicom on a Raspberry PI. First thing is to change the serial port from /dev/ttyUSB0 to /dev/ttyACM0.

Testing a CPU marked STM32F103C8T6:

Code: [Select]

stm32id
Die xy coords: 107806545
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00485478  | H T x
Lot_num ascii encoded [55:24]: 0x67244344  | g $ C D

Flash Size Register = 65536 Bytes

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~

My first test, though was accidentally a CKS CS32F103C8T6 that an ebay seller sold as the ST part.

Code: [Select]

stm32id
Die xy coords: 16917299
Wafer Number: 50
Lot_num ascii encoded  [23:0]: 0x004D3712  | M 7 .
Lot_num ascii encoded [55:24]: 0x004E4B43  | . N K C

Flash Size Register = 65536 Bytes

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
FAILTEST: $10000  Data = $8C
FAILTEST: $10001  Data = $03
... all the way to
FAILTEST: $1CDE5  Data = $BD
FAILTEST: $1CDE6  Data = $00
FAILTEST: $1CDE7  Data = $00
blank check FAILTEST
It looks like the binary I just flashed. Apparently this chip reads the second 64K from the first.

Thanks for the feedback, I wasn't able to verify proper bad chip detection with a bad chip because 'unfortunately' mine are all good ;-)

You're right, the bootable binary finishes at 0xCDE7 and is the same data as you have listed above.

Did you enable the Minicom log then press "d" to generate a dump of the binary data at 0x10000 - 0x1FFFF ?

[rhodges]

Did you enable the Minicom log then press "d" to generate a dump of the binary data at 0x10000 - 0x1FFFF ?

Yes. At the end, I saw the GPL text and some strings from your test code.

[bingo600]

@techman-001
Nice test 

And apparently "One bites the dust".

I was under the impression, that even those CKS had 2 x 64K.

Now to avoid those bluepill's on Ali/*bay

Thnx

/Bingo

[techman-001]

Did you enable the Minicom log then press "d" to generate a dump of the binary data at 0x10000 - 0x1FFFF ?

Yes. At the end, I saw the GPL text and some strings from your test code.

Detective RHodges is on the job!

[techman-001]

@techman-001
Nice test 

And apparently "One bites the dust".

I was under the impression, that even those CKS had 2 x 64K.

Now to avoid those bluepill's on Ali/*bay

Thnx

/Bingo

Thanks 

You're responsible anyway, for giving me the nudge to look into this.

Bluepills are like a box of chocolates .... but then one doesn't get many chocolates for under $2 these days.

[techman-001]

Now with a Xmas Day video 

"Did Santa bring your Blue Pill Board a free 64kB for Xmas ?"

https://youtu.be/xpTvd1Zhe0U

[Doctorandus_P]

I did not spend much time on this, as I'm not interested in binary blobs, but still had a look...

Then I saw it was soe FORTH thing, and that done it, closed the website.
I don't have anything against FORTH, but I am simply not interested in learning yet another language.

[BravoV]

Mr.Porter,

Reporting my BluePill, the one with the printed "RESRT" label for the RESET button. 



From this thread -> Cheap Bluepill, very likely it has fake STM32 right ?


Using your latest STM32F103R8 Test Kit v1.2 24Dec2019 version.


Result from "i" command :

Code: [Select]

stm32id
Die xy coords: 16985357
Wafer Number: 45
Lot_num ascii encoded  [23:0]: 0x004D3812  | M 8 .
Lot_num ascii encoded [55:24]: 0x004E4B43  | . N K C


Result from "b" command :

Code: [Select]

Flash Size Register = 131072 Bytes

Result from "t" command :

Code: [Select]

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~


[techman-001]

Mr.Porter,

Reporting my BluePill, the one with the printed "RESRT" label for the RESET button. 



From this thread -> Cheap Bluepill, very likely it has fake STM32 right ?


Using your latest STM32F103R8 Test Kit v1.2 24Dec2019 version.


Result from "i" command :

Code: [Select]

stm32id
Die xy coords: 16985357
Wafer Number: 45
Lot_num ascii encoded  [23:0]: 0x004D3812  | M 8 .
Lot_num ascii encoded [55:24]: 0x004E4B43  | . N K C


Result from "b" command :

Code: [Select]

Flash Size Register = 131072 Bytes

Result from "t" command :

Code: [Select]

Testing 64kB Flash block: 0x10000 - 0x1FFFF
Erasing
Flash with 1010101010101010 (0xAA)
Testing for 0xAA - OK
Erasing
Flash with 0101010101010101 (0x55)
Testing for 0x55 - OK
Erasing
~~~~~ ALL TESTS PASSED ~~~~~


G'day BravoV,

Thanks for the feedback.

I suspect that your chip may be a Chinese clone, the  "CKS32F103C8T6" because it uses hexadecimal for the LOT numbers, the same as yours and has 131072 bytes of ram. Finally your chip "Die xy coords" are very similar to Chinese clone #1 below.

STM32F103CX don't use hexadecimal for the LOT numbers.

Can you see any part numbers on your chips ? Either way they report 131072 bytes of flash and also test ok, that means they do have 131072 bytes of working flash as reported.


Here are two user submissions for CKS32F103C8T6's
-------------------------------------

Chinese clone #1
CKS32F103C8T6

Die xy coords: 16985099
Wafer Number: 42
Lot_num ascii encoded  [23:0]: 0x004D3512  | M 5 .
Lot_num ascii encoded [55:24]: 0x004E4B31  | . N K 1

Free
FLASH.. TOTAL REPORTED: 131072 USED: 51200 FREE: 79872

----------------------------------

Chinese clone #2
CKS32F103C8T6

Die xy coords: 276745
Wafer Number: 42
Lot_num ascii encoded  [23:0]: 0x004D3512  | M 5 .
Lot_num ascii encoded [55:24]: 0x004E4B31  | . N K 1

FLASH.. TOTAL REPORTED: 131072 USED: 51200 FREE: 79872

Cheers,
Terry

[BravoV]

The interesting comparison when reading the "Lot" number in ASCII form :

Your others CKS string

M5.
.NK1


While mine has

M8.
.NKC


Newer CKS revision maybe ? 

Also remember "F" character at the label position, as its printed at the 1st line, instead of 2nd line.


PS : Btw, regarding my report & photos, feel free to use it as you want, like for your blog. 

[techman-001]

The interesting comparison when reading the "Lot" number in ASCII form :

Your others CKS string

M5.
.NK1


While mine has

M8.
.NKC


Newer CKS revision maybe ? 

Also remember "F" character at the label position, as its printed at the 1st line, instead of 2nd line.


PS : Btw, regarding my report & photos, feel free to use it as you want, like for your blog. 

You can disregard the ASCII output because those dots are HEX numbers and discarded by my program. As they're just lot numbers there is no version information.

Ah yes, the position of the F could well be a clue the chip is fake.

Thanks, I will definitely use your data in my blog as it may help others with Blue Pills.

[BravoV]

Ah yes, the position of the F could well be a clue the chip is fake.

And coincidentally  ... on CKS, they have the same style too which put the "F" at the 1st line.

I've read somewhere, that counterfeiters nowadays also want their product can be identified, as they need it for traceabilities in the supply chain and distribution, as cosmetic/appearance can be made almost perfect now.

I guess the reset button label (RESRT) is also deliberately misspelled. 

[techman-001]

Hi All,

Announcing a bootable 52.6kB diagnostic test kit binary for the STM32F103C8 such as used in the "Blue Pill Board". The size is under 64kB so that it can be flashed by OpenOCD to a MCU claiming only 64kB of Flash in the "Flash size register".

The purpose of this kit is to physically test the "hidden" 64kB second Flash block present on many of these chips and determine if it exists and if it is reliable. It does this by flashing all the bits from one to zero and back again.

Usage
--------
1.   Flash the STM32F103C8-DIAGNOSTICS.bin image to your board with OpenOCD or whatever you normally use.
2.   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.
3.   Enter “?” at the prompt to obtain the menu.

Menu
-------
Enter ? for the menu

Code: [Select]

m - Menu; STM32F103R8 Test Kit
i - Device ID
b - Device Reported Flash Size in Bytes
t - TEST second 64kB Flash Memory block: 0x10000 - 0x1FFFF
d - Dump second 64kB Flash Memory block: 0x10000 - 0x1FFFF
e - Dump first  64kB Flash Memory block: 0x00000 - 0x10000
a - Author
l - License
q - Quit

G'day,

So far there have been 78 downloads of this diagnostics program. My thanks to those who provided feedback and data 

I'm about to release V2 which incorporates improvements and bug fixes.

Before I finish this release are there any changes or additions you would like to see to the menu to improve this free diagnostic program ?

Cheers ...

 

[Mecanix]

Great script, looking forward V2.0

[eliocor]

will it be possible to compile a version with PB9 active?
It is needed to enable the USB port on Maple Mini clones: https://stm32-base.org/boards/STM32F103C8T6-Maple-Mini-Clone.html
 
 

[techman-001]

will it be possible to compile a version with PB9 active?
It is needed to enable the USB port on Maple Mini clones: https://stm32-base.org/boards/STM32F103C8T6-Maple-Mini-Clone.html

Absolutely, great idea!

I'll enable USB for the Blue Pill, Olimex-P103 and the Maple-Mini, all at the same time on the new STM32F103C8 Diagnostic V2.
Different Firmware won't be needed.

Thanks 

[GromBeestje]

will it be possible to compile a version with PB9 active?
It is needed to enable the USB port on Maple Mini clones: https://stm32-base.org/boards/STM32F103C8T6-Maple-Mini-Clone.html

Absolutely, great idea!

I'll enable USB for the Blue Pill, Olimex-P103 and the Maple-Mini, all at the same time on the new STM32F103C8 Diagnostic V2.
Different Firmware won't be needed.

Thanks 

Could you also include PC13, as you did on my custom build?

[techman-001]

will it be possible to compile a version with PB9 active?
It is needed to enable the USB port on Maple Mini clones: https://stm32-base.org/boards/STM32F103C8T6-Maple-Mini-Clone.html

Absolutely, great idea!

I'll enable USB for the Blue Pill, Olimex-P103 and the Maple-Mini, all at the same time on the new STM32F103C8 Diagnostic V2.
Different Firmware won't be needed.

Thanks 

Could you also include PC13, as you did on my custom build?

It *would* be my pleasure but ...

Blue pills have their user LED at PC13, any suggestions how we might accommodate this in the one build ?

An option jumper  perhaps ?