30KB Blue-Pill USB Binary testing image.

• 30KB Blue-Pill USB Binary testing image.
  Posted by techman-001 on 06 Nov, 2019 15:27
• 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
  

  ---

  
• #1 Reply
  Posted by iMo on 06 Nov, 2019 20:09
• 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).
• #2 Reply
  Posted by GeorgeOfTheJungle on 06 Nov, 2019 20:57
•  
• #3 Reply
  Posted by thm_w on 06 Nov, 2019 21:35
• 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.
• #4 Reply
  Posted by iMo on 06 Nov, 2019 21:40
• 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
• #5 Reply
  Posted by Macbeth on 06 Nov, 2019 22:50
• 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.

  ---

  

  

  

  
• #6 Reply
  Posted by techman-001 on 06 Nov, 2019 23:13
• 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.
  
  
• #7 Reply
  Posted by techman-001 on 06 Nov, 2019 23:36
• Quote from: Macbeth on 06 Nov, 2019 22:50

  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.
• #8 Reply
  Posted by techman-001 on 07 Nov, 2019 01:04
• Quote from: Macbeth on 06 Nov, 2019 22:50

  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
  
  
• #9 Reply
  Posted by techman-001 on 07 Nov, 2019 01:56
• Quote from: techman-001 on 06 Nov, 2019 15:27

  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.
  
• #10 Reply
  Posted by thm_w on 07 Nov, 2019 05:24
• Added two genuine STM32 from LCSC, they are off by 1 lot number.
• #11 Reply
  Posted by GromBeestje on 07 Nov, 2019 19:22
• 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,
• #12 Reply
  Posted by techman-001 on 07 Nov, 2019 19:55
• Quote from: GromBeestje on 07 Nov, 2019 19:22

  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
• #13 Reply
  Posted by GromBeestje on 07 Nov, 2019 21:22
• Quote

  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.
• #14 Reply
  Posted by thm_w on 07 Nov, 2019 22:22
• Quote from: GromBeestje on 07 Nov, 2019 21:22

  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.
• #15 Reply
  Posted by Macbeth on 07 Nov, 2019 23:48
• Quote from: techman-001 on 07 Nov, 2019 01:56

  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. 
• #16 Reply
  Posted by techman-001 on 08 Nov, 2019 00:24
• Quote from: Macbeth on 07 Nov, 2019 23:48

  Quote from: techman-001 on 07 Nov, 2019 01:56

  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.
• #17 Reply
  Posted by techman-001 on 08 Nov, 2019 06:04
• Quote from: GromBeestje on 07 Nov, 2019 21:22

  
  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.
  
  
• #18 Reply
  Posted by Macbeth on 08 Nov, 2019 13:58
• 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

• #19 Reply
  Posted by techman-001 on 08 Nov, 2019 15:07
• Quote from: Macbeth on 08 Nov, 2019 13:58

  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.
• #20 Reply
  Posted by techman-001 on 08 Nov, 2019 23:40
• Quote from: techman-001 on 06 Nov, 2019 15:27

  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.
• #21 Reply
  Posted by techman-001 on 08 Nov, 2019 23:42
• Quote from: techman-001 on 06 Nov, 2019 15:27

  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.
• #22 Reply
  Posted by craif on 30 Jan, 2020 05:02
• 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.

  ---

  
• #23 Reply
  Posted by techman-001 on 30 Jan, 2020 06:11
• Quote from: craif on 30 Jan, 2020 05:02

  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.
  
• #24 Reply
  Posted by craif on 30 Jan, 2020 06:55
• 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.