30KB Blue-Pill USB Binary testing image.

[techman-001]

G'day,
I've made up a Blue-Pill Image (30KB) that can be used to test if the USB on your board is working. It can also read the MCU internal ‘Device Electronic Signature’ and prints the results in a organized manner according to the STM32F0 tech sheet. The image boots on power up and runs in a 64KB Flash STM32F103.

Commands are entered in a Terminal Emulator on a PC, connected to the USB device on the board ("<Mecrisp STM32F10x Forth Serial Port>")

This uses the Mecrisp-Stellaris USB driver for STM32F103 by Jean-Claude Wippler.

I've tested it on a Shenzhen LC Technology board with a STM32F103C8T6 MCU as I don't have a Blue-Pill.

For more info:  https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb

Image tarball download link: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/mecrisp-stellaris-1882bdaff62f637a7bdd517d14f4c1a4.tar.gz/download

[iMo]

Most STM32F103C8T6 chips in BluePills have got 128kB of flash..
I'll try with mine (it has got 128kB).

BPill N1:

Code: [Select]

  ok.
stm32id
Die xy coords: 107806536
Wafer Number: 113
Lot_num ascii encoded  [23:0]: 0x00564989  | V I .
Lot_num ascii encoded [55:24]: 0x67255444  | g % T D

 ok.
free
FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

 ok.
BPill N2:

Code: [Select]

  ok.
stm32id
Die xy coords: 107741009
Wafer Number: 117
Lot_num ascii encoded  [23:0]: 0x00535783  | S W .
Lot_num ascii encoded [55:24]: 0x81174113  | . . A .

 ok.
free
FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

 ok.
And the STM32F103ZET (144pinner with 512kB flash and 64kB ram):

Code: [Select]

  ok.
stm32id
Die xy coords: 97779505
Wafer Number: 78
Lot_num ascii encoded  [23:0]: 0x00383341  | 8 3 A
Lot_num ascii encoded [55:24]: 0x51137004  | Q . p .

 ok.
free
FLASH.. TOTAL REPORTED: 524288 USED: 51200 FREE: 473088
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

 ok.

@techman: it would be great if it would report the real flash and ram sizes. With most current genuine STM32F103XYZ the real amount of flash is 2x of the declared in DS (and maybe the ram is bigger too).

[GeorgeOfTheJungle]

 

[thm_w]

Thanks for posting this. For anyone else wondering, this worked best in windows: power on device let it enumerate on COM port, then use terminal software to connect (115k or any baud), then send the command stm32id to see if it responds.

Bluepill (marked as STM32F103C8T6):

Code: [Select]

Die xy coords: 108068690
Wafer Number: 114
Lot_num ascii encoded  [23:0]: 0x00525366  | R S f
Lot_num ascii encoded [55:24]: 0x67145016  | g . P .

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

Genuine STM32F103 #1:

Code: [Select]

Die xy coords: 107740976
Wafer Number: 48
Lot_num ascii encoded  [23:0]: 0x00395435  | 9 T 5
Lot_num ascii encoded [55:24]: 0x51211941  | Q ! . A

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132
Genuine STM32F103 #2:

Code: [Select]

Die xy coords: 108199728
Wafer Number: 48
Lot_num ascii encoded  [23:0]: 0x00395435  | 9 T 5
Lot_num ascii encoded [55:24]: 0x51211940  | Q ! . @

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132


I tried it on a GD32F103C8T6 on a custom board and got "Device descriptor request failed". I'm not sure if this is a hardware issue (it has single 8MHz crystal, no LSE), or related to the chip itself.. will have to try on the same hardware with genuine STM32 when I get home and update.

edit: arduino FW works with the GD32 so it must be doing something different to initialize the USB: https://github.com/rogerclarkmelbourne/STM32duino-bootloader/blob/master/binaries/generic_boot20_pc13.bin (they mention a lot of tricks in the documentation).

edit2: the OPs FW works OK on the same board with a genuine STM32, so clearly there are some differences in how the GD32 behaves with respect to USB.

[iMo]

GD32F103 is a flash less chip. There is an SPI (8pin) 64kB flash chip bonded on the top of the arm chip, loading the actual flash image into the GD's sram (64kB+20kB) upon reset. Interesting to see what it will report

[Macbeth]

Ok, my "good" bluepill board I have only had a day to play with, but appears to work flawlessly:




My POS bluepill board that requires reconfiguring GDB, does not work with Windows STM debug at all, and the only USB device implementation that works for some reason I would love to know how/why, Mecrisp-stellaris virtual com port.




