STM8S001J3 - The Good, the Bad and the Ugly

A project log for MCU how-tos, reviews, rants

As title says, my random essays about microcontrollers, all in one package

jaromir.sukubajaromir.sukuba 09/12/2017 at 07:5412 Comments

Before the STM8S001J3 MCUs hit the streets, I received a few samples directly from ST Microeletronics to evaluate. ST finally jumped on a train ran by companies like Microchip or NXP for something like 20 years. It is coming from STM8S family, now being almost classic and well proven chip family.

The Good
STM8S001J3 is very similar to STM8S003F3 - so much similar it's probably the same silicon chip, actually. There is nothing inherently wrong about it, as it makes development cheaper - that is easier for manufacturer and cheaper for end customer - and allows to jump on existing development tools, again enabling customers to work with the MCUs easier and faster.

The Bad
On the other hand, dark side if this decision is easily recognizable. Fitting 20-pin chip into 8-pin frame forces designers into some compromises - which pins to expose, which ones to leave unconnected? Another option is to merge multiple bonding pads to single package pin - and that is route which was chosen in ST.
It allows multiple peripherals to be shared on single pin, which could be advantageous at times, also uncomfortable, as seen later.
From 8 pins of SOIC package, two are for power supply pins - there is not way doing it otherwise. One is sacrificed for VCap pin. As this one is based on STM8S, with supply voltage range up to 5V and relatively modern core manufactured on "dense" manufacturing process, innards of MCU are supplied by lower voltage, requiring internal LDO to do this job. VCap is pin to connect capacitor to keep this LDO stable - and this pin can't be used for anything else.
I wish ST would design also STM8L device in SOIC package. Apart from Vdd being maximum 3,6V (nothing unusual in last 10-15 years), this would free up one pin (now sacrificed to VCap) and sleep current consumption would be as low as usual for STM8L devices. STM8S (including STM8S001J3) do have sleep consumption of about 5-10uA, what is one order of magnitude higher than sleep current of MCU devices designed 15 years ago!

The Ugly
Now, with 5 pins, guys at ST had to decide what to do with the other ones. Higher pin count STM micros do have dedicated NRST (Not ReSeT - low active reset) pin, but from obvious reasons they decided to omit it on 8-pin STM8. And SWIM pin is shared with three other pins; being it not exactly ideal solution, as confirmed by datasheet too:

So, setup your data direction register into wrong state and there you have it - OTP device. We have seen really bad programming interfaces in the past - just like AVR. With more than one way of programming of FLASH, you can easily lock one or another access, having fall-back in 1980's parallel programming. That being said, once the fuses were setup correctly, one didn't have to touch it anymore and any further access was safe. On this device it's different. DDR registers have zero protection agains fuck-ups, from programmer side or even from runaway program - that is particularly dangerous, IMO. With STM8S001J3 you should always have a few spares and hot-air soldering gun for the case you do something goofy in your program. One solution of how to escape this problem is to set-up and use some kind of bootloader to load the FLASH.
While absolutely vital SWIM pin is shared with three other pins, PB4 is just alone. I wish it would be other way around. And alternative pin functions list don't mention MISO signal of SPI interface. Either MISO is forgotten in documentation, or it's forgotten to be bonded out. On STM8S003F3, MISO is on PC7, which is explicitly being listed as NC

I hope it's alternative function to some other pin, otherwise the SPI would be seriously crippled without MISO.

All in all, while STM8 family seems to be one of the better 8-bit MCU design, this 8-pin variant does seem to suffer a bit from compromises during design stage. I really hope ST will release new 8-pin device, as there seems to be space for further optimizations.


Wesley Brianez wrote 08/29/2019 at 20:03 point

the trick is put the SWIM PIN as input pin using a key for example.

If you have to use it as output, a 5s delay should be done for debug and reflash issue

  Are you sure? yes | no

Richard Aplin wrote 09/19/2017 at 04:27 point

