STM8L050J3 Bug?

[Sisto Zànier]

Hi,

I am experiencing a serious problem with STM8L050J3.

Due to an unused pin configuration of port A (PA1..PA7) then excluding PA0 used as SWIM, in order to check for any difference in current consumption, I have configured Port A with the following command:

GPIO_Init(GPIOA, GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_4|GPIO_Pin_5|GPIO_Pin_6|GPIO_Pin_7, GPIO_Mode_Out_PP_Low_Slow);

As a result, the firmware uploaded now does not run, and it is no longer possible to access it with ST-LINK V2, neither for debugging nor for programming.

Since the RESET pin is missing on this micro, there is no way to reset this situation and recover the functionality of the micro, which is otherwise no longer usable.

Any suggestions for solving this?

Thank you for your attention.

Translated with www.DeepL.com/Translator (free version)

[Tesla DeLorean]

Perhaps have a small delay after power on or recognize some pin pattern before using pin settings that might block debugger/programmer interactions.​

[Sisto Zànier]

Hi again,

I would agree with you if you were to use PA0 as I/O, but in my case I don't have this need, and I have configured pins PA1 to PA7 in Push-Pull Output Low mode for exploratory purposes only for current consumption, so I don't understand how this caused the SWIM pin, which is on PA0, to be blocked. In this situation, even having modified the firmware by adding a small power-on delay, I can no longer download it to the micro's flash, because I no longer have access with the ST-Link V2 and I have no way of resolving the issue other than by replacing the micro on my board.

[Tesla DeLorean]

Package pins are bonded to multiple chip level IO-Cells, you can configure one of those as an Output, or they will fight, and block secondary usage

[Cristian Gyorgy]

Hi!

what you experience is no bug, PA0 is tied up on the same physical metal pin with PA2 and PC6. So,if you configured PA2 as output, the SWIM will not work anymore. Pls. see datasheet.

So yes, solder a new chip and read the datasheet carefully before commiting to programming.

Good byte!

[Sisto Zànier]

Hi Cristian,

thanks for the support!...Indeed, looking better at the DS especially the part of "Pin Description and Tables 3 and 4�?, I saw that some pins of the micro STM8L050J3 are internally connected together and therefore can not be considered disjointed and configure them independently as it happens for different models of STM8Lxx.

Therefore, in order to avoid making other micros unusable during debugging, for the purpose of limiting current consumption, I decided to configure the unused I/Os as per the listing below:

---

// STM8L050J3

void GPIO_LOW_POWER_CONFIG(void)

{

// Configure unused pins as output push-pull 0 to enter low power

// Port A: PA3 used as I/O only

GPIO_Init(GPIOA, GPIO_Pin_1|GPIO_Pin_4|GPIO_Pin_5|GPIO_Pin_7, GPIO_Mode_Out_PP_Low_Slow);

// Port B: PB3 used as AIN15, PB6 as AIN12, PB7 as Output PP

GPIO_Init(GPIOB, GPIO_Pin_0|GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_4, GPIO_Mode_Out_PP_Low_Slow);

// Port C: PC4 used as Output HiZ or PP

GPIO_Init(GPIOC, GPIO_Pin_1|GPIO_Pin_2|GPIO_Pin_3|GPIO_Pin_7, GPIO_Mode_Out_PP_Low_Slow);

// Port D

// Unused

// Port E ??

GPIO_Init(GPIOE, GPIO_Pin_All, GPIO_Mode_Out_PP_Low_Slow);

// Port F ??

GPIO_Init(GPIOF, GPIO_Pin_All, GPIO_Mode_Out_PP_Low_Slow);

}

However, it is not clear to me whether ports E and F exist on the chip and therefore I can configure them as PP Output or I can ignore them.

Please have a look and confirm that this is OK, and thanks again

Sisto

[Cristian Gyorgy]

Hi! Sorry I could not answer you earlier, but I don't log in as often anymore.

No, Port E and F are not implemented in STM8L050, so you don't have to configure them.

[Sisto Zànier]

No problem Cristian and I thank you anyway.

In my project, which is powered by a CR2450 battery, it is imperative to consume as little power as possible and therefore I use the Active-Halt function with wake-up from RTC for functions that can be switched off for short periods of time.

However given the lack of the RESET pin and consequently the impossibility of debugging with the Active-Halt mode, for a customer verification on 5 prototypes, I will complete the debugging using the NUCLEO-STM8L152R8 board configured to use the same firmware for the STM8L050J3, but for production I have decided to use the STM8L151F3Ux later for the same project.

In this way, albeit with some limitations, I will be able to make changes and then reprogram the chips even with the Active-Halt mode, without the risk of no longer being able to access the micro for reprogramming.

Sisto

[Thomas G]

This kind of optimization is better done with an STM8L051F3P6 (which is the same silicon). The time spent for trying to revive a chip (or even to create a "bug thread" ;) ) is better spent on making a breadboard test.

I can also recommend doing such tests with an interactive system. STM8 eForth is stable, free, open source, and it can be used in active halt.

[Sisto Zànier]

Hi Thomas, 

actually considering SWIM vs HALT this 'limitation', in the end I decided to use the STM8L051F3P6 with the TSSOP20 package, which also has the RESET pin and thus, in Active_Halt mode, allows the chips to be reprogrammed even for a FW update.

However, it remains problematic to debug in real time, with Active Halt mode, using STVD (v.4.3.12) and Cosmic "C" Coss-Compiler, because there are some communication difficulties that cause SWIM disconnection. 

As described above, for Active-Halt mode I use RTC configured for a wake-up from the HALT state, every 8mS (activities with micro in RUN last about 2mS).

However, by taking IDD current measurements, I am finding that in HALT-MODE, the absorption of my system, even physically disconnecting the HF part, is about 700uA, which I still consider excessive for use with a CR2450 battery. I am probably doing something wrong in the I/O configuration (I attach the diagram of my small project for your opinion on this). 

I am not familiar with the STM8 eForth environment and will look on GitHub to see what it is and whether it might facilitate me for projects with these small micros.

Thanks for the support; your comments are appreciated.

Sisto

[Thomas G]

Hi Sisto,

I assume that your new circuit (with an STM8L051F3P6) uses the 38kHz LSI as the RTC clock (the WUT is a bit easier to use). In Active Halt mode the current consumption should be much lower.

I've never used the STVD or the Cosmic compiler (my projects are all based on the SDCC tool chain). STM8 eForth gives the programmer full control of the chip, for the better or the worse (i.e., you know what you're doing, and there is no one else to blame).

Communicating with an STM8L chip through the serial interface uses a few tricks, e.g., waking up from Active Halt with an external interrupt from the pin that's configured as USART_RxD. That way it's possible to reconfigure GPIOs by interactive command entry.

If you're interested, setting up a test system isn't hard. It's easiest using Linux - but programming the Forth system to the chip any serial terminal with a standard "TTL" serial interface will be sufficient for an interactive session. You'll find a binary here (stm8ef-bin.zip) and some guidance for the STM8L051F3P6 here. An introduction to using Forth on the STM8 is here.