ThomasToday I worked a little on a more complete hardware register map. I copied the map data from the STM8S003 datasheet and converted it into a new stm8s003f3.inc file with a simple AWK script. Make failed because "PC_IDR" was rendered as "PB_IDR". Great, a human touch! After correcting the typo I got the same results as with my original register map file (that doesn't mean that all the map addresses I didn't use before are correct ;-)).
In my little project I always had difficulties telling the "Value Line" STM8S003F3P6 and the "Access Line" STM8S103F3P6 apart. According to the front page of the datasheets the differences are :
| STM8S003F3P6 | STM8S103F3P6 | |
| Flash | 8 Kbyte Flash memory; data retention 20 years at 55 °C after 100 cycles |
8 Kbyte Flash; data retention 20 years at 55 °C after 10 kcycle |
| EEPROM | 128 bytes true data EEPROM; endurance up to 100 k write/erase cycles |
640 byte true data EEPROM; endurance 300 kcycle |
| Unique ID | - | 96-bit unique key for each device |
Shouldn't I have a different include file for the STM8S103F3P6 for the sake of consistency?
Besides the wildly different specs for Flash, the different size of the EEPROM, and the guaranteed write cycles (what does "up to" mean in a datasheet?) there is that one "unique selling point" for an "Access Line" device: the "Unique ID".
What's the "Unique ID" anyway? Using the Forth console on a STM8S103F3P6 I made a dump of the "Unique ID" address range :
$4865 $F dump
4865 0 7 0 3A 2 47 36 30 32 35 36 35 1F 0 0 1F ___:_G602565__ ok
According to the datasheet the numbers mean "xWafer=1792, yWafer=14600, wafer#=2, lot#=higherthanthereareatomsintheuniverse". Quite obviously the datasheet is wrong: ID = [ 7, 58, 2, "G602565" ] is more like it.
Wafer number, lot number, position: all that sounds much more like the data the fab's QA is after. It would be a shame if such critical quality assurance data were not available for "Value Line" devices, wouldn't it?
Let's run the same test on a STM8S003F3P6:
$4865 $F dump
4865 0 1C 0 46 6 47 35 34 37 36 37 37 1F 0 0 1F ___F_G547677____ ok
This looks familiar. Of course, it makes no sense to tailor QA process just for removing a feature that's not listed!
Now I got curious: what about the 640 vs. 128 bytes EEPROM?
hex ulock ok
4000 &640 + . 4280 ok
77EE 427E ! ok
427E ? 77EE ok
Guess what: the STM8S003F3P6 also has 640 bytes of EEPROM!
Be advised: there is no easy way to tell a STM8S003F3P6 and a STM8S103F3P6 apart, and there is a very high risk that you receive fake STM8S103F3 chips when you source from the gray market!
On the bright side, for hobby use you can put your trust in the outstanding quality record of ST, and simply ignore the intimidating reference to "100 cycles" in the Flash characterization. It's probably more like 10k, and then only if you have data retention requirements of "20 years@55 °C". Otherwise I'm, quite sure, the trusty device on the breadboard will tolerate 20k erase/write cycles (and if not, dump it).
Ah yes, and you can use the additional 512 bytes EEPROM, too. Other than the QA guarantees, the front page of the data sheet, and the missing description of the "Unique ID" the devices are the same. The STM8103F3 datasheet even has the same error as that of it's cheaper twin: the symbol PC_IDR is missing in the port mapping. too ;-)
EDIT: Paul found a STM8S003F3 chip with considerably less EEPROM memory than 640 bytes (but still more than 3x the size specified in the datasheet). So please be aware that you might "get what you paid" for & "YMMV".
Discussions
Become a member
In order to follow projects & hackers or give likes
Already a member?you need to create an account.
Tested my stm8s003s3f3p6, and it only had 416Bytes of 'eeprom'. Not the 640 advertised here, but still better than 128 advertised in the datasheet. Perhaps some portion of my chip's eeprom failed in testing and a section was disabled in hardware and the die was downgraded from 103 to 003..? I'll have to test some more chips and see what I find with those.
I was also able to read the chip's fuse ID just fine as well.
Are you sure? yes | no
I guess that STM8S003 chips are not tested to meet higher specs, or shown not to meet STM8S103 specs during testing. For anybody but the ST QA there is almost certainly no way to tell how much more besides what's described in the datasheet one will get. It's good if it works, and bad luck if it doesn't :-)
By the way, based on the assumption that the EEPROM is organized in units of 64 bytes 416 bytes is an odd number (it suggests that there are units of 32 bytes). How did you test it?
Are you sure? yes | no
I simply used stm8flash tool to read/write from eeprom with a file. Only the first 416 bytes of my 640 byte file were able to be written and read back. Bytes 417-640 read back as zero. The datasheet explains the memory as erase granularity is 4 bytes. Having previously worked in memory industry, it seems reasonable they can disable portions of flash/eeprom as small as 32Bytes.
Are you sure? yes | no
You're right to call for careful statements. Getting more memory than the advertised 128 bytes is always "complementary", or a "free gift" for the hobby or development use case. Even selecting chips is out of the question for commercial use. It looks like a good idea to include a "memory survey" test in the STM8EF makefile.
Are you sure? yes | no
The same goes for 64 vs 128kB variants of STM32F103. All the 64kB versions do actually hold 128kB worth of FLASH and I ran more than 64kB programs on it, with no problems at all. But manufacturer guarantees only first 64kB - this is the amount of FLASH that is actually tested. Testing is expensive, by not testing some features they can sell it cheaper, what more, it increases manufacturing yield.
Are you sure? yes | no
This makes sense & good to know (STM32S103CBT6 boards cost much more than the 64K variant).
Depending on how stable a manufacturers process is they may also have some way to switch off a defective partition of some kind of memory (the same goes for EEPROM, complex timers etc). I reckon that for most testing and hobby usage taking advantage of such "free resources" is a good thing, but I'm concerned about cases where re-labeled cheap components (virtually indistinguishable from the real thing) appear on the gray market. If one is responsible for the reliability of a product such fake devices turn out to be very, very expensive.
Are you sure? yes | no
I checked the datatsheet of the Automotive STM8 variants STM8AF6213/23/23A/26: the STM8A6223 is rather similar to the STM8S103F3. The number of guaranteed Flash cycles is at 1k, there is a "LINUART" UART4 device instead of the UART1. The Timer2 is replaced with a Timer5 (which is about as capable as Timer1), and Timer4 is replaced with a Timer6 (which can be chained with other timers).
How different are the devices exactly? I played a bit with as the reserved registers of Timer2 and Timer4 to test the hypothesis that these are in fact Timer4 and Timer6. There are indications that this is the case, but I'll have to write proper test code. On the other side, the register set of UART2 isn't a subset of a LINUART. If it's the same UART someone must have spent some effort to hide it (the register address differs at one point).
Are you sure? yes | no
That goes in the same direction, thanks!
I guess that these guys use all the tricks in the books to please the automotive industry customers (with a cutthroat "business margin"/"quality requirements" ratio) *and* still make money. Most likely, the wafers that are used to calibrate the fab process for the automotive chips can still be dumped on the Chinese market.
Some people with not-too-expensive ties must be thinking really hard what to write in product line-ups, and some people must even sit down and doctor the tables in datasheets for devices with reduced specs (like you, I also compared the datasheets - most of the values in the tables and diagrams are identical, even if the arrangement was changed ;-) ).
Are you sure? yes | no
I saw the same thing on my couple of batches of STM32F030. They are actually 32K chips from STM32F050 line instead of 16K.
https://hackaday.io/project/9469-misc-arm-projects/log/31288-stm32f030-observations
Are you sure? yes | no