As an aside from the bluepill boards - I have to say I haven't used Forth since the mid 80's. It was one of the few Acornsoft tapes I bought for my BBC Micro back then. Unfortunately it took up so much space in RAM that it was very limited for the graphics/games I wanted it to be used for programming. BBC Basic (in the ROM page) included an inline 6502 assembler which was excellent and I resorted to that, but I did kind of like the very low level of Forth and its RPN and stack back then. It was pretty much like 6502 with all the push and pops hidden under the cover.

[techman-001]

Thanks for the feedback.

The Flash size is read from the chip "Flash size register" as per the F103 datasheet and the ram is just a constant from the datasheet ram specs as there is no "ram size register.

30.1.1  Flash size register

Base address: 0x1FFF F7E0

Bits 15:0 F_SIZE: Flash memory size
Indicates the Flash memory size of the device in Kbytes.
Example: 0x0080 = 128 Kbytes.

[techman-001]

Ok, my "good" bluepill board I have only had a day to play with, but appears to work flawlessly:

(Attachment Link)
(Attachment Link)

My POS bluepill board that requires reconfiguring GDB, does not work with Windows STM debug at all, and the only USB device implementation that works for some reason I would love to know how/why, Mecrisp-stellaris virtual com port.

(Attachment Link)
(Attachment Link)

As an aside from the bluepill boards - I have to say I haven't used Forth since the mid 80's. It was one of the few Acornsoft tapes I bought for my BBC Micro back then. Unfortunately it took up so much space in RAM that it was very limited for the graphics/games I wanted it to be used for programming. BBC Basic (in the ROM page) included an inline 6502 assembler which was excellent and I resorted to that, but I did kind of like the very low level of Forth and its RPN and stack back then. It was pretty much like 6502 with all the push and pops hidden under the cover.

The "good" board ID looks  standard but the POS unit ID  'lot number' definitely doesn't.

Coupled with the fact GDB doesn't like it I'm guessing a fake chip especially if the chip label claims to be a STM32F103C8T6 ?

Thanks for testing, Forth is still around today and still doing what it did in the 70's but on modern chips and with modern IDE's.

All the peripheral register real time config listed below can be read (where reading is supported) by adding a "." period after the name.
PWR
RCC
GPIOA
GPIOB
GPIOC
AFIO
EXTI
DMA1
SDIO
RTC
TIM1
I2C1
SPI1
USART1
ADC1
NVIC

I.e.
nvic.
NVIC_ICTR (read-only) $00000001
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1

NVIC_STIR (write-only) $00000000
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

NVIC_ISER0 (read-write) $00000040
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0

NVIC_ISER1 (read-write) $00000100
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0

Any sub register cab be read by itself by adding a period after the name, they don't have to be printed in a large group.
NVIC_ISER1.
NVIC_ISER1 (read-write) $00000100
3|3|2|2|2|2|2|2|2|2|2|2|1|1|1|1|1|1|1|1|1|1|
1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0
 ok.

[techman-001]

As an aside from the bluepill boards - I have to say I haven't used Forth since the mid 80's. It was one of the few Acornsoft tapes I bought for my BBC Micro back then. Unfortunately it took up so much space in RAM that it was very limited for the graphics/games I wanted it to be used for programming. BBC Basic (in the ROM page) included an inline 6502 assembler which was excellent and I resorted to that, but I did kind of like the very low level of Forth and its RPN and stack back then. It was pretty much like 6502 with all the push and pops hidden under the cover.

Now you have a modern Forth running at 72MHz on your bluepills to play around with if you so desire

Mecrisp-Stellaris also has a image for the modern BBC Microbit listed here, it's 20 from the top:-

https://mecrisp-stellaris-folkdoc.sourceforge.io/supported-hardware.html?highlight=supported

[techman-001]

G'day,
I've made up a Blue-Pill Image (30KB) that can be used to test if the USB on your board is working. It can also read the MCU internal ‘Device Electronic Signature’ and prints the results in a organized manner according to the STM32F0 tech sheet. The image boots on power up and runs in a 64KB Flash STM32F103.

Commands are entered in a Terminal Emulator on a PC, connected to the USB device on the board ("<Mecrisp STM32F10x Forth Serial Port>")

This uses the Mecrisp-Stellaris USB driver for STM32F103 by Jean-Claude Wippler.

