2014-02-27 12:56 PM
Hi,
If you set the PLL speed of the micro to 160MHz (PLL_M=25, PLL_N=320, PLL_P=2) then the generated software correctly contains the line in SystemClock_Config(): HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5); However if you change it to run at 168MHz by setting PLL_N=336, it incorrectly generates this code: HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_0); This means that the processor stops running as the flash access times are wrong. The STM32Cube code generator algorithm needs to have this bug fixed. Thanks Richard #stm32f400-stm32cube2014-02-28 01:34 AM
Hi,
A work-around for now is to add the following lines to main.c: /* USER CODE BEGIN 0 */ ///////////// Due to bug in STM32CubeMX, 168MHz is generated with FLASH_LATENCY_0 // when it should be FLASH_LATENCY_5. Therefore here we have to hack this value // back to ensure that even when main.c is auto-regenerated, it still works and // doesn't change the code back... ///////////// #undef FLASH_LATENCY_0 #define FLASH_LATENCY_0 FLASH_LATENCY_5 /* USER CODE END 0 */ Works now :) Richard2014-02-28 07:56 AM
With this configuration and scenario, the generated flash latency of 0 is actually correct.
In fact the STM32CubeMX default behavior is to optimize the chip configuration if not modified by the user (only the default values are impacted). With this scenario when changing the frequency from 160 MHz to 168 MHz, STM32CubeMX will optimize the configuration by setting the minimum possible value of the flash latency and the Vdd. So after changing the frequency to 168 MHz, you can check the RCC UI where you will find that the Vdd value is 2.1 V (168 MHz, 0 flash latency, 2.1 V is a correct configuration) Regards Daniel2014-02-28 08:38 AM
Hi Daniel,
Interesting. In that case can you explain why the Cube generates software with a flash wait state value set to 5 for 160MHz, but 0 for 168MHz? And why the processor crashes at the instruction where the 0 is programmed? Thanks, Richard2014-03-04 02:45 AM
Richard,
Thanks for pointing out this error. After verification with the designers, here is the actual table that should be used for this frequency:If 2.7V =<VDD<=3.6V --> Latency=5WS
2.4V=<VDD<=2.7V --> Latency=6WS 2.1V =<VDD<=2.4 --> Latency=7WS We have fixed the STM32CubeMX rules accordingly. This will be available in the next release of STM32CubeMX coming in a few weeks. Regards Daniel2016-03-10 03:09 PM
Hi all,
Really very interesting! Broke two walls with my head when trying to run Nucleo-64-F446RE - extremely simple thing - code below, w/o success. Finally, I found that Stm32cubeMX in Configuration, System, RCC have 5WS, but in code I've got 2WS. When changed to 5WS all is fine... till next code generation when value is back to 2WS. CubeMX version is 4.0 10x/* Infinite loop */
/* USER CODE BEGIN WHILE */
while
(1)
{
/* USER CODE END WHILE */
/* USER CODE BEGIN 3 */
HAL_GPIO_TogglePin(LD2_GPIO_Port, LD2_Pin);
HAL_Delay(500);
}
/* USER CODE END 3 */
2016-03-11 03:02 AM
Hi ivaylo iltchev,
Thanks for your feedback and contribution. I report this to our STM32CubeMX team.-Hannibal-2016-03-11 03:50 AM
RCC.FLatency-AdvancedSettings=FLASH_LATENCY_2
For now I changed to:RCC.FLatency-AdvancedSettings=FLASH_LATENCY_5
and all works as supposed to work, but probably this line has to be removed.2016-03-16 02:13 AM
Dear user,
Please note this issue will be fixed in the next release: STM32CubeMX 4.14.0. Best regards.2016-03-23 02:30 PM
Well done. With new version all worked as supposed to work.
Thanks.