STM32C011. Cant run sysclk from LSI.

SHDK2000 · ‎2026-01-23

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?

SHDK2000 · ‎2026-01-23

@mƎALLEm wrote:
I don't have that part number to test the case.
I will do it when I have on at hands.

Thanks.

As mentioned, this was tested on:

* NUCLEO-C031C6 board

* STM32C011 self-made board

Using autogenerated code. The following scenaros were tested individually.

* Idle While(1) loop measuring SYSCLK routed to MCO

* Endless loop toggling an IO

* UART2 transmitting "Hello\r\n"

In all scenarios, SYSCLK (or any other activity) could not be detected. Debugging was not possible, cause debugger couldnt connect to device.

I can provide complete cubeIDE projects if needed.

Simon.T · ‎2026-01-23

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

waclawek.jan · ‎2026-01-23

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

JW

SHDK2000 · ‎2026-01-23

@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.

Andrew Neil · ‎2026-01-26

@Simon.T wrote:
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.

Would that explain the debugger not connecting?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

waclawek.jan · ‎2026-01-26

We don't know which debugger, with what settings; and also generally we (as mere users) don't know enough about the details of working of individual debuggers (whatever that word exactly entails) to give a definitive judgement; but I believe in this case the debugger would time out with such system clock setting regardless of what firmware is running in the target.

JW

Andrew Neil · ‎2026-01-26

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

(or am I thinking of a different chip?)

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.

waclawek.jan · ‎2026-01-26

> 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

mƎALLEm · ‎2026-01-28

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.

To give better visibility on the answered topics, please click on "Accept as Solution" on the reply which solved your issue or answered your question.