I've tested it on a Shenzhen LC Technology board with a STM32F103C8T6 MCU as I don't have a Blue-Pill.

For more info:  https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb

Image tarball download link: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/mecrisp-stellaris-1882bdaff62f637a7bdd517d14f4c1a4.tar.gz/download

When submitting your results, please paste the text in your reply rather than pictures because text is a lot easier for me to tabulate the results.


1882bdaff62f637a7bdd517d14f4c1a4.bin User Results

STM32F103C8T6
This is the chip I developed my 1882bdaff62f637a7bdd517d14f4c1a4.bin image on. It’s in a $9 Shenzhen LC Technology board. 64KB Flash.
Die xy coords: 108068691
Wafer Number: 80
Lot_num ascii encoded  [23:0]: 0x00555071  | U P q
Lot_num ascii encoded [55:24]: 0x87011723  | . . . #

STM32F103ZET
144pinner with 512kB flash and 64kB ram
Die xy coords: 97779505
Wafer Number: 78
Lot_num ascii encoded  [23:0]: 0x00383341  | 8 3 A
Lot_num ascii encoded [55:24]: 0x51137004  | Q . p .

FLASH.. TOTAL REPORTED: 524288 USED: 51200 FREE: 473088
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

BPill N1
(it has got 128kB).
Die xy coords: 107806536
Wafer Number: 113
Lot_num ascii encoded  [23:0]: 0x00564989  | V I .
Lot_num ascii encoded [55:24]: 0x67255444  | g % T D

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

BPill N2
(it has got 128kB).
Die xy coords: 107741009
Wafer Number: 117
Lot_num ascii encoded  [23:0]: 0x00535783  | S W .
Lot_num ascii encoded [55:24]: 0x81174113  | . . A .

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

Bluepill
marked as STM32F103C8T6
Die xy coords: 108068690
Wafer Number: 114
Lot_num ascii encoded  [23:0]: 0x00525366  | R S f
Lot_num ascii encoded [55:24]: 0x67145016  | g . P .

FLASH.. TOTAL REPORTED: 65536 USED: 51200 FREE: 14336
RAM.... TOTAL PRESET: 20000 USED: 868 FREE: 19132

GD32F103C8T6
“Device descriptor request failed”

Good Bluepill
Die xy coords: 107806545
Wafer Number: 80
Lot_num ascii encoded  [23:0]: 0x00525680  | R V .
Lot_num ascii encoded [55:24]: 0x87192455  | . . $ U

POS Bluepill
Requires reconfiguring GDB, does not work with Windows STM debug at all.
Die xy coords: 74414100
Wafer Number: 47
Lot_num ascii encoded  [23:0]: 0x00525680  | . . .
Lot_num ascii encoded [55:24]: 0x87192455  | . . .
Note: the total lack of Ascii data is telling.

[thm_w]

Added two genuine STM32 from LCSC, they are off by 1 lot number.

[GromBeestje]

These are some results from some bluepills I've laying around (with the R10 replaced with the proper value)

Bluepill

Code: [Select]

Die xy coords: 107741008
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00485572  | H U r
Lot_num ascii encoded [55:24]: 0x87243926  | . $ 9 &
Bluepill

Code: [Select]

Die xy coords: 108265297
Wafer Number: 72
Lot_num ascii encoded  [23:0]: 0x00515782  | Q W .
Lot_num ascii encoded [55:24]: 0x87061344  | . . . D
Bluepill

Code: [Select]

