Today 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 :
|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".