Cheap Bluepill, very likely it has fake STM32 right ?

[iMo]

Yeah, those are the small annoyances veteran BluePill users learned to live with 

10k resistor - you do not need to change it (for 1k5), it works fine with 10k.
USB connectors - I always resolder the usb connector mounting tips with a tin blobs
pin headers - the pins they ship are crap, I always solder in the gold plated ones (what doubles the price of the board actually)

Do not expect high-end finish with a board for $2 incl. shipping. There is maybe 100 manufacturers of "BluePill" boards and various clones of it (a dozen?). The same with MapleMinis. The bigger Pill pcbs (like F103ZET, F407ZET with 144pin stm32) are of high quality btw, but cost $10-$15.

Well, if the traditional BluePill was manufactured in US or EU, the quality would be maybe better, but you would pay 10x more.

[donotdespisethesnake]

What makes it "shoddy"?

Items such as inadequately anchored USB connectors that snap off after a few uses, incorrect value USB resistor (Google “R10 Blue Pill” for more information), header pin coatings that go rusty and FAKE mcu's.

The name "Blue Pill" is the personification of "shoddy".

https://www.yourdictionary.com/shoddy
shoddy definition: The definition of shoddy is something immoral or sordid, or is something badly made. (adjective) Stealing from people who trust you is an example of shoddy behavior.

*yawn*

Quality is defined as conformance to requirements. A carrier bag (for food shopping) is obviously not the same spec as an executive briefcase, but they both meet their quality targets.

These boards cost $1.86, really WTF do you expect... Maybe you should find some other windmill to tilt at.

[OwO]

I'm not sure if there are F4 clones, but on F303 gigadevice cheaped out by keeping the old F1 peripherals layout rather than copy the STM32F303 peripherals, so GD32F303 isn't drop in compatible with STM32F303, but it does have a Cortex-M4 and FPU (unless you are unlucky and get an early 2017 batch which have no FPU).  I simply developed my code targeting GD32F303 rather than STM32F303 because the BOM cost in that particular application (NanoVNA V2) is critical.

[techman-001]

I'm not sure if there are F4 clones, but on F303 gigadevice cheaped out by keeping the old F1 peripherals layout rather than copy the STM32F303 peripherals, so GD32F303 isn't drop in compatible with STM32F303, but it does have a Cortex-M4 and FPU (unless you are unlucky and get an early 2017 batch which have no FPU).  I simply developed my code targeting GD32F303 rather than STM32F303 because the BOM cost in that particular application (NanoVNA V2) is critical.

Thanks for the GD information, your NanoVNA V2 looks nicely done

Not that it matters but I  wonder if Gigadevices licensed or purchased the old F1 peripherals from STM as they seem to be using them in a lot of their MCU's?

The Gigadevices  RISC-V GD32VF103  (which also uses most of the F1 peripherals) is quite interesting, I'm playing with one at the moment.
https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

[iMo]

STM has no cooperation with GD. It is not needed.
GD has to talk to ARM to get the license and pay royalties. Nothing to do with STM.
F1 peripherals - you may copy it easily, a patent or license for an layout of bits in a register is a joke.
Moreover, the peripherals compatibility was in question in past (also USB etc).

[BravoV]

.... incorrect value USB resistor (Google “R10 Blue Pill” for more information) ...

Hmm ... my pill's R10 is using the right value, isn't that proof its not shoddy ? ... j/k 

[SiliconWizard]

The Gigadevices  RISC-V GD32VF103  (which also uses most of the F1 peripherals) is quite interesting, I'm playing with one at the moment.
https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

