cancel
Showing results for 
Search instead for 
Did you mean: 

Bug in STM32Cube for STM32F417

rgledhill
Associate II
Posted on February 27, 2014 at 21:56

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-stm32cube
9 REPLIES 9
rgledhill
Associate II
Posted on February 28, 2014 at 10:34

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 🙂

Richard

fauvarque.daniel
ST Employee
Posted on February 28, 2014 at 16:56

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

Daniel

rgledhill
Associate II
Posted on February 28, 2014 at 17:38

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,

Richard

fauvarque.daniel
ST Employee
Posted on March 04, 2014 at 11:45

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

Daniel

Ivaylo Ilchev
Associate III
Posted on March 11, 2016 at 00:09

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 */

Walid FTITI_O
Senior II
Posted on March 11, 2016 at 12:02

Hi ivaylo iltchev, 

Thanks for your feedback and contribution. I report this to our STM32CubeMX team.

-Hannibal-

Ivaylo Ilchev
Associate III
Posted on March 11, 2016 at 12:50

Hi Hannibal,

Thanks for participation. I found strange line in ioc files - my project file and template in STM32CubeMX\db\plugins\boardmanager\boards :

A42_Nucleo_NUCLEO-F446RE_STM32F446RE_Board.ioc

A42_Nucleo_NUCLEO-F446RE_STM32F446RE_Board_AllConfig.ioc

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.

 

stm32cube-t
Senior III
Posted on March 16, 2016 at 10:13

Dear user,

Please note this issue will be fixed in the next release: STM32CubeMX 4.14.0.

Best regards.
Ivaylo Ilchev
Associate III
Posted on March 23, 2016 at 22:30

Well done. With new version all worked as supposed to work.

Thanks.