STM32 G0B1KEU6: Using LSI as clock source

[KarineBlier]

I am trying to use the LSI as the clock source on the STM32 G0B1KEU6. It doesn't work, and as soon as I select the LSI in the MUX on the clock tree, my code stops working. To ensure there are no other sources of error, I used the exact same code but with the HSI selected for SYSCLK. Below are the main source files generated by Cube IDE for when LSI is selected and for when HSI is selected (I attached files to this ticket). I also ran a diff to provide more detailed insights and help pinpoint the issue.

Here’s what happens when I try to use the LSI:
First, when I simply download the program to the STM32 without using debug mode, I get the exact same output in the console.

Then, to understand where the code fails, I enter debug mode and step through the code line by line. Here’s where it fails:

The issue occurs at line 907, which I believe is where the code selects the LSI as the SYSCLK source.

All the code is entirely generated by CubeIDE, except for the parts where I set and clear the debug pins and inside the while(1) loop.

So my question is: how do you configure the LSI as the SYSCLK source, and why is Cube IDE generating code that doesn’t work? Did I miss something?

Thank you for your help


Karine

 

[STOne-32]

Dear @KarineBlier ,

 

Can you give more details on this “It doesn't work, and as soon as I select the LSI in the MUX on the clock tree, my code stops working”

 

Can you as exemple have a LED toggling or see to output LSI on MCO pin using an oscilloscope .  Disconnect your debug Probe from the system ( SWD) or ST-link , Power off and power On the device . It may happen is only a configuration of the debug with a higher speed frequency in range of MHz not able to synchronize with SYSCLK running at 32KHz .

Hope it helps 

STOne-32

[KarineBlier]

Hi STOne-32,

 

---

@STOne-32 wrote:

Can you give more details on this “It doesn't work, and as soon as I select the LSI in the MUX on the clock tree, my code stops working”

In debug mode:

The code gets stuck in the clock initialization function. As soon as the LSI output is selected on the MUX in the SystemClock_Init() function (see photos in the description), the ST programmer seems unable to communicate with the chip (this is a hypothesis). The behavior is that Cube IDE exits debug mode (the play/pause buttons become unavailable) and the console repeatedly shows :

“Target is not responding, retrying...”

before eventually displaying (see the photos in the bug description) :

“Failed to read registers from target” 
“Shutting down ...” 
“Exit .” 

Here is the way I select the LSI on the MUX (AHB and APB prescalers are set to 1) :

Without debug mode: There is no activity on the debug pins (see below for more details).

 

---

@STOne-32 wrote:

Can you as exemple have a LED toggling or see to output LSI on MCO pin using an oscilloscope . 

---

I set and clear a debug pin in the main function as well as in the IRQ handler of the RTC wakeup timer, and I monitor the activity on these pins using the Saleae:

Debug pin are initialized in the MX_GPIO_Init function (See in the attached files of the description of the bug).

 

When the LSI is used as the SYSCLK clock source, I experience the behavior described earlier in my response, and there is no activity on the debug pins. When I use the HSI as SYSCLK, here’s the behavior I observe on the debug pins:

The clock source for the wakeup timer is still the LSI. To confirm that the wakeup timer is indeed connected to the LSI, I configured the timer to generate an IRQ every 100 ms. The counter is set to 200, assuming a 32kHz clock with a divider of 16.

Here is how I made the math :

In the Saleae, we can clearly see that an IRQ is generated by the wakeup timer every 100 ms (Debug Pin 2 (PC6)), which proves that the LSI is functioning properly.

 

---

@STOne-32 wrote:

Disconnect your debug Probe from the system ( SWD) or ST-link , Power off and power On the device . It may happen is only a configuration of the debug with a higher speed frequency in range of MHz not able to synchronize with SYSCLK running at 32KHz .

---

I tried flashing the board both without debug mode and with debug mode using Cube IDE (I used the play button instead of the bug icon for normal flashing, and the bug icon for debugging).

The behavior is exactly the same. The console shows:

I physically disconnect the ST Link programmer, reset the board, and there is still no activity on the debug pins.

I also tried using STM32 Programmer to flash the board with the .elf file:

When I disconnect (in STM32 Programmer), physically remove the ST Link programmer, and power cycle the board, there is still no activity on the debug pins.


How to reproduce the bug :

1. Start an STM32 project with the MCU STM32 G0B1KEU6.

2. Select the LSI as the clock source for the SYSCLK (see picture above).

3. Configure 2 GPIOs as outputs for debug pins (I used PB5 and PC6).

