Need clarification between clock and enable

[pierreandre]

Posted on November 08, 2013 at 10:45

Hello,

I don't understand well how the STM8L works, when enabling a module we have to enable the clock sourcing the module and then enable the module itself, that's OK.For module configuration (register access) it seems that the module has to be disabled and the clock enabled.If I want to disable a module for a while without loosing the configuration, how do I proceed?For example I enable the LCD to display a message, after some time I want to disable it to spare power. Should I: - Stop the clock (PCKEN23=0) but let the module enabled (LCD_CR3_LCDEN=1)?- Stop the clock (PCKEN23=0) and disable (LCD_CR3_LCDEN=0)? - Or let the clock (PCKEN23=1) and disable (LCD_CR3_LCDEN=0)?This is the same question for all module, which is the global principle for the STM8L?Hoping someone will help me;)

[fggnrc2]

Posted on November 08, 2013 at 13:36

Argail,

I ignore the implementation details of each module. I however tell what experience taught me. Every module works if it's enabled and a clock signal is applied to it. If you disable a module, you disconnect its inputs and outpus from the microcontroller pins. Some modules are enabled/disabled through their power supply, but their configuration registers should keep their value, i.e. they can be used as a RAM if the code can read and write all their bits. When you remove their clock signal, they freeze and the power they draw decreases. As regards peripheral module power consumption, it's alike to the core power saving modes: An enabled and clocked module is alike to a running core. An enabled, but unclocked module is alike to a waiting core. A disabled and clocked module is alike to a stopped core. A disabled and unclocked module is alike to a powered down core. If a module must save as power as possible, it should be disabled and unclocked. As you already know (I saw your other post), a disabled module doesn't drive its outputs, so your code must set the outputs to the values that your application expects. Regards, EtaPhi

[pierreandre]

Posted on November 08, 2013 at 15:59

Dear EtaPhi,

Thank you for your message and neat explanation, the things began to be clear (clearer at least:)) for me.I was coming crazy because I didn't know that the pin configuration was not saved and I was confused.There is some great features in those devices, I was playing with WFE and WFI today;) I'm only a bit sad there is not UFQFN48 with hardware AES.

[fggnrc2]

Posted on November 08, 2013 at 17:01

Dear Argail,

I give you a bit of advice: WFI and WFE instructions make debugging very difficult (sometimes it's impossible). The symptom of these debugging troubles is an ''unable to connect to the device'' error. I suppose that this happens because the SWIM hardware is sleeping too when the core executes a WFI / WFE instruction. For this reason, the debugging interface of an IDE gets no answer to its requests until the core and the SWIM interface restart their normal operation. I only use WFI or WFE instructions in the release version of my projects. I usually exclude them from the debug version by using the pre-processor instructions #ifdef #endif. EtaPhi

[pierreandre]

Posted on November 11, 2013 at 16:20

Thank for this information, ready to hear any other;)