cancel
Showing results for 
Search instead for 
Did you mean: 

CubeMX can not set speeds above 32 MHz on NUCLEO F446ZE

Elwood Downey
Associate III
Posted on August 24, 2016 at 21:45

I have NUCLEO F446ZE, STM32CubeMX version 4.0 on Mac OS X 6. When I set the HCLK to 8, 16 or 32 MHz my program runs fine, but anything faster and it does not run at all. For this exercise my program is just one line:

while(1)
{
HAL_GPIO_TogglePin(GPIOB, LD2_Pin);
}

I put a scope probe on CN1 21 (PB_7 for LED2). When I set HCLK to 8 MHz, I see the square wave period is 4.68 usec; at 16 MHz it is 2.32; at 32 MHz it is 1.16, all fine. But anything higher and the pin does not change state at all, it just stays low. Any suggestions would be welcome. My project chose the F446 in part because it should be able to go up to 180 MHz so I hope this is possible. Cube does say ''180 MHz max'' below the speed setting box so it should be possible. Thanks much for any ideas. Elwood Downey Steward Observatory University of Arizona #cube-mhz-f446
20 REPLIES 20
Elwood Downey
Associate III
Posted on August 25, 2016 at 22:55

Also, could you please comment on why you think the HAL clock inquiry functions are returning values 2x those specified in the Cube? Are you proposing this is also a toolchain issue? It seems noteworthy the program fails exactly when the 2x HCLK value reaches the magic 180 MHz limit. 

Regards,

Elwood

Posted on August 25, 2016 at 22:55

Per my profile, I don't work for ST, I'm also not a huge fan of the Cube/HAL stuff.

The screenshot suggests it is defining HSI as ''8'' which is definitely wrong, as it clocks at 16 MHz. And the PLL comparison frequency needs to be between 1 and 2 MHz. The NUCLEO boards provide an 8 MHz HSE source, you might want to use that as the clock source into the PLL

Yes, looks to be a Cube bug, and could be remedied by gaming the settings in the dialog, or modifying the output code. Someone from that coding group would need to pick this up.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Posted on August 25, 2016 at 23:02

You'd want to check the code configuring the clocks.

/* Enable HSI Oscillator and activate PLL with HSI as source */
RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI;
RCC_OscInitStruct.HSIState = RCC_HSI_ON;
RCC_OscInitStruct.HSICalibrationValue = 0x10;
RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSI; // 16 MHz
RCC_OscInitStruct.PLL.PLLM = 16; // HSI/16 = 1 MHz
RCC_OscInitStruct.PLL.PLLN = 360; // 360 x 1 = 360 MHz
RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2; // 360/2 = 180 MHz
RCC_OscInitStruct.PLL.PLLQ = 7;
if(HAL_RCC_OscConfig(&RCC_OscInitStruct) != HAL_OK)
{
Error_Handler();
}
/* Select PLL as system clock source and configure the HCLK, PCLK1 and PCLK2
clocks dividers */
RCC_ClkInitStruct.ClockType = (RCC_CLOCKTYPE_SYSCLK | RCC_CLOCKTYPE_HCLK | RCC_CLOCKTYPE_PCLK1 | RCC_CLOCKTYPE_PCLK2);
RCC_ClkInitStruct.SYSCLKSource = RCC_SYSCLKSOURCE_PLLCLK;
RCC_ClkInitStruct.AHBCLKDivider = RCC_SYSCLK_DIV1; // 180 MHz
RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4; // 45 MHz
RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2; // 90 MHz
if(HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5) != HAL_OK)
{
Error_Handler();
}

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Elwood Downey
Associate III
Posted on August 25, 2016 at 23:42

Thank you, sir. After making the following changes the program is running. I will do further study on the purpose of these values but it appears this is the heart of the problem. I have posted a query over on the official STM support page for this topic.

Thank you again for your time. While I have been browsing many older forum posts I have seen your handle on so many over several yeas I just assumed you must be a valued employee of STM. Now I see from your profile your kindness in helping others from your vast experience is most extraordinary.

All the best,

Elwood

ecd-mbpr: diff -wb main-cube.c main-fixed.c 

116,117c116,117

<   RCC_OscInitStruct.PLL.PLLM = 4;

<   RCC_OscInitStruct.PLL.PLLN = 180;

---

>   RCC_OscInitStruct.PLL.PLLM = 16;

>   RCC_OscInitStruct.PLL.PLLN = 360;

119,120c119,120

<   RCC_OscInitStruct.PLL.PLLQ = 2;

<   RCC_OscInitStruct.PLL.PLLR = 2;

---

>   RCC_OscInitStruct.PLL.PLLQ = 7;

>   RCC_OscInitStruct.PLL.PLLR = 7;

Amel NASRI
ST Employee
Posted on August 26, 2016 at 17:34

Hi downey.elwood,

The highlighted issue about the wrong HSI value is reported internally.

Could you please let me know the ticket ID?

-Mayla-

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.

Elwood Downey
Associate III
Posted on August 26, 2016 at 18:47

Hi Mayla,

Thank you for your attention to this. The support ticket I posted is number TECH022706.

Regards,

Elwood

Posted on August 26, 2016 at 20:22

Thank you for your generous support.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
stm32cube-t
Senior III
Posted on September 06, 2016 at 16:48

Dear user,

Please find Attached STM32CubeMX 4.16 nucleoclock tree for 180 MHz using HSI+PLL (and5 Flash wait states).

Please let us know if you still encounter an issue.

Thanks

________________

Attachments :

Capture.PNG : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htgd&d=%2Fa%2F0X0000000aVk%2FGMT_hW2rT3bzR9_VFnc1TnbYZfVMOcd5hdq4zIIdeU0&asPdf=false
Elwood Downey
Associate III
Posted on October 10, 2016 at 21:59

The ticket seems to have gone stale, no comments from STM since late August. The bug in Cube has been reproduced and a work-around established but I was hoping to see a path to a real fix. Also hoping to get a response to my question about correct power predictions in Cube when the bug is in play.

Edited Oct 26: I just tried CubeMX 4.17.0 and it is still generating incorrect clocks. And still no traffic on my TECH request. Sorry to say, but this company seems to not care about this at all. I marked by original TECH post as Critical when I posted in August, now 2 months later the only reason I am up and running is because of the generosity of a fellow user on here. 

Amel NASRI
ST Employee
Posted on October 31, 2016 at 15:51

Hi downey.elwood,

The CubeMX bug is highlighted internally -again- as it seems to be a regression issue after being fixed in version 4.16.

Sorry for such inconvenience.

-Mayla-

Edit: I've just made the test and checked that the HSI_VALUE is set to 16 MHz in the file stm32f4xx_hal_conf.h. So the error is only related to wizard display.

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.