I'm analyzing a BLDC controller based on STM32F030C8T6 and there is a clear usage of several peripherals missing in this chip officially, but existing in other models from the same line: the Hall sensor sampling is built around "missing" TIM2, the "missing" PVD is initialized. Is it something similar to F103C8T6 having 128K flash instead of official 64K actually?
I'm analyzing a BLDC controller based on STM32F030C8T6 and there is a clear usage of several peripherals missing in this chip officially, but existing in other models from the same line: the Hall sensor sampling is built around "missing" TIM2, the "missing" PVD is initialized. Is it something similar to F103C8T6 having 128K flash instead of official 64K actually?
Yes.
It's a common practice to "downgrade" chips, all mcu manufacturers do this.
The "missing" features may or may not be "blocked" in any way, but if they are not, they are not guaranteed to work - they were probably not tested, as testing forms a surprisingly high portion of the production costs. Also, given enough demand, the manufacturer may decide to produce an optimized maskset, where the "extra" features are "optimized out".
In other words, using the "extra" features is akin to overclocking. It's your leg you're shooting at.
JW
I'm analyzing a BLDC controller based on STM32F030C8T6 and there is a clear usage of several peripherals missing in this chip officially, but existing in other models from the same line: the Hall sensor sampling is built around "missing" TIM2, the "missing" PVD is initialized. Is it something similar to F103C8T6 having 128K flash instead of official 64K actually?
Yes.
It's a common practice to "downgrade" chips, all mcu manufacturers do this.
The "missing" features may or may not be "blocked" in any way, but if they are not, they are not guaranteed to work - they were probably not tested, as testing forms a surprisingly high portion of the production costs. Also, given enough demand, the manufacturer may decide to produce an optimized maskset, where the "extra" features are "optimized out".
In other words, using the "extra" features is akin to overclocking. It's your leg you're shooting at.
JW
a place I used to work accidentally used a few bytes of a of memory that was only supposed
to be in the bigger version of the chip, everything worked just fine until one day production
panic because everything failed. The volume of the that version of chip had gotten big enough
that the manufacturer had made an optimized version with only the memory that was supposed to be there
Sure, that looks suspicious, but the board I'm talking about is from a mass produced eScooter I'm seeing here riding every 5 min or so. There are thousands of them just in my city, the problem would pop up already. And it is not some brake light blinker, but a rotor position sensor which is critical to drive the motor.
Not guaranteed to work does not mean guaranteed to fail.
Let me guess: the manufacturer of those products is hardly be held accountable for failure of the product.
JW
It’s one of the most common rental eScooters in EU/US actually, NIU N1S.
All the 32F10x seem to use the same die, including the higher pin count R variants(64-pin)
Even you can use peripherals that are supposed to be disabled, like i2s, USB.. just set the device settings as a higher variant in the code.
The RAM is locked in a different way, will cause hard fault when trying to exceed the limit.
Although the speed seems what actually make the difference, 36MHz devices are usually unable to run any faster than that, while I've ran 32F103 at 120MHz (From be 72MHz max) by just increasing flash latency.
There are flash density categories: low density (64 and 128KB), medium density (256KB) and high density (512KB), and they appear to be different dies.
But, as you see, 64 and 128 are the same.
It’s one of the most common rental eScooters in EU/US actually, NIU N1S.
How does that change anything I wrote?
Quality does not equal success; often contrary.
JW
I mean quantity, not success. With so many vehicles riding around for several years already a repeating failure would be visible. I could name several other mass produced escooter’s common problems easily, but never heard about failing Halls on NIU.
I mean quantity, not success.
Fair enough. However,
Not guaranteed to work does not mean guaranteed to fail.
With so many vehicles riding around for several years already a repeating failure would be visible.
We are talking about random failures and parameter deviations here. For example, the "non-existent" PVD may have threshold voltages different than the DS states. Or the timer may have a stuck-on bit in some of its registers. The device still may be "working" overall, but it may be "weird". Cosider a scenario, where such failure does result in increased vibrations/noise, increased power consumptions, heating. How many of such would be treated as failure? How many would be traced back to the controller?
Semiconductor manufacturing is good enough these days so that the majority of digital devices is probably OK even without testing. And with large portions (if not majority) of circuitry being left unused in a typical application, you can get a partially or even fully working chip even with several faults. Analog may need trimming, but that depends on the particular product.
JW
All the 32F10x seem to use the same die, including the higher pin count R variants(64-pin)
Even you can use peripherals that are supposed to be disabled, like i2s, USB.. just set the device settings as a higher variant in the code.
The RAM is locked in a different way, will cause hard fault when trying to exceed the limit.
Although the speed seems what actually make the difference, 36MHz devices are usually unable to run any faster than that, while I've ran 32F103 at 120MHz (From be 72MHz max) by just increasing flash latency.
There are flash density categories: low density (64 and 128KB), medium density (256KB) and high density (512KB), and they appear to be different dies.
But, as you see, 64 and 128 are the same.
Interesting, I knew about the flash, but not about peripherals. So then we have:
- STM2F103C8 = STM32F103CB (64k/128k)
- STM32F030F4 = STM32F030K6/C6 (16K/32k) - I've tried myself
- STM32F030C8 = STM32F070CB (64k/128k) - according to OP
But then if the RAM is locked off as you say, you'd have to screw with the build files to add a custom version of the chip no?
Most engineers who have never worked in a semiconductor vendor would be amazed to find how many different part numbers have the same die inside these days. As the cost of producing a new mask set has risen, more and more sellable parts are being made from a single die. During development everyone says they'll make a custom die to cost optimise any variant that proves to be a big hit, but in the end opportunity cost issues usually means they don't. However, you usually can't use anything that the device is not supposed to have, as those modules are made invisible during assembly and test.
But then if the RAM is locked off as you say, you'd have to screw with the build files to add a custom version of the chip no?
Actually it's very easy. For example, to use a 101C8 as a 103CB:
Make a new project, select the 103CB, then edit the linker script (STM32F101C8TX_FLASH.ld) and adjust the ram length (Ex. 10KB for the 101).
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K // Change to 10K
Now you will be able to program it like a 103, but applying the flash/ram limits from the linker script.
Not everyting is ensured to work, I wouldn't use this for production.
But for yourself it's ok
Have a look at this table:
https://www.mikrocontroller.net/attachment/443532/stm32-families.txt
Same DIE number means the chip types come from the same die.
fchk
Great info! Where did they got that die data from?
Have a look at this table:
https://www.mikrocontroller.net/attachment/443532/stm32-families.txt
Same DIE number means the chip types come from the same die.
fchk
Great info! Where did they got that die data from?
They extracted the DIE numbers from XML files in the STM CubeMX package which describe the properties of each chip type. Seems to be official STM data.
fchk
Actually it's very easy. For example, to use a 101C8 as a 103CB:
Make a new project, select the 103CB, then edit the linker script (STM32F101C8TX_FLASH.ld) and adjust the ram length (Ex. 10KB for the 101).
RAM (xrw) : ORIGIN = 0x20000000, LENGTH = 20K // Change to 10K
Now you will be able to program it like a 103, but applying the flash/ram limits from the linker script.
Not everyting is ensured to work, I wouldn't use this for production.
But for yourself it's ok
Thank you
Have a look at this table:
https://www.mikrocontroller.net/attachment/443532/stm32-families.txt
Same DIE number means the chip types come from the same die.
Examples:
DIE439 STM32F302C(6-8)Tx (32k/64k)
DIE439 STM32F318K8Ux (64k) - cheaper version with no USB.
DIE422 STM32F302C(B-C)Tx (128k/256k) 2x 5MSPS ADC, 1x DAC
DIE422 STM32F303VCYx (256k) get 2x more ADCs and 1 more DAC
So who dares to try this one? Get an extra CPU core:
DIE450 STM32H742A(G-I)Ix - M7 core
DIE450 STM32H757ZIYx - M7, M4 core, crypto/hash, tft/mpi
Though the difference in price is not much at volume. Was thinking some of these oddball ones with no USB could be in stock, nope.
Who knows what ST actyally cuts down at die level using laser / efuses.
Mayebe these cores are permanently disabled, or not. It would great to know.
You know for sure that if ST starts selling less high-end mcus because of this, at some stage they'll completely lock their devices
Maybe coincidentally, similar question is being discussed
on a Russian forum, particularly the differently specified FLASH endurance for 'F030 vs. 'F031 (1k vs. 10k cycles).