4. Configure the RTC wake-up timer to generate an IRQ every 100 ms with a wake-up clock of RTC/16.

(32kHz /16 = 2kHz)

5. Set and clear one debug pin in the while(1) loop and toggle the second debug pin in the RTC wake-up timer IRQ handler.

There will be no activity on the debug pins, and the code won't run.

7. Try the exact same setup but with the HSI as the clock source for the SYSCLK instead of the LSI, and monitor the debug pins.

 

[KarineBlier]

Update 23 october 4hours later :

An alternative would have been to connect to the LSE. So, I ordered a NUCLEO-G0B1RE to run additional tests.

First test: Validate the functionality and general code by connecting to the HSI, which should work. (SUCCESS)

I start a new STM32 project, and using the board selector, I choose the NUCLEO-G0B1RE. To validate that I’m connected to the correct pins and that my project is set up correctly, I configure the SYSCLK MUX to the HSI, the RTC to the LSI, the wakeup timer (exactly as explained earlier, with a frequency of 100 ms connected to the RTC/16), and the GPIOs PC10 and PC12 as outputs on connector CN7. I toggle debug pin 1 in the main loop and toggle debug pin 2 in the IRQ handler of the wakeup timer. Using a Saleae logic analyzer, I can confirm that the frequency entering the IRQ handler of the wakeup timer is indeed every 100 ms, and I see debug pin 1 toggling.

 

Second test: Attempt to use LSI as SYSCLK source (FAILED)

Using the exact same code, I selected LSI as the SYSCLK source in STM32 Cube IDE's clock tree, saved, and regenerated the code (with AHB and APB prescalers set to 1). The code appears to get stuck in the SysTickHandler, though the tick value continues to increment. However, there is no activity on the GPIOs configured as outputs.

Here is the call stack (it’s the same every time I pause and play, no matter how many times I try):

I attempted to locate the clock source for SysTick but couldn't find it. From what I understand, it must be the SYSCLK. I also tried flashing the board and resetting it, but there was still no activity on the debug pins.

 

Third test: Attempt to use LSE as an alternative to LSI (FAILED)

Using the exact same code, I selected LSE as the SYSCLK source in the clock tree of STM32 Cube IDE, saved, and regenerated the code (again with AHB and APB prescalers set to 1). The behavior was identical to when SYSCLK was connected to LSI. There was no activity on the debug pins, and the code seemed to be stuck in the SysTick_Handler, with the call stack unchanged regardless of play/pause actions.

 

More specifically, the code gets stuck in the SystemClock_Config function in the main, at HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0) != HAL_OK) within SystemClock_Config, and at HAL_InitTick(uwTickPrio) within HAL_RCC_ClockConfig, and finally at HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority, 0U) (see the call stack in the second test).

 

Again, did I miss something ?

 

Thank you for your help

 

Karine

[STOne-32]

Dear @KarineBlier ,

 

Can you please go the sources file : stm32g0xx_hal.c

then inside the function

__weak HAL_StatusTypeDef HAL_InitTick(uint32_t TickPriority)
{
HAL_StatusTypeDef status = HAL_OK;

/* Check uwTickFreq for MisraC 2012 (even if uwTickFreq is a enum type that doesn't take the value zero)*/
if ((uint32_t)uwTickFreq != 0U)
{
/*Configure the SysTick to have interrupt in 1ms time basis*/
if (HAL_SYSTICK_Config(SystemCoreClock / (1000U /(uint32_t)uwTickFreq)) == 0U)
{
/* Configure the SysTick IRQ priority */
if (TickPriority < (1UL << __NVIC_PRIO_BITS))
{
HAL_NVIC_SetPriority(SysTick_IRQn, TickPriority, 0U);
uwTickPrio = TickPriority;
}

 

Please comment it out the 1000U value and put instead 1U or even comment out all the function.   It seems the the calculation is based on MHz range and so divided by 1000.   and let us know if it helps ?  

Hypothesis : Systick seems using 1ms time base based on this formula which will not work if the frequency in KHz ranges like LSI or LSE.

Ciao

STOne-32.

 

[KarineBlier]

Hi @STOne-32 

The solution doesn’t work. I still can’t use the LSI as the SYSCLK.

Did you try the solution with the Cube IDE ? Is it working for you ?

 

 

Thank you

Karine

 

 

 

[STOne-32]

Hi @KarineBlier ,

Yes, it is working for me using CubeIDE.  you may debug step by step your code with breakpoints and step on the "tick" configuration .  another alternative also to put in breakpoint inside the "Systick" IRQ - interrupt and see if you hit it ?

Ciao

STOne-32.