STM32L051C6T6 MSI clock range problem

[tomasz_matuska]

Posted on June 02, 2015 at 00:55

Hello!

I have a problem with MSI clock configuration on STM32L051C6T6. I wanted to test my device with this microcontroller and I generated a simple code for Keil MDK v5 (LED blinking and USART transmission) using a CubeMX tool. CubeMX generated SystemClock_Config function, that should set a MSI clock speed (range) at 536 kHz (listed below). But when I run the program, microcontroller does not work and everything seems to be dead. When I debugged the code, it get stucked at the macro that writes the value of the clock speed to the registers and Keil showed error Internal Communication Error. When I changed MSI clock speed to 072 kHz it works fine, but debug still get stucked at the same line as before. When I changed MSI clock speed to 144 kHz, code and debug work just fine. I double checked the code generated by CubeMX with all documents from ST website. Can somebody please explain me why the lower speeds do not work? Maybe I did something wrong? Please help me with my problem. Function generated by CubeMX

void SystemClock_Config(void)
{
RCC_OscInitTypeDef RCC_OscInitStruct;
RCC_ClkInitTypeDef RCC_ClkInitStruct;
__PWR_CLK_ENABLE();
__HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE3);
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_MSI;
RCC_OscInitStruct.MSIState = RCC_MSI_ON;
RCC_OscInitStruct.MSICalibrationValue = 0;
RCC_OscInitStruct.MSIClockRange = RCC_MSIRANGE_0;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_NONE;
HAL_RCC_OscConfig(&RCC_OscInitStruct);
RCC_ClkInitStruct.ClockType = RCC_CLOCKTYPE_SYSCLK;
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_MSI;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1;
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV1;
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV1;
HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0);
__SYSCFG_CLK_ENABLE();
}

#stm32l #clock-configuration #msi

[waclawek.jan]

Posted on June 03, 2015 at 14:05

Isn't there a timeout kicking in while setting the new clock? I am not goint to touch Cube with a stick; OTOH you can set the clock manually.

Debugging at low clock might be a no-go, as some debug adapters simply time out internally when waiting for response from the core. You can ''achieve'' the same setting a high AHB divider at a relatively high clock. You might want to explore if your debug adapter/debug software allows to manipulate such timeout.

JW

[tomasz_matuska]

Posted on June 03, 2015 at 19:26

Thank you for your reply. About the debugging it may be a point, I'm going to check it. But why the program does not work in a normal run mode with 65 kHz clock (with 131 kHz works fine) ?

[waclawek.jan]

Posted on June 03, 2015 at 19:37

Did the program get beyond

HAL_RCC_ClockConfig

()? (checked e.g. through lighting up a LED at that point). If not, the culprit is there. If yes, it's in your application. Did you try to set the clock directly writing into the registers, avoiding the function call? JW

[tomasz_matuska]

Posted on June 04, 2015 at 16:32

No, the code did not get beyond

HAL_RCC_ClockConfig

(), it stucked at one of the macros inside that function (the one which writes clock range into a particular register). I am aware that the issue is there. The thing is I do not know what is going on. Writing the value manually did not change the behavior of the program.

[waclawek.jan]

Posted on June 04, 2015 at 16:51

So do I understand it correctly - you wrote a program which reads RCC_ICSCR, masks MSIRANGE[2:0] to zero and writes it back to RCC_ICSCR - and the program won't get beyond that write, confirmed by lighting up a LED just after that?

JW

[Tesla DeLorean]

Posted on June 04, 2015 at 18:33

May be you need to consider alternative measures to ''debug'' at this speed?

https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/Flat.aspx?RootFolder=https://my.st.com/public/STe2ecommunities/mcu/Lists/STM32Discovery/ST-Link%20not%20working%20after%20sysclk%20is%20lowered&FolderCTID=0x01200200770978C69A1141439FE559EB459D75800084C20D8867EAD444A5987D47BE638E0F&currentviews=86

[tomasz_matuska]

Posted on June 04, 2015 at 19:48

Not exactly. I wrote a program that writes 000 (65kHz) or 001 (131kHz) to MSIRANGE[2:0] of RCC_ICSCR. Program does not get beyond that point - no LED is lighted up (but it should when everything is allright).

[waclawek.jan]

Posted on June 04, 2015 at 19:54

What is the system clock at that moment?

Post the content of RCC registers just before the instruction which performs the write, and the value which is going to be written (single-step in disassembler just before that write). I have a L0-DISCOVERY and I'd try to reproduce your problem - it's based on 'L053 but that should not be an issue IMO.

JW

[tomasz_matuska]

Posted on June 04, 2015 at 21:14

The value of

RCC_ICSCR 

before a write is 0x0000B000.

The value to be written is 0x00000000 (for 65kHz) or 0x00002000 (for 131 kHz).

I can not tell you any more info, because I do not have access to the board at the moment. Please try the values of RCC_ICSCR on your microcontroller, I will post the rest at monday.

[tomasz_matuska]

Posted on June 04, 2015 at 21:25

Sorry for double post. 

I think the rest of the values of the registers are OK since setting higher clock speeds works fine. I am only changing those MSIRANGE bits.