CubeMX can not set speeds above 32 MHz on NUCLEO F446ZE

[Elwood Downey]

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

[Tesla DeLorean]

Posted on August 24, 2016 at 22:03

They are capable of going at 180 MHz, I would look at what the Flash Wait states are set to in the generated code.

[Elwood Downey]

Posted on August 24, 2016 at 22:28

Thanks for the fast reply. Good idea but Cube does generate SystemClock_Config() which includes this line which seems to take care of it:

HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0)

I added some print statements and discovered that when Cube is set for HCLK 32 then HAL_RCC_GetHCLKFreq() returns 64000000 and HAL_RCC_GetSysClockFreq() returns 128000000. I was able to eek HCLK up to 40 MHz at which point SysClock returned 160000000. So I'm thinking any higher and it reaches 180 and it gags.

[Tesla DeLorean]

Posted on August 25, 2016 at 00:47

0WS isn't going to get you beyond 32 MHz, you'd want 5WS at 168-180 MHz

[Elwood Downey]

Posted on August 25, 2016 at 16:59

Hi clive1,

My mistake, Cube did set it to LATENCY_5, I was getting confused with my several little test files.But the main issue remains: program will not run if HCLK is set higher than about 40 in Cube. And I confirmed HAL_RCC_GetHCLKFreq really does return 64 when set to 32 in Cube so it seems like that might be a clue.Thanks.

[Tesla DeLorean]

Posted on August 25, 2016 at 20:47

Debugging this through the keyhole is going to be too much work, suggest you review exactly what Cube is outputting, how it actually configures the clocks and how it performs if you single step the initialization code in a debugger.

You'd need to provide .IOC and output for someone in the HAL/Cube group to review/recreate. Attached is a .HEX running the F446 at 180 MHz, outputting clock status to the VCP at 115200 8N1, and toggling LD2 at 9 MHz (5ns). This was built with Keil uV4.7 and SPL F4 DSP v1.6.1 ________________ Attachments : NUCLEO144-F446ZE-180MHZ-TOGGLELD2.hex : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtjH&d=%2Fa%2F0X0000000aWG%2FV9FQxk9C7IwTqPuXWJTWZqrqxgVW9uIZ6fGOgev0iVo&asPdf=false

[Elwood Downey]

Posted on August 25, 2016 at 21:14

I've confirmed on scope LD2 is toggling at 9 MHz. Serial port says:

Welcome to NUCLEO-144 F4

SYS:180000000 H:180000000, P1:45000000, P2:90000000

So my NUCLEO seems to function just fine, suggesting Cube is doing something wrong. I've attached Actuator.ioc for my small test program and a screen shot of Cube that created it. Again, my program works fine if HCLK is 40 MHz or less, above this the NUCLEO does nothing after fresh load. Would appreciate if this could be expedited, my project needs to be assured we can operate at full 180 MHz. Best, Elwood ________________ Attachments : Actuator.ioc : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006Htc7&d=%2Fa%2F0X0000000aS6%2FcUdGNdiiAOLQMKFEKID0ggWNNVuTEMd8z9jBm50CNro&asPdf=falseCube_180_MHz.png : https://st--c.eu10.content.force.com/sfc/dist/version/download/?oid=00Db0000000YtG6&ids=0680X000006HtjW&d=%2Fa%2F0X0000000aWJ%2F89T9mnrC3LRRkQfhNQYPnhSfCPZhMWUWTbLstSXnOPA&asPdf=false

[Tesla DeLorean]

Posted on August 25, 2016 at 22:14

Would appreciate if this could be expedited, my project needs to be assured we can operate at full 180 MHz.

I'm not the guy to fix your tools, the chip works fine if programmed properly.

[Elwood Downey]

Posted on August 25, 2016 at 22:39

I do apologize if there has been a misunderstanding. I thought we had concluded the problem was the code generated by STMCube32MX. You asked me for the ioc which I provided. If you thought it was my tool chain I would not have expected you to ask for this. I am happy to supply any further supporting information to help diagnose this issue.

I am using the arm gcc toolchain from https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads. I imagine STM does not support this but it is merely compiling the files generated by Cube. Bugs can be anywhere, of course, but at this point it is not clear to me how you can conclude so definitely the tool chain is the cause of my issue and not Cube.Would you please at least be willing to look at the clock code generated by Cube and confirm it is correct? I don't know exactly where it is so I have attached a tarball of the complete project tree created by Cube. If you can tell for sure that the clock code is correct, then I will accept the problem is not Cube and look elsewhere.Regards,Elwood

[Elwood Downey]

Posted on August 25, 2016 at 22:44

The forum software rejected my tarball. Perhaps you can specify the specific files related to clock settings and I could send those as plain text attachments?

Thanks again for your help.Regards.Elwood