I got some samples but bricking them (primarily by turning any of the pins connected to SWIM to outputs, easily done) is a bit worrying. I think my solution might be to check if SWIM is held low (or high, whichever is convenient depending on schematic) on boot and if so just sit in an infinite loop before anything else gets configured. There's probably a cleverer way to do it too...

  Are you sure? yes | no

Richard Aplin wrote 09/28/2017 at 23:42 point

I put in a safety thing as described (hang in infinite loop without ports set up if SWIM is low), but I've had no problems with the STM8S001; it works fine. I did check carefully that my code has all the parallel-bonded pins set up correctly ;-)

  Are you sure? yes | no

Richard Aplin wrote 09/12/2017 at 19:14 point

I think with the PB4/PB5 pin choice they prioritized retaining i2c over anything else, and that fits my application.

  Are you sure? yes | no

Richard Aplin wrote 09/12/2017 at 19:13 point

I like it. Huge compromises required for 8 pins (esp the vcap thing) but it just so happens I have a design with STM8S003 in it and someone just asked for a reduced version that is ideal for an 8-pin version. I'll do all development and debugging on the full size version though :-)

  Are you sure? yes | no

K.C. Lee wrote 09/12/2017 at 19:06 point

There are 3 pins for power, if you have a full duplex SPI port which only leaves you 1 pin.  You could  bitbang the SPI and not like there are too many other real time peripherals to worry about with that 1 I/O line.

Chances are that the die size prevents them from making a TSSOP8 which would have been nice.  If it has to be SO8 size, I would prefer to see a TSSOP14 (about same size) and not have to compromise as much.

  Are you sure? yes | no

Thomas wrote 09/13/2017 at 05:26 point

The STM8S003F3P6 already has a very low price (I've seen it for less than $0.20/unit). Creating an "almost as capable" TSSOP14 device would created unwanted internal competition.

The SO8 is about as low-tech as today's industry gets - 1.27mm is a lot these days. This enables applications that would otherwise use a NE555, an LM358, and a (still surviving) 80s 74HCxxx chip.

One more observation: SPI clearly wasn't the main concern, but I2C was: pin6 provides a standard compliant open-drain SDA, and not much else. What a waste in package that bonds 3 more GPIOs to PD1/SWIM. On the other side, if you need a programmable I2C peripheral device, you get 3 Ain, 2 timers, and a UART to play with.

  Are you sure? yes | no

Thomas wrote 09/12/2017 at 18:26 point

I fully agree that an the STM8L would have been a better choice. The STM8S is most likely a tiny bit cheaper. You're right, MISO isn't accessible (the datasheet discusses that in detail), and I'd really like to know why the ST product designers took that decision. There is a bidirectional mode for the SPI, but that's not for everybody.

  Are you sure? yes | no

jaromir.sukuba wrote 09/12/2017 at 18:57 point

My biggest gripe is that OTP-bilty. I think it's serious flaw, severely limiting development, especially in DIY conditions.

Could you, please, point out where is MISO discussed in datasheet? I can't find it.

  Are you sure? yes | no

Thomas wrote 09/12/2017 at 20:15 point

STM8EF works around the "OTB" issue by providing a console (OK, you can also kill the console, but an OS like feature is harder to break).

There is no MISO but 4.13.2, says something about the limitations of not having that signal:

• Maximum speed: 8 Mbit/s (f MASTER /2) both for master and slave
• Unidirectional transfer: SPI master mode transmit/receive only, SPI slave mode receive only
• Simplex master synchronous transfers on two lines with a possible bidirectional data line

  Are you sure? yes | no

jaromir.sukuba wrote 10/30/2017 at 12:16 point

Looks like we are going to have STM8L in 8-pin package

STM8L001J3M3 a STM8L050J3M3

  Are you sure? yes | no

Thomas wrote 10/30/2017 at 16:34 point

Well spotted! STM8 eForth will have support for STM8L (I ordered some STM8L051F3P6). 

Question: Is anybody aware of a peripherals synopsis of the L together with the S family?

  Are you sure? yes | no