Issues working with STM8L051 (flash endurance?)

[rhodges]

I have been working with STM8S (-003, -103, -105) for a while, and recently got interested in the low power STM8L051. So I bought 10 on ebay. (First mistake? They look legit.)

My first task was "blinky". Just set up the GPIO pins and turn an LED on and off, with two simple for() loops for delay. I got that working.

Next is to bring in my "board" libary, which does the CPU frequency setup, GPIO, and a generic LED on/off function. I tested it for the CPU frequencies from 16mhz down to 125khz. So far, so good, the LED blink times seem to go with CPU frequency.

Then I want to bring in my TIMER4 clock library from STM8S, which uses an interrupt and gives millisecond and 1/10 second callbacks. Now I want to test the frequencies again. And that looks good.

Next, I want to start working with the Low Speed External oscillator. I grab an unmarked resonator that "looks" like a 32.768khz...
And after many tries with the register settings, I give up for a bit to do something else.

Around that point, my blinking CPU starts acting strangely. The blinking changes, sometimes going extremely fast, sometimes off for random periods. I tried flashing a "known working" image, but now STM8FLASH program gives me errors. I can read back, or write to the option bytes.

Interesting note: Before I could write to the CPU, I had to clear the read/write protection using "stm8flash -u". The datasheet says that the protection is disabled by factory default. Did I get already programmed and protected chips?

I give up on this CPU and solder a new one on a breakout board. This is my first time at soldering 0.65 pitch TSSOP, so maybe my first soldering job was "almost good enough"?

The new CPU seems fine. For a while. Then it starts acting badly. And it gives errors when trying to program the flash almost all the time. But not always. But the chip will not behave properly any more.

I have never had any serious flash problem with the STM8S103, and they advertise 10,000 cycles, so I have no problem re-writing new code constantly to them. Is the STM8L051 any different? On the first page of the datasheet, they make no claim about the flash endurance. So down in 8.3.5 "memory characteristics", I see...

100 cycles.

Damn.

"history | grep stm8flash | less" gives me hundreds, in the two days I have been playing with these chips. Damn. This is my typical workflow... I guess I should buy a lot of spares if they are going to die on me after a hundred cycles.

I soldered my third chip on a breakout board, flashed "blinky" on it, and it has been working perfectly for more than  a day. It is in front of my monitor, so I get to watch it a lot.

Question #1: Do the failures I saw point to a problem with flash endurance? Or should I keep looking for another explanation?

Question #2: Should I start exploring the idea of putting only stable code in flash, and create a special area of RAM for my current code? I would probably have to make a special loader for the RAM code.

Question #3: Has anyone come up with a better solution?

Thanks!

[HwAoRrDk]

Interesting note: Before I could write to the CPU, I had to clear the read/write protection using "stm8flash -u". The datasheet says that the protection is disabled by factory default. Did I get already programmed and protected chips?

I have seen this mentioned before - I can't remember if it was here on some blog or another. Generic STM8 breakout boards (similar in nature to the STM32 "blue pill") purchased from eBay/AliExpress/etc that came with chips that already had the write protection set.

I have never had any serious flash problem with the STM8S103, and they advertise 10,000 cycles, so I have no problem re-writing new code constantly to them. Is the STM8L051 any different? On the first page of the datasheet, they make no claim about the flash endurance. So down in 8.3.5 "memory characteristics", I see...

100 cycles.

Yes, it is kind of annoying that all of the STM8S00x series have such a low number of flash write/erase cycles. I wonder what it is about the flash that makes them have such limited durability?

Question #2: Should I start exploring the idea of putting only stable code in flash, and create a special area of RAM for my current code? I would probably have to make a special loader for the RAM code.

Hmm, you're not going to fit much code in 1K of RAM. I know you can use stm8flash to write to arbitrary locations in the RAM, but then does the contents of RAM persist through a reset? And you'd have to ensure that the flash code that inits .bss and .data memory doesn't overwrite any of the code. Maybe use the --data-loc linker option of SDCC to tell it that RAM starts at, say, 0x100, rather than 0x0. Or maybe a custom serial bootloader compatible with the standard protocol (used by stm8gal) that all it does is write to the special RAM area and then jumps execution to that location.

[rhodges]

I have seen this mentioned before - I can't remember if it was here on some blog or another. Generic STM8 breakout boards (similar in nature to the STM32 "blue pill") purchased from eBay/AliExpress/etc that came with chips that already had the write protection set.

Yes, their "blinky" code must be SO precious to them.

Yes, it is kind of annoying that all of the STM8S00x series have such a low number of flash write/erase cycles. I wonder what it is about the flash that makes them have such limited durability?

I don't know about the -003. I used that chip as part of my "w1209" library and never had an issue with flash endurance.
On the STM8L051, I can only guess. Maybe the lower voltage and lower current specs push the chip to less flash endurance?

Hmm, you're not going to fit much code in 1K of RAM.

Yes, that is why I was thinking of leaving stable code in flash while doing the debugging cycle in RAM.

...but then does the contents of RAM persist through a reset? And you'd have to ensure that the flash code that inits .bss and .data memory doesn't overwrite any of the code. Maybe use the --data-loc linker option of SDCC to tell it that RAM starts at, say, 0x100, rather than 0x0. Or maybe a custom serial bootloader compatible with the standard protocol (used by stm8gal) that all it does is write to the special RAM area and then jumps execution to that location.

I will read the init code again to be sure, but I think it loads in the constant data, then clears the rest. There is no stack usage at init, so it probably goes all the way to wherever SP is (which is initialized in reset.)

I guess I am lucky that I already have a good body of debugged code for STM8Sxxx. But the STM8L051 DMA, low voltage sensing, and Real Time Clock look really nice and I would like to make some solid libraries for them. And my work cycle on STM8 involves a lot of small changes and verifications. Yes, I am used to it being so easy now. Decades ago, I had to write new code, burn it to an EPROM, remove the old EPROM, erase the old EPROM, etc. And the EPROMs had a life too. Today, 10,000 flash cycles has made me complacent.

As Joe Walsh sang, "I can't complain, but sometimes I still do..."