STM32L4 32kHz low speed clock - Page 1
Forum section: electronics / general

author: Veketti
author_rank: Regular Contributor
timestamp: July 09, 2021, 03:05:13 pm
content: Dear All,I was probing my PCB where I'm using STM32L4S5 MCU and found out that the LSE is not oscillating. 24MHz HSE was oscillating. That board however works just fine, so that makes me wonder how could it be possible? Is it somehow using the internal LSI instead? In the code I have initialized:Code:RCC_OscInitTypeDef RCC_OscInitStruct = {0};RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_LSE;RCC_OscInitStruct.LSEState = RCC_LSE_ON;RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;Originally I had 10pF caps for the LSE but changed them to 8.2pF when I found out that it is not oscillating. However the issue was stupid software error.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 09, 2021, 04:51:40 pm
content: Quote from: Veketti on July 09, 2021, 03:05:13 pmI don't get your question then. You're just saying it was a software error (without saying what exactly). What is your question?

author: Veketti
author_rank: Regular Contributor
timestamp: July 09, 2021, 05:14:58 pm
content: Sorry, I mean that the reason why I started scoping the PCB was in the end software error. I thought that the LSE was the issue why it didn't work but it wasn't. Problem is that the LSE is still not oscillating and the board works just fine. So I'm wondering should it oscillate as I've declared LSE to be on?

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 09, 2021, 05:36:50 pm
content: I'm not sure what "the board works fine" means exactly. The LSE oscillator is certainly not required to run code on the MCU, unless you explicitely use it as a clock source for some peripherals.

author: Veketti
author_rank: Regular Contributor
timestamp: July 09, 2021, 06:39:41 pm
content: Ok, I see. The problem is that I’m not aware when these LSE/LSI and HSE/HIS are used. I’ve just read that these STM32 do have them but no explanations are they always needed and if not, what peripherals need which. I come from simple PIC 16 world where there was just one clock either internal or external. And the external only if there was need for time critical tasks..When I jumped on this STM32 bandwagon I bought Mikroe Fusion for STM32 V8 to ease the software development. So I build the same hardware that the MCU card had, 32kHz Crystal and 24MHz crystal just to be able to test the same code with the real pcb.In this case I’m using stop mode 1 which according to the datasheet uses LSI or LSE, so I assume the 32 kHz oscillator should be working when in sleep, but it is not. But from those declarations that I’ve managed to do it is not LSI, so that makes no sense to me. Hope someone could help me to understand this?Also if there is any documentation (for dummies) to explain what peripherals need LS?Also I was googling about the LSE oscillation problem and found that it is very delicate and you need to have layout and just correct value capacitors for it to work. And there is possibility to use higher drive level if it is marginal eg. __HAL_RCC_LSEDRIVE_CONFIG(RCC_LSEDRIVE_HIGH);However this doesn’t seem to work with L4 –series. Doesn’t it have possibility to change the drive level? Or different syntax perhaps?Many things. Bare with me.. Thanks.

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 09, 2021, 06:44:18 pm
content: Ah, you'll have to read a lot about those parts then. They are a lot more complex than PIC16 MCUs. They can make use of several clock sources for core clocking and peripherals. It's almost impossible to give you a quick course of this with just a few lines. I suggest reading the datasheet first, then the reference manual.You can also read this presentation for starters:https://www.st.com/resource/en/product_training/stm32l4_system_rcc.pdf

author: emece67
author_rank: Frequent Contributor
timestamp: July 09, 2021, 08:27:38 pm
content: .

author: thm_w
author_rank: Super Contributor
timestamp: July 10, 2021, 12:13:21 am
content: Cubemx gives a reasonable overview of what the crystals are used for, although it won't include everything.

