cancel
Showing results for 
Search instead for 
Did you mean: 

Problems using the Cache and SCB_DisableDCache in Bootloader before jumping to Application

Hueli.1
Associate III

I have a question about the usage of the Cache in a Bootloader for the STM32H730

I am using:

  • STM32H7
  • external Flash connected to over OCTOSPI in QSPI Mode
  • CMISIS version V5.0.8
  • I first run a Bootloader that initialized the OCTOSPI/QSPI and then loads the Application from Flash and jumps to the Application
  • I have based my Code on the example for the STMH735G-DK which comes with STM32CubeMX in the Folder "C:\Users\<Username>\STM32Cube\Repository\STM32Cube_FW_H7_V1.9.0\Projects\STM32H750B-DK\Templates\ExtMem_Boot\Src "
  • I am using Code generated by CubeMX and the following USER CODE:
int main(void)
{
  /* USER CODE BEGIN 1 */
  /* USER CODE END 1 */
 
  /* Enable I-Cache---------------------------------------------------------*/
  SCB_EnableICache();
  /* Enable D-Cache---------------------------------------------------------*/
  SCB_EnableDCache();
 
  /* MCU Configuration--------------------------------------------------------*/
  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init();
 
  /* USER CODE BEGIN Init */
  __enable_irq();
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();
 
  /* USER CODE BEGIN SysInit */
  /* USER CODE END SysInit */
 
  /* Initialize all configured peripherals */
  MX_GPIO_Init();
  MX_DMA_Init();
  MX_CRC_Init();
  MX_OCTOSPI1_Init();
  /* USER CODE BEGIN 2 */
...
      *init QSPI*
      *set QSPI to memory mapped mode*
...
/* Disable all interrupts */
	NVIC->ICER[0] = NVIC->ICER[1] = NVIC->ICER[2] = NVIC->ICER[3] = NVIC->ICER[4] = NVIC->ICER[5] = 0xFFFFFFFF;
 
SCB_DisableICache();
SCB_DisableDCache(); /************* DOES NOT WORK ***************/
 
SysTick->CTRL = 0;
 
*jump to application*
}
  •  

My Problem:

  • Before jumping to the Application I try to call SCB_DisableDCache but this doesn't work (get stuck on function for longer time). The function SCB_DisableICache works fine
  • When debugging I get an infinite loop but I have read that this can actually occur while debugging and usually does not.
  • Strangely when I call SCB_CleanInvalidateDCache before SCB_DisableDCache  AND use an older version of SCB_DisableDCache (here) then it somehow works fine.

My Question:

  • Am I missing something like enabling SDRAM or should I disable the DMA or something or interrupts?
  • Should I call something like Clean or Invalidate before disabling or a combination thereof?

Thank you for any help!

1 ACCEPTED SOLUTION

Accepted Solutions
Hueli.1
Associate III

Problem is described here already: https://github.com/ARM-software/CMSIS_5/issues/620

Solution:

  • either do not use compiler optimization -O0
  • or put the "register" keyword in front of ccsidr, sets and ways variable definition in SCB_DisableDCache when using compiler optimization -O0

View solution in original post

8 REPLIES 8
Hueli.1
Associate III

Update:

I noticed that the SCB_DisableDCache() run properly if I do it before HAL_InitTick().

Could it be that the settings in HAL_InitTick come from an older project that and do not match the current STMH7?

Ons KOOLI
Senior III

Hi @Hueli.1​ ,

Are you using DTCM/ITCM ?

Ons.

I don't think so. While the ITCM and DTCM sections are defined like the following there is no .itcm part (does this mean it's not used?):

 DTCMRAM  (xrw)  : ORIGIN = 0x20000000 + 0x30,   LENGTH = 128K - 0x30

 ITCMRAM  (xrw)  : ORIGIN = 0x00000000,   LENGTH = 64K

However I think I have found the solution to the problem. See response to my original post

Hueli.1
Associate III

Problem is described here already: https://github.com/ARM-software/CMSIS_5/issues/620

Solution:

  • either do not use compiler optimization -O0
  • or put the "register" keyword in front of ccsidr, sets and ways variable definition in SCB_DisableDCache when using compiler optimization -O0
Piranha
Chief II

Bootloader must be as simple and robust as possible and it's performance is not critical. Therefore to avoid both software and hardware issues for bootloader it is highly recommended to not use cache memories at all.

This commit to the CMSIS repository fixes it properly.

Expect it to be updated in ST's code base in the next 5 years. ;) For F7 series they are still shipping a version from 2018 with broken cache management functions, which were fixed in the same 2018 few months later.

And read my other comment...