Yet another question about the STM32 clones...

[Camilo71515]

Hi there!
Me and a partner are developing a product and would like it to be based around the GD32F103C8T6, which seems to be a clone of the STM32F103C8T6. We chose this micro controller due to cost, availability and peripherals.
Most of our product is based around the blue pill modules that are found very cheap on AliExpress, and the GD32F103C8T6.
We'd like to know what are your opinion and experiences with this micro's vs the originals from ST.
Is it possible to use them with the CubeIDE and the ST-Link?
Do the debug functions of the ST-Link will work with this "clones"?
Thanks in advance to y'all!!

[ataradov]

Using Cube would violate the licence you accept before the download:

This software package or any part thereof, including modifications and/or derivative works of this software package, must be used and execute solely and exclusively on or in combination with a microcontroller or a microprocessor devices manufactured by or for STMicroelectronics.

ST-Link itself should work, but the IDEs designed for STM32 may not work correctly with  GD32 devices.

Treat this as a different device that is similar, but no the same.

[peter-h]

This is a potentially interesting thread because my 32F417 project is nearly done and none of the hardware crypto features were used (most are obsolete, and aes256 runs fast enough in software for this job) so I could use a 32F407 which exists in some chinese clones.

I would expect the peripherals to have subtle differences.

[rooppoorali]

Here is an article about the differences between these two. You may find it helpful: https://www.hackster.io/techmirtz/alternative-to-stm32f103c8t6-by-gigadevice-43e7b2

[peter-h]

That's unfortunately a very superficial comparison.

If you make loop based delays use the system clock value, it should still work the same way. But I would say almost nobody will use a chinese CPU for a faster clock option. For a lower price, or for availability, definitely!

A much better way to make delays is to use CCYCNT.

I wonder if anyone has reported on things like timers, DMA controllers, etc. In fact are the DMAs a part of the ARM core and not "peripherals" like e.g. SPI are? The peripherals run from the APB clocks and run slowly, so accessing them takes up a lot of clock cycles, whereas AFAIK that is not true for the DMAs.

IDEs designed for STM32 may not work correctly with  GD32 devices

What would be the reason for that? The IDE, AFAICT, is mostly to do with tool (compiler etc + debugger) integration.

[ataradov]

In fact are the DMAs a part of the ARM core and not "peripherals" like e.g. SPI are?

No, it is not.

What would be the reason for that? The IDE, AFAICT, is mostly to do with tool (compiler etc + debugger) integration.

Mostly device ID registers. If clones match them exactly, then it will probably work. But there are also differences in timings, differences in the ARM core revisions. But I doubt IDEs would check that unless they explicitly want to detect the fakes.

But keep in mind that the more complex the device is, the more clones deviate from the original. There are a lot of small differences, but it may be annoying, especially if you want to make a firmware that works on both.

[peter-h]

So the DMAs are slow to access too? That's interesting. No wonder memcpy is used a lot instead of DMA, in ETH code

Re Cube IDE getting confused when configured for one chip but finding another chip, I posted this
https://www.eevblog.com/forum/microcontrollers/is-st-cube-ide-a-piece-of-buggy-crap/msg4316272/#msg4316272
It does work ok but it does funny stuff with displaying the "unexpected" memory, which is probably to be expected.

OTOH, nothing stops one developing code with a real ST chip and then programming the code into a chinese fake; if you got it right, it will run and the IDE won't be relevant.

[ataradov]

So the DMAs are slow to access too?

To access in what way? DMA controller registers are on the APB bus. The DMA data interfaces are on the AHB bus The bus system is pretty complicated and it is hard to predict what would be slow or fast. There are a lot of factors that go into it.

But DMA transfer would be faster regardless. It is just for simple things it makes no sense to complicate the code and software memcpy() works just fine. Not everything needs to be optimized to death.

[wek]

DMA controller registers are on the APB bus.

In which STM32?

JW

[ataradov]

In which STM32?

In all of them. This is a common way to design DMA controllers.

[wek]

In which STM32?