Just a small correction: you mention that the conditional branches range is +/-2048 bytes, which is not exact. Since instructions can only be aligned to 4 bytes, or 2 bytes for compressed instructions, the 12-bit offset actually encodes an offset that is in multiples of 2 bytes, which is clever, so the range is +/-4096 bytes. (I'm currently actively working on RISC-V so that piqued my attention!)

Otherwise, this little MCU seems nice. One thing I'm wondering about, and haven't really seen figures, is the power consumption. If you have a board, could you measure the current draw while the MCU executes code? I'm just curious.

[techman-001]

The Gigadevices  RISC-V GD32VF103  (which also uses most of the F1 peripherals) is quite interesting, I'm playing with one at the moment.
https://mecrisp-stellaris-folkdoc.sourceforge.io/gd32vf103.html#gd32vf103-longan-nano

Just a small correction: you mention that the conditional branches range is +/-2048 bytes, which is not exact. Since instructions can only be aligned to 4 bytes, or 2 bytes for compressed instructions, the 12-bit offset actually encodes an offset that is in multiples of 2 bytes, which is clever, so the range is +/-4096 bytes. (I'm currently actively working on RISC-V so that piqued my attention!)

Otherwise, this little MCU seems nice. One thing I'm wondering about, and haven't really seen figures, is the power consumption. If you have a board, could you measure the current draw while the MCU executes code? I'm just curious.

Thanks for the conditional branch info, I'll update my page

I'll set something up to measure the current drain, all I can really do that be be vaguely informative is a comparison under similar circumstances with a STM32F103, both  running a Forth primes program then post the results here and on my doc site. At least they use the same peripherals with a couple of exceptions.

[techman-001]

Re GD32VF103.
One thing I'm wondering about, and haven't really seen figures, is the power consumption. If you have a board, could you measure the current draw while the MCU executes code? I'm just curious.

As promised, a very rough indicator.

I have a elcheapo USB power monitor connected to a USB/3.3v dongle, there are two red power leds illuminated on the dongle and the longan-nano (one each) at all times.
Time is to reach prime 99991. Not 99991 primes.
Time is derived manually as I watch my PC clock, so allow +- 0.5 second !

Clock (MHz)	Description	Current (A)	Time (seconds)
8	Idle	0.00
8	primes	0.00	26
72	idle	0.02
72	primes	0.02	3.5
104	idle	0.02
104	primes	0.02	3

The STM32F103 72MHz quiescent was borderline at 0.02A with it jumping  to 0.00A about 50% of the time and the primes seemed to take 3.0 seconds rather than 3.5 but the RISC-V Forth I'm running is only experimental compared to the stable STM32F103 release.

So my very uninformed and adhoc impression is that the (genuine) STM32F103 is using less power than the GD32VF103.

[SiliconWizard]

I took a deeper look at the datasheet: https://www.gigadevice.com/products/microcontrollers/gd32/risc-v/

Comparing with the figures given in the F103 datasheet, it should draw less power/MHz in run mode, but of course there's a number of factors to take into account, such as which peripherals are enabled, etc, and the frequency you ran them at was also not the same obviously. Still, for the STM F103,  they state ~50mA @72MHz with all peripherals enabled (which is not terribly impressive), and for the GD32VF103, 33.7mA @108Mhz (also all peripherals enabled), which looks definitely better. Now that remains to be confirmed with measurements. Thanks for the couple measurements you made, unfortunately the tool you used is not really accurate enough... but we are definitely in the ballpark stated in the datasheets.

Other than power consumption at the typical 3.3V, I noticed two points that are worth considering when using a GD32VF103.

* First, min. VDD is 2.6V (vs. 2V for the STM32F103), which probably also says a thing or two about the process node they must have used. Or maybe it's all due to the flash memory... (which I suspect, see below!)
* Second, the startup time is very significant at 132ms... (and also the wakeup from standby mode which is almost as much...) They are much shorter on a STM32F103. Not sure what explains this as I haven't found clear documentation on the "boot" process. I'm suspecting that the internal flash is first copied to an internal SRAM block (which would allow 1/ cheap flash on a separate die and 2/ easily allow the zero-wait-state that is advertised), but I haven't seen that clearly stated (unless I missed it), and the block diagram makes it look like the core would have direct access to flash memory.

[iMo]

That is the same booting process as with the GD32F. I think the GigaDevices has taken the same road with GD32V chips as well (2 chips in the package).
Btw, a pretty clever decision. No need to cope with slow flash on the chip (like STM does with ART).
An you may design 1GHz mcu with zero ws.

[SiliconWizard]

That is the same booting process as the GD32F. I think the GigaDevices has taken the same road with GD32V chips as well (2 chips in the package).

Yeah, several clues are there that indicate it must be this.

It's definitely something to keep in mind. It may not matter in some applications, and may in others.

[iMo]

Sure, but what is the percentage of apps where you have to start your MCU app in XX clocks after a power on?

[BravoV]

Noob question, in order to identify STM32F103 vs GD32VF103, say both set @72MHz, run a tight loop, say many-many iterations that will make it significant, between the loop accessing the SRAM at GD32 vs Flash at STM32, and blinks the PC13 led after certain millions of iterations that human eyes can spot it ? 

[iMo]

Do you mean GD32F vs STM32F?
Run the same code (ie a benchmark) and count clocks with the internal DWT_CYCCNT counter.

[SiliconWizard]

Sure, but what is the percentage of apps where you have to start your MCU app in XX clocks after a power on?

In significantly less than >100ms, quite a few actually. Can be even more of a problem when getting out of standby mode if you use it, or simply after a reset (from watchdog for instance).
The 2.6V min can also be a concern in many low-power applications (although these days I would probably never use either the STM32F103 or the GD MCU for a low-power design anyway...)
Then, the fact flash is copied at startup can also pose some specific security concerns, so it's not necessarily the best approach for all designs. Sure is cheap though.

All this to emphasize some of the significant differences between the two MCUs (apart from having a different ISA) that could matter depending on specific requirements and that may not be obvious if you don't read the specs carefully.

Of course, it's likely that most users of "Bluepill" boards wouldn't care about any of the above. (But those, OTOH, will care about the two chips being actually not at all as compatible, at least peripheral-wise, as they could initially assume, which I think was an earlier thread in itself...)

[techman-001]

I took a deeper look at the datasheet: https://www.gigadevice.com/products/microcontrollers/gd32/risc-v/

Comparing with the figures given in the F103 datasheet, it should draw less power/MHz in run mode, but of course there's a number of factors to take into account, such as which peripherals are enabled, etc, and the frequency you ran them at was also not the same obviously. Still, for the STM F103,  they state ~50mA @72MHz with all peripherals enabled (which is not terribly impressive), and for the GD32VF103, 33.7mA @108Mhz (also all peripherals enabled), which looks definitely better. Now that remains to be confirmed with measurements. Thanks for the couple measurements you made, unfortunately the tool you used is not really accurate enough... but we are definitely in the ballpark stated in the datasheets.

Other than power consumption at the typical 3.3V, I noticed two points that are worth considering when using a GD32VF103.

* First, min. VDD is 2.6V (vs. 2V for the STM32F103), which probably also says a thing or two about the process node they must have used. Or maybe it's all due to the flash memory... (which I suspect, see below!)
* Second, the startup time is very significant at 132ms... (and also the wakeup from standby mode which is almost as much...) They are much shorter on a STM32F103. Not sure what explains this as I haven't found clear documentation on the "boot" process. I'm suspecting that the internal flash is first copied to an internal SRAM block (which would allow 1/ cheap flash on a separate die and 2/ easily allow the zero-wait-state that is advertised), but I haven't seen that clearly stated (unless I missed it), and the block diagram makes it look like the core would have direct access to flash memory.

Both MCU's had exactly the same peripherals enabled, the GPIOS and a USART. The Longan-Nano is a $5 board, it's tiny and has no quick method to measure only the MCU power (like any STM32 Discovery or Nucleo board), hence the rough indication of my quick test.

GD use a "flash into ram overlay" at bootup, hence zero wait states at 108MHz and the longer boot up time. I guess 132ms isn't *that* long in a world where all Windows users are conditioned to wait five minutes while their PC boots up ;-)

The GD documentation is very poor in comparison to ST Micro, for instance:
I can find no reference to SYSRESETREQ in the literature other than the reset-logic pic in the GD32VF103 User Manual V1.2 PDF (which I suspect is just  paste from the GD32F103 PDF). What this means is there seems to be no simple way to reset all the peripherals to power-up-defaults as can be done on STM32.

This is achieved in the GD32VF103 sample factory code using a long list of individual peripheral register resets.

[langwadt]

That is the same booting process as with the GD32F. I think the GigaDevices has taken the same road with GD32V chips as well (2 chips in the package).
Btw, a pretty clever decision. No need to cope with slow flash on the chip (like STM does with ART).
An you may design 1GHz mcu with zero ws.

with the down side that RAM uses much more die area than flash, and uses much more power doing nothing like in sleep mode

[westfw]

the startup time is very significant at 132ms...

Is that in addition to oscillator startup time, or "in parallel" somehow?
(I'll note that the normal Atmel AVR crystal oscillator start-up time is ~65ms.  But the STM32s start on an internal oscillator and you have to enable the crystal oscillator separately.  In theory, that could mean additional time (132ms to copy the flash to RAM, start running, enable the crystal oscillator and wait another few 10s of ms for that to stabilize...)

[techman-001]

the startup time is very significant at 132ms...

Is that in addition to oscillator startup time, or "in parallel" somehow?
(I'll note that the normal Atmel AVR crystal oscillator start-up time is ~65ms.  But the STM32s start on an internal oscillator and you have to enable the crystal oscillator separately.  In theory, that could mean additional time (132ms to copy the flash to RAM, start running, enable the crystal oscillator and wait another few 10s of ms for that to stabilize...)

Good points. One of the things I appreciate about the MSP430 is the 'instant' USART wake up from deep sleep.

And let's not overlook the ESP2866 which also uses the same serial FLASH technique at boot-up as the GD MCU's. That boot-up delay hasn't stopped millions of them being sold and deployed because of their low price, high clock speed and WiFi capability.

[westfw]

let's not overlook the ESP2866 which also uses the same serial FLASH technique at boot-up as the GD MCU's.

Does it?  I thought ESP8266 has XIP Serial flash with RAM Cache, plus a fair amount of code in ROM?(A bit of everything, it appears:  https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/general-notes.html )

[iMo]

GD32F/V includes some sort of ROM (or a state machine) too - the bootloader accessing the external flash (in case of the GD the second die inside the package). Thus ESP and GD are "flashless" mcus.

https://zeptobars.com/en/read/GD32F103CBT6-mcm-serial-flash-Giga-Devices

[GeorgeOfTheJungle]

But the startegy is completely different, the Giga Devices chip upon reset copies the entire flash contents into RAM and boots from the copy at full speed, but the esp32 can't do it because there's no way to copy (up to) 16MB of flash into 520kB of RAM, so it's got a flash caching mechanism that, as with all caches, if your code happens to jump all over the place^W flash address space too often, penalizes execution speed. For time critical code (interrupts!) or anything you need or want to have cached at all times no matter what, you can tell the compiler to leave it mapped permanently on to RAM with the IRAM_ATTR attribute.

https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/general-notes.html#application-memory-layout

Edit:
That "copy flash to RAM on reset" thing is nowhere to be seen in any of the Giga Devices datasheets. I said it because I read it somewhere in a forum on the interwebs, but now I don't think it's true.

[bingo600]

On topic 

User madias (over there), just got this "It's Fake" letter from STM
https://www.stm32duino.com/viewtopic.php?f=7&t=127

/Bingo

[iMo]

Is the silicon die inside the package original STM?
Where the die comes from?