2016-08-24 12:45 PM
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
2016-08-25 01:55 PM
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,Elwood2016-08-25 01:55 PM
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 PLLYes, 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.2016-08-25 02:02 PM
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();
}
2016-08-25 02:42 PM
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,Elwoodecd-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;
2016-08-26 08:34 AM
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.
2016-08-26 09:47 AM
Hi Mayla,
Thank you for your attention to this. The support ticket I posted is number TECH022706.Regards,Elwood2016-08-26 11:22 AM
Thank you for your generous support.
2016-09-06 07:48 AM
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=false2016-10-10 12:59 PM
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.2016-10-31 07:51 AM
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.