STM8 Low Density Devices
Some industrial STM8S devices are actually rebranded automotive STM8AF devices, and these sometimes have hidden "application specific" features worth exploring.
STM8 Low Density devices are among the cheapest micro-controllers available that are powerful enough to host an interactive programming environment. They can be divided in Standard (S) and Low Power (L) devices, and both families have at least two major variants.
STM8S "low density" devices can be divided in different variants, industrial (standard) and automotive (also called "application specific"):
| Base | Similar products |
|---|---|
| STM8S103 | STM8S003, STM8AF6223 |
| STM8AF6226 | STM8AF6223A, STM8S903, , STM8S001J3M3 |
Note that the GPIO-pin assignment the STM8AF6223 (TSSOP20 package) is like STM8S103F3P6 and similar to STM8S903F3P6. STM8AF6226 in a 32 pin is like the STM8S903K3 but the STM8AF6223A (the same chip in a 20 pin package) has a pin assignment dissimilar to the STM8S903F3P6.
Both low density device types have a very similar set of peripherals but the STM8AF6226 "family" is more versatile:
- ADC channel with bandgap reference
- one more ADC channel available
- cascadable timers
- UART GPIO pins reconfigurable from PD5-PD6 to PA3/PF4
The STM8S103 features are more or less a subset of those of the STM8AF6226, so most applications written for the first device should work on the second.
This similarity between the STM8S103 and the STM8AF6223 suggests that the UART in both devices is of type UART4 (LINUART) and not UART1 like documented in the STM8S103 datasheet. If it doesn't support LIN "Slave Mode" then there are really at least 3 types of STM8S Low Density devices.
STM8S103 is marketed as a commercial general purpose (i.e. not automotive) STM8S "low density" device.
A comparison of datasheets between the "Value Line" STM8S003F3P6 and the "Access Line" STM8S103F3P6 suggests that it's the same silicon with a different specification (e.g. number of Flash write cycles), and with a different specified EEPROM size (Value Line devices specify 128 bytes but tests show that up to the same amount as in the higher rated devices may be available). The same is maybe true for the STM8S103F2P6 for which 4K instead of 8K Flash memory are specified.
The STM8S Low-Density errata sheet makes no difference between "STM8S001J3, STM8S003xx, STM8S103xx and STM8S903xx device limitations", which means that all these chips are at least "very similar".
In the STM8S001J3 datasheet there is a bit of information that's not in the STM8S003 datasheet:
Note: The PA2, PB0, PB1, PB2, PB3, PB6, PB7, PC1, PC2, PC7, PD0, PD2, PD4, PD7, PE5 and PF4 GPIOs should be configured after device reset in output push-pull mode with output low-state to reduce the device’s consumption and to improve its EMC immunity. The GPIOs mentioned above are not connected to pins, and they are in input-floating mode after a device reset.
Only 32 pin devices provide the GPIOs mentioned in the note (e.g. LQFP32 STM8S003K3). The advice is thus also applicable to STM8S003F3 (i.e. PB1, PB2, PB3, PB6, PB7, PC1, PC2, PD0, PD7, PE5 and PF4).
The latest member of the STM8S00x "Value Line" is the STM8S001J3 in a SO8N package, which has about the same dimensions as the TSSOP20 but, due to the reduced pin count, is very easy to solder.
A note in the STM8S001J3 datasheet states that the STM8S001 is a member of the "low density family", and it's not a special "stripped down" silicon with (curiously) more alternative pin functions:
Note: As several pins provide a connection to multiple GPIOs, the mode selection for any of those GPIOs impacts all the other GPIOs connected to the same pin. The user is responsible for the proper setting of the GPIO modes in order to avoid conflicts between GPIOs bonded to the same pin (including their alternate functions). For example, pull-up enabled on PD1 is also seen on PC6, PD3 and PD5. Push-pull configuration of PC3 is also seen on PC4 and PC5, etc.
This means that the SO8N package contains the same chip as a device with more pins (i.e. the "Application Specific Line" device STM8S903F3 in a TSSOP20 package). It should be possible to combine up to 4 GPIOs (pin 8) for push-pull of up to 80mA load within the specification (pin 8).
The following GPIOs/features are available:
| Pin | GPIO | Features |
|---|---|---|
| 1 | PA1 | OSC_IN |
| 1 | PD6 | UART1_RX, AIN6 |
| 5 | PA3 | TIM2_CH3, [SPI_NSS], [UART1_TX] |
| 5 | PB5 | I2C_SDA |
| 6 | PB4 | I2C_SCL, [ADC_ETR] |
| 7 | PC3 | TIM1_CH3, [TLI], [TIM1_CH1N] |
| 7 | PC4 | TIM1_CH4, CLK_CCO, AIN2, [TIM1_CH3] |
| 7 | PC5 | SPI_SCK, [TIM2_CH1] |
| 8 | PC6 | SPI_MOSI, [TIM1_CH1] |
| 8 | PD1 | SWIM |
| 8 | PD3 | TIM2_CH2, TIM2_CH2, ADC_ETR |
| 8 | PD5 | UART1_TX, AIN5 |
The Alternate Function options if the STM8S001J3 are identical with the STM8S903. Compared to the STM8S003 low density devices there are the following additional features:
- UART1_TX can be mapped to GPIO PA3
- Timer synchronization/chaining features (TIM5 and TIM6 instead of TIM2 and TIM4)
- AIN6 at GPIO PD6 (the STM8S903 has 6 analog inputs)
- AIN7 is connected to an internal bandgap reference
The timer and the bandgap reference features are undocumented but a test (e.g. querying the ADC7 with 7 ADC! ADC@ . in STM8 eForth) results in 400 at roughly 3.3V supply, which is consistent with the specs (the STM8S903 datasheet specifies the reference as 1.19 to 1.25V).
When comparing the UART features in Table 52 of the STM8S Reference Manual RM0016 it's a curious fact that "NA" doesn't mean "Not Available" but "Not Applicable". Since it's hard to see that there are should be two styles of UART1 (one in STM8S903 and STM8S001 devices, the other in STM8S103), it's likely that the name "UART1" in the STM8S903 and STM8S001 datasheets is misleading, and that these devices have a "UART4" ("LINUART") with full LIN features like the STM8AF6226. This remains to be tested.
Whoever assigned the GPIOs to SO8 pins must have a particular set of requirements. A final assessment if the solution we now see should also look at constraints, like the position of bond pads on the die that may have caused some "non features" and restrictions of usability:
- when UART1_TX is mapped to GPIO PA3, UART1_RX is hidden (mapped to GPIO PF4, not connected)
- high risk of lock-out when using a full-duplex UART (why share PD1 pin with PD5, not PD6?)
- no SPI MISO - the SPI is limited to the rarely used half-duplex mode
STM8 Low Density devices consist of two distinct families:
- STM8L101, including STM8L001J3M3 (SO8)
- STM8L05x, including STM8L050J3M3 (SO8)
The STM8L101 family has the lowest power consumption, and 1.5K RAM (instead of only 1K ) but it lacks RTC and ADC and there are important differences and limitations with respect to non-volatile memory (e.g. Flash and EEPROM are unified) and IAP (exiting in application programming requires a device reset). Right now no STM8 eForth support is planned but it's certainly a good device for power critical applications that need some more RAM (e.g. transfer some application code to RAM, disable the Flash memory, and run the code at 38 kHz on a tight power budget).
This said, programming an STM8L101 with STM8FLASH and a cheap ST-LINK/V2 clone has been notoriously difficult. Using a recent version of STM8FLASH (3ad9500 at the time of writing) and a recent version of the ST-LINK/V2 firmware (STSW-LINK007 with firmware 2.34.25 tested in a USB-dongle type and a pod style ST-LINK/V2 clone) it was possible to read/write flash of a STM8L101F3P6, and to read an STM8L001J3M3 (writing consistently results in "Tries exceeded"). For device in SO8 it's currently a safer bet to use the tools provided by ST (i.e. STVD-STM8).
Unlike the STM8L101 and like the Medium/High Density STM8L family members, IAP in the STM8L051 behaves like in STM8S devices. The peripherals are often superior to those in STM8S (e.g. RTC, 12 Bit ADC, Vcap not required), but they also show important changes with respect to the standard family (GPIO interrupts) and it's absurdly difficult to learn about differences and commonalities. One should think that it's easy for a company like ST to provide a synopsis to make the migration of applications easier, but it's likely that the management went the way of the automotive industry (i.e. they replicated the STM8S organization, and the STM8L tribe doesn't even know the STM8S docs).