Are there any known issues with having i-cache, d-cache & flash pre-fetch enabled on STM32F411/STM32F413

[MSuhe]

I have come across some unreliable behaviour with SPI, when having i-cache & d-cache enabled. Are there any known issues with i-cache & d-cache on these controllers?

Recently, while going through "ChibiOs" repository i found below comment which points at similar issues. So, it looks like i am not the only one to have come across a similar issue.

 /* Some old revisions of F4x MCUs randomly crashes with compiler

   optimizations enabled AND flash caches enabled. */

Can anyone from the ST community be so kind and share if there are any known limitations/issues with having i-cache, d-cache & flash pre-fetch enabled?

[Tesla DeLorean]

Some of the older 405/415, 407/417 had issues..

static void SystemClock_Config(void)
{
  RCC_ClkInitTypeDef RCC_ClkInitStruct;
  RCC_OscInitTypeDef RCC_OscInitStruct;
 
  /* Enable Power Control clock */
  __HAL_RCC_PWR_CLK_ENABLE();
 
  /* The voltage scaling allows optimizing the power consumption when the device is
     clocked below the maximum system frequency, to update the voltage scaling value
     regarding system frequency refer to product datasheet.  */
  __HAL_PWR_VOLTAGESCALING_CONFIG(PWR_REGULATOR_VOLTAGE_SCALE1);
 
  /* Enable HSE Oscillator and activate PLL with HSE as source */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PLLSOURCE_HSE;
  RCC_OscInitStruct.PLL.PLLM = 25;
  RCC_OscInitStruct.PLL.PLLN = 336;
  RCC_OscInitStruct.PLL.PLLP = RCC_PLLP_DIV2;
  RCC_OscInitStruct.PLL.PLLQ = 7;
  HAL_RCC_OscConfig(&RCC_OscInitStruct);
 
  /* 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;
  RCC_ClkInitStruct.APB1CLKDivider = RCC_HCLK_DIV4;
  RCC_ClkInitStruct.APB2CLKDivider = RCC_HCLK_DIV2;
  HAL_RCC_ClockConfig(&RCC_ClkInitStruct, FLASH_LATENCY_5);
 
  /* STM32F405x/407x/415x/417x Revision Z devices: prefetch is supported  */
  if (HAL_GetREVID() == 0x1001)
  {
    /* Enable the Flash prefetch */
    __HAL_FLASH_PREFETCH_BUFFER_ENABLE();
  }
}

[MSuhe]

Thanks for your response. Can you please provide the definition of HAL_GetREVID() or let me know where i can get it. Also, we are working with STM32F411 & STM32F413 are there any issues on these as well?

[Tesla DeLorean]

Try grep or google

http://www.disca.upv.es/aperles/arm_cortex_m3/llibre/st/STM32F439xx_User_Manual/stm32f4xx__hal_8c_source.html#l00459

No, not aware of such issues with the 411/412/413 parts, check the Errata?

[MSuhe]

Thanks for reference. Yes i did have a look at the errata document and i find no issues related to cache.

[S.Ma]

Unless proven wrong, instruction and/or data cache are only implemented in cortex M7 and higher parts.

[waclawek.jan]

Here, it refers to portions of the FLASH accelerator - jumpcache and datacache, a.k.a. ART.

IMO, except the mentioned ancient revision of 'F407, if switching them on causes "unreliable behaviour of SPI", it's either a race condition in software unmasked by a faster code execution, or hardware problem - inadequate power supply/grounding - revealed by increase in power consumption and digital noise related to the use of accelerator.

JW