STM32C011. Cant run sysclk from LSI.

[SHDK2000]

Im trying to run SYSCLK from LSI on a STM32C011. But it appears as if the MCU is not running. I cant see anything in the datasheet that says the clock cant be used and it can be routed fine in the clock configurator. Am I missing something in the datasheet or does the HAL not support it?

[mƎALLEm]

Hello,

Nothing prevents you using LSI as a clock source for the system clock. From RM0490:

CubeMx:

Are you using CubeMx for the code generation or are you coding the system clock config yourself?

" But it appears as if the MCU is not running" 

-> how do you know? what are the symptoms? how you did you debug that?

How to write your question to maximize your chances to find a solution

 

[SHDK2000]

I have set the clock as shown. I have verified that I get no clock out when I use LSI. I also have a serial port configured. Again, everything works fine when using HSI as source for SYSCLK. Nothing happens when I use LSI.

 

 

[Andrew Neil]

This was in response to posts about unmarking a solution which have since been removed.

---

See:

https://community.st.com/t5/community-guidelines/help-others-to-solve-their-issues/ta-p/575256#:~:text=If%20you%20accidentally%20choose%20the%20wrong%20post%20as%20the%20solution%2C%20you%20can%20revert%20this%20action%20by%20clicking%C2%A0Not%20the%20Solution

 

PS:

See also: Unmark Solution is too hard to find.

[mfgkw]

Even when I do not understand why you want to do it...

 

What makes you believe the MCU does not run at all?

Maybe it is just really slow. LSI is ~32kHz or 0.032 MHz, while using HSI we talk about 48/n MHz.

[SHDK2000]

Why I wnat to verify, that my MCU is running? Seems obvious to me, but ok. If it doesnt run, then nothing will work. Isnt that an ok reason?

 

I use my oscilloscope to verify MCO behaviour.

 

[SHDK2000]

I have attached the ioc file. 

 

I add the following code:

while (1)
 {
	 HAL_UART_Transmit(&huart2, "Hello\n\r", 7, 1000);
	 HAL_Delay(1000);
 /* -- Sample board code for User push-button in interrupt mode ---- */

 /* USER CODE END WHILE */

 /* USER CODE BEGIN 3 */
 }

 

Works fine with HSI.
Nothing happens with LSI.

[Andrew Neil]

---

@SHDK2000 wrote:

Nothing happens with LSI.

---

You mean you don't see any UART output?

That's not the same as nothing happening !

Have you used the debugger to check that your code is actually running?

How do you check for UART output? If using a terminal, it might show nothing because the baud rate is wrong...

Have you used an oscilloscope to see if anything is coming from the UART? 

Does just toggling a GPIO pin work?

[SHDK2000]

Sorry for not clarifying.

 

I said nothing happens because i meant NOTHING happens.

 

I dont get MCO out when routing SYSCLK to the output even if I ONLY use the autogenerated code with an idle while(1) main loop. It works when I use HSI, so I know its the right pin.

I dont get UART output of any kind. When I use HSI it works.

I cant toggle a pin. When I use HSI it works.

I cant use a debugger, cause I get the message "Target is not responding, retrying...". Works when I use HSI.

 

I tried both on the NUCLEO-C031C6 board, and a board with the STM32C011, that I made myself. I cant get any response when using LSI as SYSCLK. When I use HSI, everything works fine.

[mfgkw]

Sorry for not beeing precise enough, I wonder why you want to use LSI to feed Sysclk.

[SHDK2000]

I want to use LSI to power SYSCLK to minimize current consumption.

[Andrew Neil]

Usually the best way to minimise current consumption is to maximise use of low-power modes.

So you want  the CPU to run quickly - then it can finish sooner, and sleep longer.

[mfgkw]

Maybe you look at the wrong pin for the clock signal.
DS13867 says in 3.9:

Clock output:
– MCO and MCO2 (microcontroller clock output) provides one of the internal
clocks for external use by the application.
– LSCO (low speed clock output) provides LSI or LSE in all low-power modes.

I assume LSI is not routed to MCO.

LSCO is mentioned as alternate function on Pin13 for LQFP48.

[Simon.T]

Hello, 

 

The issue might come from the systick timer. With the HAL it is configured to have an interrupt frequency of 1kHz.

When system clock is clocked by the LSI, the CPU doesn't have time to enter in the interrupt, clear it and restore the context. Therefore the MCU is locked in the interrupt. 

To have it working the systick should be disabled. 

 

Best regards,

 

Simon 

 

[SHDK2000]

---

@Simon.T wrote:

Hello, 

 

The issue might come from the systick timer. With the HAL it is configured to have an interrupt frequency of 1kHz.

When system clock is clocked by the LSI, the CPU doesn't have time to enter in the interrupt, clear it and restore the context. Therefore the MCU is locked in the interrupt. 

To have it working the systick should be disabled. 

 

Best regards,

 

Simon 

 

---

Thanks, makes sense. I will try to confirm this. 

[mƎALLEm]

Hello,

I confirm @Simon.T saying, that's due to the system tick timer.

You can test that by modifying the system tick interrupt frequency in stm32c0xx_hal.c. This is the default value i.e. 1kHz:

HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_DEFAULT; /* 1KHz */

The different definitions are available in stm32c0xx_hal.h:

typedef enum
{
 HAL_TICK_FREQ_10HZ = 100U,
 HAL_TICK_FREQ_100HZ = 10U,
 HAL_TICK_FREQ_1KHZ = 1U,
 HAL_TICK_FREQ_DEFAULT = HAL_TICK_FREQ_1KHZ
} HAL_TickFreqTypeDef;

So in your case select 100Hz or 10Hz:

HAL_TickFreqTypeDef uwTickFreq = HAL_TICK_FREQ_100HZ; /* 100Hz */

Hope that helps.

[waclawek.jan]

Write a simple loopdelay blinky with no Cube/HAL to confirm the mcu working/not working.

JW

[waclawek.jan]

> Isn't the (maximum) SWD clock rate related to the CPU clock rate ?

I don't know the debug subsystems enough, but IMO SWD as such (i.e. basically a shift register and a bunch of controlling logic) has an independent clock (from the SWD clock pin) from the system/processor.

However, it has to communicate somehow with the rest of the processor, and if the debug interface requests access to outside of the processor (e.g. to RAM or peripherals), that has to get accomplished, too, regardless of how long it may take, i.e. what's the ratio between SWD ans system clock. Again, I don't know what's the actual implementation, but I expect this to involve some sort of handshake between the processor and the processor, indicating, that the transaction requested by the debug interface has been accomplished. In other words, the debugger has to poll the SWD interface for some "ready" flag. I can't quite imagine how different clocks could be implemented otherwise. 

And, within this, I expect, the debugging host (at whichever point, i.e. either within STLink or some of the chain of software  in PC) has the ability to time out, if the transaction takes too long. And this is IMO where the "Target is not responding, retrying..." message originates.

The SWD clock rate may indirectly influence that timeout, but again, this is up to the particular debugging toolchain how are the details exactly implemented.

I may be wrong.

JW