Die xy coords: 108068681
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00545682  | T V .
Lot_num ascii encoded [55:24]: 0x87055015  | . . P .
Bluepill (this one didn't want to program with st-flash as in the supplied script. Programs fine with openocd)

Code: [Select]

Die xy coords: 108134227
Wafer Number: 113
Lot_num ascii encoded  [23:0]: 0x00544872  | T H r
Lot_num ascii encoded [55:24]: 0x67041446  | g . . F
Bluepill

Code: [Select]

Die xy coords: 108003154
Wafer Number: 72
Lot_num ascii encoded  [23:0]: 0x00565388  | V S .
Lot_num ascii encoded [55:24]: 0x87093153  | . . 1 S



This firmware seems to be incompatible with GD32F103C8T6 on my own board. On the same board configuration, I have managed to get it running with an STM32 chip (by manually pulling up the D+ line, as I used a GPIO pin for that)

STM32F103CBT6 on my own board

Code: [Select]

Die xy coords: 108199730
Wafer Number: 52
Lot_num ascii encoded  [23:0]: 0x00353254  | 5 2 T
Lot_num ascii encoded [55:24]: 0x57012556  | W . % V

I have some other *32F103 chips laying around (MM32, BLM32, CS32)
I am waiting for some PCBs to solder them on, then I can test them too,

[techman-001]

These are some results from some bluepills I've laying around (with the R10 replaced with the proper value)

<snip>
This firmware seems to be incompatible with GD32F103C8T6 on my own board. On the same board configuration, I have managed to get it running with an STM32 chip (by manually pulling up the D+ line, as I used a GPIO pin for that)

<snip>
I have some other *32F103 chips laying around (MM32, BLM32, CS32)
I am waiting for some PCBs to solder them on, then I can test them too,

Thank you for the feedback 

No one can read the GD32F103C8T6 so far, so it must have some USB differences to the  STM32F103xxxx  and the CKS32F103C8T6 ?

My up to date chip feedback listing (including your feedback) is at the end of my original doc page:

https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb

[GromBeestje]

No one can read the GD32F103C8T6 so far, so it must have some USB differences to the  STM32F103xxxx  and the CKS32F103C8T6 ?

Or something else that is accessed during initialisation of your code. It seems to hang up to a state where the debugger won't connect unless I press the reset button.


Is it possible to have a build that makes PC13 high, as I use this pin as USB pullup pin in my board design, rather then have it hard-wired. That would make the testing of the chips I've waiting easier. 

I'm also waiting for an APM32F103C8T6 as this one has appeared on lcsc. I'm planning to run some tests on the various 32F103 chips out there.

[thm_w]

Or something else that is accessed during initialisation of your code. It seems to hang up to a state where the debugger won't connect unless I press the reset button.
Is it possible to have a build that makes PC13 high, as I use this pin as USB pullup pin in my board design, rather then have it hard-wired. That would make the testing of the chips I've waiting easier. 

I'm also waiting for an APM32F103C8T6 as this one has appeared on lcsc. I'm planning to run some tests on the various 32F103 chips out there.

Wow I would not have expected yet another competitor. Would like to see those tests.

So GD32F103C8T6 is $1.60 and 64kB of flash, but this thing is $1.30 or less with claimed 128kB flash. Undercutting each other like crazy. I did a quick glance at the datasheet and didn't see anything pop out so I am assuming its another "direct" clone in terms of feature-set. The GD32 might still be faster due to its unique architecture though.

[Macbeth]

When submitting your results, please paste the text in your reply rather than pictures because text is a lot easier for me to tabulate the results.

I agree. I was only playing "follow by example" considering your initial post was in screenshot form.

I will also point out that my "POS Bluepill" with blatantly fake STM32 micro should have its ASCII data corrected because you have recorded it wrong:


Die xy coords: 74414100
Wafer Number: 47
Lot_num ascii encoded  [23:0]: 0x000E0014  | . . .
Lot_num ascii encoded [55:24]: 0x170707E2  | . . . .


The other obvious wrong 'un is the free flash report:

FLASH FREE: 0 vs 14336 for every other STM32 F103C8T6 contender. 

[techman-001]

When submitting your results, please paste the text in your reply rather than pictures because text is a lot easier for me to tabulate the results.

I agree. I was only playing "follow by example" considering your initial post was in screenshot form.

I will also point out that my "POS Bluepill" with blatantly fake STM32 micro should have its ASCII data corrected because you have recorded it wrong:


Die xy coords: 74414100
Wafer Number: 47
Lot_num ascii encoded  [23:0]: 0x000E0014  | . . .
Lot_num ascii encoded [55:24]: 0x170707E2  | . . . .


The other obvious wrong 'un is the free flash report:

FLASH FREE: 0 vs 14336 for every other STM32 F103C8T6 contender. 

Fixed!

I've no idea what's wrong with the Ram free result.

[techman-001]

Is it possible to have a build that makes PC13 high, as I use this pin as USB pullup pin in my board design, rather then have it hard-wired. That would make the testing of the chips I've waiting easier. 

Sure, grab your custom version here 
https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/513f0474ceda9d0979fd5631ee862479.tar.gz/download

Special image for GromBeestje
=============================

* boots in USB 'virtual serial port' mode
* gpioc-13 is high on power-up
* gpioc-13 can be lowered by entering "pc13off" and raised again by "pc13on"
* USB terminal can revert to USART2 by entering "-usb". Speed is 460800 Baud.
=========== ============= =====================
USART2       MCU Signal    3.3v/USB Dongle
=========== ============= =====================
PA1         RTS           CTS   
PA2         TX            RX 
PA3         RX            TX 
=========== ============= =====================
* USART2 terminal can revert to USB by entering "+usb"

This image runs from the USB port on any STM32F103 on power-up.

This uses the Mecrisp-Stellaris USB driver for STM32F103 by Jean-Claude Wippler which is based on the Coreforth USB driver by Eckhart Köppen.

1. Flash 513f0474ceda9d0979fd5631ee862479.bin image to board using your usual method
2. Connect blue pill USB port to PC and look for  "<Mecrisp STM32F10x Forth Serial Port>" device in your system
3. Connect a PC serial terminal to the USB device above, you can choose any Baud Rate. NOTE: There is NO HANDSHAKING,
so a End Of Line Delay of 200ms will required for uploads.
4. You should see "MS RA 2.5.1 tpmod for STM32F103 by Matthias Koch" at board power up

See the 513f0474ceda9d0979f~ee862479.README.txt for further details.

[Macbeth]

Just checked my other 2 boards:

Good Bluepill #2

Code: [Select]

Die xy coords: 108068680
Wafer Number: 113
Lot_num ascii encoded  [23:0]: 0x00565366  | V S f
Lot_num ascii encoded [55:24]: 0x67133045  | g . 0 E

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

Interesting. This boards STM32 F103C8T6 device marking is exactly the same as my other 991KA 93 MYS 903 (week 3 of 2019?) but this one reports 128K vs 64K. STM32 ST-LINK confirms this.

Bad Bluepill #2

Code: [Select]

Die xy coords: 74414100
Wafer Number: 63
Lot_num ascii encoded  [23:0]: 0x000E000C  | . . .
Lot_num ascii encoded [55:24]: 0x170707E2  | . . . .

FLASH.. TOTAL REPORTED: 65536 USED: 65536 FREE: 0


[techman-001]

Just checked my other 2 boards:

Interesting. This boards STM32 F103C8T6 device marking is exactly the same as my other 991KA 93 MYS 903 (week 3 of 2019?) but this one reports 128K vs 64K. STM32 ST-LINK confirms this.

St-link would only do what I do, namely look in the MCU factory flash memory register.

The fact that two similarly  marked MCU's have different Flash  memory would tend to imply that one or another has been reprinted because of scratch damage from a ewaste pull ?

No way that STM QA would allow that kind of error.

[techman-001]

G'day,
I've made up a Blue-Pill Image (30KB) that can be used to test if the USB on your board is working. It can also read the MCU internal ‘Device Electronic Signature’ and prints the results in a organized manner according to the STM32F0 tech sheet. The image boots on power up and runs in a 64KB Flash STM32F103.

Commands are entered in a Terminal Emulator on a PC, connected to the USB device on the board ("<Mecrisp STM32F10x Forth Serial Port>")

This uses the Mecrisp-Stellaris USB driver for STM32F103 by Jean-Claude Wippler.

I've tested it on a Shenzhen LC Technology board with a STM32F103C8T6 MCU as I don't have a Blue-Pill.

For more info:  https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb

Image tarball download link: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/mecrisp-stellaris-1882bdaff62f637a7bdd517d14f4c1a4.tar.gz/download

I've just discovered the driver pulses PA12 (Open-Drain Output) low for 1ms at USB start up. This is to to briefly pull USB-DP down but is board specific.

[techman-001]

G'day,
I've made up a Blue-Pill Image (30KB) that can be used to test if the USB on your board is working. It can also read the MCU internal ‘Device Electronic Signature’ and prints the results in a organized manner according to the STM32F0 tech sheet. The image boots on power up and runs in a 64KB Flash STM32F103.

Commands are entered in a Terminal Emulator on a PC, connected to the USB device on the board ("<Mecrisp STM32F10x Forth Serial Port>")

This uses the Mecrisp-Stellaris USB driver for STM32F103 by Jean-Claude Wippler.

I've tested it on a Shenzhen LC Technology board with a STM32F103C8T6 MCU as I don't have a Blue-Pill.

For more info:  https://mecrisp-stellaris-folkdoc.sourceforge.io/f1-usb.html#stm32f1-usb

Image tarball download link: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/mecrisp-stellaris-1882bdaff62f637a7bdd517d14f4c1a4.tar.gz/download

This image also pulses PA12 (Open-Drain Output) low for 1ms at USB start up. This is to to briefly pull USB-DP down but will be board specific.

[craif]

2 boards bought off amazon a week ago as a pair with a random st-linkv2.  Advertised as "initeq] STM32 ARM STM32F103C8T6 Blue Pill Minimum System Development Board"

The top one actually has a fully numeric id, but its brother from the same lot has a single "B" hiding in it...  so...   2 fakes?  Maybe someone is cutting their batches with fakes?  ¯\_(ツ)_/¯? 

The writing on both is maddeningly faint, but they both read

STM32
F103C8T6
991KA 93
MYS 903

top

Code: [Select]

stm32id
Die xy coords: 108003144
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00505689  | P V .
Lot_num ascii encoded [55:24]: 0x87071342  | . . . B

ok.
free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 63800 FREE: 1736
RAM.... TOTAL PRESET: 20000 USED: 960 FREE: 19040


bottom

Code: [Select]

stm32id
Die xy coords: 107872310
Wafer Number: 49
Lot_num ascii encoded  [23:0]: 0x0031304B  | 1 0 K
Lot_num ascii encoded [55:24]: 0x43113133  | C . 1 3

ok.
free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 63800 FREE: 1736
RAM.... TOTAL PRESET: 20000 USED: 960 FREE: 19040

The jumper's on the bottom ones each lost a shoulder while I've been goofing off with them.

I've worked with microcontrollers before, but these are my first STM32s so I've been attributing any fighting I've done with them to my own dumb ass rather than something working out of spec....  Honestly that still seems more likely.

[techman-001]

2 boards bought off amazon a week ago as a pair with a random st-linkv2.  Advertised as "initeq] STM32 ARM STM32F103C8T6 Blue Pill Minimum System Development Board"

The top one actually has a fully numeric id, but its brother from the same lot has a single "B" hiding in it...  so...   2 fakes?  Maybe someone is cutting their batches with fakes?  ¯\_(ツ)_/¯? 

The writing on both is maddeningly faint, but they both read

STM32
F103C8T6
991KA 93
MYS 903

top

Code: [Select]

stm32id
Die xy coords: 108003144
Wafer Number: 73
Lot_num ascii encoded  [23:0]: 0x00505689  | P V .
Lot_num ascii encoded [55:24]: 0x87071342  | . . . B

ok.
free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 63800 FREE: 1736
RAM.... TOTAL PRESET: 20000 USED: 960 FREE: 19040


bottom

Code: [Select]

stm32id
Die xy coords: 107872310
Wafer Number: 49
Lot_num ascii encoded  [23:0]: 0x0031304B  | 1 0 K
Lot_num ascii encoded [55:24]: 0x43113133  | C . 1 3

ok.
free (bytes)
FLASH.. TOTAL REPORTED: 65536 USED: 63800 FREE: 1736
RAM.... TOTAL PRESET: 20000 USED: 960 FREE: 19040

The jumper's on the bottom ones each lost a shoulder while I've been goofing off with them.

I've worked with microcontrollers before, but these are my first STM32s so I've been attributing any fighting I've done with them to my own dumb ass rather than something working out of spec....  Honestly that still seems more likely.

Thanks for the info, you don't need a dumb ass to fight Cortex-M3, I've been fighting it for years 

Do either chip have a 'hidden' second 64kB Flash ?
You can test for that with the STM32F103C8-DIAGNOSTICS.bin here: https://sourceforge.net/projects/mecrisp-stellaris-folkdoc/files/STM32F103C8-DIAGNOSTICS.bin/download

Generally if it advertises 64kB Flash, doesn't have any HEX in the lot numbers but has a second 64kB block that passes test with option "T" in the program above, then it's a STM32F103C8.

If it doesn't have any HEX in the lot numbers, advertises 64kB Flash and fails option "T" then it may be a CKS

I think your second unit is a CKS as it does have HEX in the lot numbers.

The STM32F103 is a very complex chip and if you don't know it very well you could waste weeks, months following the STM32 datasheet and running into problems because it's a CKS and has some differences.

The only way to be sure is to buy a STM32F103 Discovery or Nucleo board and compare the suspect blue pill(s) with STM factory board, but as the Blue Pills are only ~$2 each, is it even worth it ?

Note: I'm close to releasing a V2 of my Diags program that gives (I hope) more useful test based information.

[craif]

Did the flash test but forgot to post it.   They both passed!

top (decimal id)

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 ~~~~~

bottom (hex id)

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 ~~~~~


I'll be sure to grab the new tool once its out.