In all of them. This is a common way to design DMA controllers.

Probably in none of them.

Both the single-port and dual-port DMA registers are accessed through a slave AHB port.

I don't know the MDMA in 'H7 nor the new DMA modules in 'U5, and I don't know the 'Wx at all, and I may have overlooked some.

JW

[ataradov]

My bad, they indeed put the control register on the AHB bus. This seems strange to me.

I looked at a few other vendors and it looks like placing DMA registers on the APB bus is not as common as I thought.

[wek]

My bad, they indeed put the control register on the AHB bus. This seems strange to me.

Why?

All "fast" peripherals in STM32 (ETH, USB, DMA, GPIO except in the ancient 'F1 and CM0+-based, LCD, crypto, CRC - heck even the FLASH control interface :-) ) are setup/controlled through slave AHB bus.

Other manufacturers may have different approach. I am very un-knowledgeable of other 32-bitters. APB is there to offload load from long buses at the cost of speed (latency).

JW

[ataradov]

Why?

There is no reason for DMA configuration to be fast. You don't really access it much after the initial setup. And adding more peripherals on the fast bus can't be good for the bus performance. But it looks like they manage to get the necessary performance, so it is fine.

But it also appears that they wrap both master and slave into a single interface, so it does not need additional real ports on the bus matrix. I need to look into how exactly they are doing that.

[dietert1]

Recently i happened to get a bluepill with a cloned or bad STM32F103. It responds a CM4 signature, while CM3 was expected. I found a way to debug it, pretending it is a GD32E103 (CM4 core expected). But i put it aside after verifying it isn't a GD32E103. Some peripheral registers did not respond where expected.
I think clones are difficult for business. The meaning of clone in this context is betrayal, so you may always get a clone of a clone or a different revision - different enough to make your product fail. As far as i know this even happened with original STM32 products, when they changed the MCU ID code in later revisions.
One would need a tool to verify all functions mentioned in the reference manual. Like automatic detection of memory ranges and peripheral registers (producing lots of hard faults). Then, in order to check it, one would need an interpreter to extract the info from a reference manual.

Regards, Dieter

[wek]

There is no reason for DMA configuration to be fast. You don't really access it much after the initial setup.

Well, not quite, it depends.

Can you please give me a "reference/typical" ATSAM number (you're Atmel guy, right?) so that we understand each other in what's reasonable and what not?

Thanks,

JW

[wek]

Recently i happened to get a bluepill with a cloned or bad STM32F103. It responds a CM4 signature, while CM3 was expected. I found a way to debug it, pretending it is a GD32E103 (CM4 core expected). But i put it aside after verifying it isn't a GD32E103. Some peripheral registers did not respond where expected.
I think clones are difficult for business. The meaning of clone in this context is betrayal, so you may always get a clone of a clone or a different revision - different enough to make your product fail. As far as i know this even happened with original STM32 products, when they changed the MCU ID code in later revisions.
One would need a tool to verify all functions mentioned in the reference manual. Like automatic detection of memory ranges and peripheral registers (producing lots of hard faults). Then, in order to check it, one would need an interpreter to extract the info from a reference manual.

Regards, Dieter

Well, an outright counterfeit (i.e. if the chip is marked STM32 and inside is a clone) is IMO not worth consideration at all.

IMO most of the cloners made considerable effort to make sure that typical STM32 programs - i.e. those clicked in CubeMX for a bluepill - will mostly work out of the box. It's only those cases where timing, pins' leakage/drive, etc. matters, where things are more likely to go astray.

JW

[ataradov]

Can you please give me a "reference/typical" ATSAM number (you're Atmel guy, right?) so that we understand each other in what's reasonable and what not?

Representative Cortex-M0+ is SAM D21. Representative Cortex-M7 is SAM V71. Both have DMA configuration in the APB space.

I looked at a bunch of devices for which I had documentation handy.  The only devices I could find with registers on the APB are MAX32660 and i.MX series. i.MX have proprietary bus (AIPS), which seems to be similar to APB in function.

ARM PL330 IP also uses APB for configuration, but I don't even know if anyone uses this in practice.

[wek]

> SAM D21/ SAM V71

Thanks. I'll have a look. It is probably not surprising that SAM D21 came up as first with the simplest possible google request (ATSAM)...

> I looked at a bunch of devices

Interesting. Does this mean that most DMA (or DMA-capable-peripherals') registers appear to quite regularly be connected through AHB rather than APB?

I had a look at Nuvoton's NUC505 (although it's an outlier in Nuvoton's offering). It does not appear to have a general-purpose DMA, but quite a couple of peripherals embed its own DMA (USB Host, USB Device, SPI (they call it SPIM), SD controller, I2S), i.e. they are AHB masters (and there's also a somewhat intriguing arbitration scheme for them), and almost all of them have also registers connected as AHB slaves, except I2S, which is on APB (yes, that's the one which is typically configured only once or seldom).

JW

[ataradov]

Interesting. Does this mean that most DMA (or DMA-capable-peripherals') registers appear to quite regularly be connected through AHB rather than APB?

I also looked at GD/WCH devices, but those are clones of the STM, so they are designed the same as STM32.

Nuvoton M480 series uses AHB interface. Interestingly on the drawing it shows one AHB interface and "Master / Slave Wrapper" attached to it. So, I guess they manage to change the role on the fly.

Also, on a second thought, all those AHB peripherals are obviously not direct slaves on the main matrix. They all are represented by one AHB slave interface on the main matrix. So, it is not all that different from the APB. So, I guess I was overthinking the potential overhead.

It looks like EFM32 devices use direct AHB too.

I have not looked at anything else.

[dietert1]

..
Well, an outright counterfeit (i.e. if the chip is marked STM32 and inside is a clone) is IMO not worth consideration at all.

IMO most of the cloners made considerable effort to make sure that typical STM32 programs - i.e. those clicked in CubeMX for a bluepill - will mostly work out of the box. It's only those cases where timing, pins' leakage/drive, etc. matters, where things are more likely to go astray.

JW

In my case the chip is marked to be a STM32F103C8T6. But it reports 128K flash with 64K expected and the wrong core id. So it's not a glitch of an original chip, but a clone. So i would need to characterize that chip in all detail, which is a major effort. It won't happen.

Regards, Dieter

[ataradov]

That's just a fake, I would not consider using that at all. "Cloned" devices released under their own name with their own datasheet are fine.

[peter-h]

It would be good to see photos.

I have posted some in the past, here.

Most chinese fakers are not particularly clever; much of china now runs as a gangster economy, full of opportunists, and looking for whichever devices are in demand, and they quickly set up a production line, often making empty packages (I've had H8 CPUs like that).

[up8051]

Recently i happened to get a bluepill with a cloned or bad STM32F103. It responds a CM4 signature, while CM3 was expected. I found a way to debug it, pretending it is a GD32E103 (CM4 core expected). But i put it aside after verifying it isn't a GD32E103. Some peripheral registers did not respond where expected.
I think clones are difficult for business. The meaning of clone in this context is betrayal, so you may always get a clone of a clone or a different revision - different enough to make your product fail. As far as i know this even happened with original STM32 products, when they changed the MCU ID code in later revisions.
One would need a tool to verify all functions mentioned in the reference manual. Like automatic detection of memory ranges and peripheral registers (producing lots of hard faults). Then, in order to check it, one would need an interpreter to extract the info from a reference manual.

Regards, Dieter

Probably Artery AT32F403

[wek]

> Nuvoton M480 series ... EFM32 devices...

Thanks for doing this research. It would be interesting to talk to the designers about these design choices.

I looked at the "smallest CM4F", that MAX32660 you've mentioned above. Similarly to the SAM-D21, all peripherals are behind an AHB-APB bridge, but here's only a single bridge and the only other AHB slave on the S-port of processor is the SRAM. Here it may something to do with being the "smallest" perhaps, brutally simplifying any address decoding.

Sorry all for hijacking this thread.

JW