author: Veketti
author_rank: Regular Contributor
timestamp: July 10, 2021, 06:24:20 am
content: Thank you all. I've been reading.. It seems this is so advanced that it will automatically switch to internal oscillator if the external fails, causing interrupt but still working. So I assume my external LSE fails then. But what might be the cause. I've read the application note "AN2867 Oscillator design quide" but it didn't list the exact crystal I'm using and I don't have the fancy equipment to do the measurements. My Crystal isCitizen CMR200T32768DZBT6pF 50kOhms. This far I've tried 10pF and 8.2pF caps. Layout attached.C9 and C10 are the 32kHz crystal caps. Would it be capacitor, crystal or layout issue?

author: Siwastaja
author_rank: Super Contributor
timestamp: July 10, 2021, 08:48:53 am
content: Well in a usual / most typical design, a 32768Hz crystal is only used to clock the Real Time Clock peripheral (and even then, theinterfaceof that peripheral comes elsewhere like APB which is usually clocked from the same high-speed clock, internal or external, as the core).The question is, are you going to use the Real Time Clock?

author: cv007
author_rank: Frequent Contributor
timestamp: July 10, 2021, 02:22:38 pm
content: QuoteA feature you have to enable, and it generates an interrupt, but you still have to switch the clock source(s) yourself for an LSE failure.I would concentrate on RCC_BDCR, where LSE gets its marching orders. Its also possible that if LSE is not used as a source for anything, it may be turned off in low power modes, but it almost looks like LSEON always has the final say in the matter (its on when that bit is on, and if you want it off for any reason its up to you to do it).If no debugger, a simple test- if led off, no lLSERDY for some reason. If on, then LSE should be running as LSERDY was set.int main(){RCC->BDCR = (3<<3) | 1; //LSEDRV high(est), LSEONwhile( (RCC->BDCR & 2) == 0 ){} //wait for LSERDYledOn();while(1){}}What peripheral is using LSE ? If you have not set any peripheral to use the LSE, then it is unused.

author: bugnate
author_rank: Regular Contributor
timestamp: July 11, 2021, 01:48:20 am
content: Quote from: Veketti on July 09, 2021, 03:05:13 pmIt looks like you are using CubeMX generated code, right? May be helpful to post more around this area. Are you using the CubeMX given SystemClock_Config()? Are you touching anything to do with the clocks afterward? Is HAL_RCC_OscConfig() returning HAL_TIMEOUT or HAL_OK? In the default setup, a HAL_TIMEOUT would cause Error_Hanlder() and loop. It would be strange if it was getting past this init step (claiming success) and not working. This has always caught my mistakes in the past, although I haven't used L4.Are you leaving PC14 and PC15 alone (not trying to use them elsewhere)? It looks like they should be left untouched. I note that a fresh CubeMX project will __HAL_RCC_GPIOC_CLK_ENABLE() but I'm not convinced even this is necessary for the LSE.How exactly did you determine that the LSE is not working?I would suggest building a CubeMX project with nothing but LSE+RTC (make sure LSE is selected in the RTC clock mux) and see what happens.

author: cv007
author_rank: Frequent Contributor
timestamp: July 11, 2021, 05:58:09 pm
content: I have a stm32g031 (nucleo32 board), which is not very different for LSE (I presume). It seems there is a DBP bit in PWR CR1 that has to be set to allow access to the RCC BDCR register after a reset. And of course to get at the PWR registers you need rcc again.Code:RCC->APBENR1 or_eq (1<<28); //PWREN, allows writing to PWR CR1PWR->CR1 or_eq (1<<8); //DBP disable rtc domain write protection, allows writing to RCC BDCRRCC->BDCR or_eq 1; //LSEONwhile( (RCC->BDCR bitand 2) == 0 ){} //wait for LSERDY, should have a timeoutMy stm32g031 has alternate functions listed for PC14/15, which I don't think the L4 has. In this case, PC15 had AF0/AF1 as OSC32_EN and OSC_EN, but have no idea what these are and the LSERDY is set without touching the gpio config so I assume LSEON just overrides gpio.These registers are also involved in low power things ,resets, etc., and looks like it takes some reading to understand which bits survive resets and a bunch of other details.edit- I guess I should add that I have no idea what the stm32 hal is doing, but one would think its doing the above things, so the above was probably not much help, but I guess you have some registers you can now check out to see what their values are.