STM32H755 CM4's HAL_Delay() never returns

[bramble]

Hi All,

I have a problem on H755 Nucleo which is that the M4's tick doesn't seem to be advancing.

Digging a little deeper I can see that uwTickFreq is zero, but I can't see why that's happened. There must be something wrong in my .ioc file since I've hardly done anything in the M4 code (M7 is working fine).

Currently, both cores boot with FreeRTOS on each. I can step through a simple bit of code on the M4 using osDelay(), however as soon as HAL_Delay() is called that's the end of it.

I have searched this forum and read several Q&A on this topic, but none of them seem to match my situation. I'd be very grateful if anyone can spot an obvious error in my .ioc file.

Thanks

[TDK]

The tick priority needs to be higher (numerically lower) than the interrupt you're calling HAL_Delay from.

So for you, that means TIM6 and TIM7 interrupts need to be under 5 if you're calling HAL_Delay from another interrupt with priority 5.

[bramble]

Hi @TDK ,

Thank you for your advice. I'm calling from a very simple RTOS task - I originally saw this issue in my SDMMC driver on M4, where I suspected a problem with priorities. However I've stripped out that code and gone back to a much simpler way of reproducing the issue in the only RTOS task that's running on my M4:

void StartCM4MainTask(void *argument)
{
  /* USER CODE BEGIN StartCM4MainTask */
  /* Infinite loop */
  for(;;)
  {
	BSP_LED_On(LED_GREEN);
	HAL_Delay(1000);
    osDelay(500);
    BSP_LED_Off(LED_GREEN);
  }
  /* USER CODE END StartCM4MainTask */
}

Whilst I think osDelay() is generally preferable at the task level (being tick-freq independent), I should be able to do also use HAL_Delay() here shouldn't I?

Thanks.

[TDK]

Yes. Are you debugging and stepping through or just looking at the green LED? It should be on for 1.5 seconds, then off for about 1us, which is always on for a human.

[bramble]

Hi @TDK , ah - good point!  I'm single stepping though, in fact the LEDs aren't enabled on M4, so that's a bit of rotten code, sorry to say.

I think I've confirmed that my ADCs on M7 are trampling over M4's memory though. I saw that uwTickFreq was zero, which was a big clue. So I must have either done something silly in my linker scripts or messed up in the ADC config.

A related thing that I'm confused about is whether when configuring MPUs for the cores, can/should I used RAM aliases? For example, I'm using the first 16 kB of SRAM1 for ADC buffers and the remaining 272 kB of SRAM1, plus SRAM2 & SRAM3 for CM4. So I have this (for CM4):

MEMORY
{
FLASH (rx)     : ORIGIN = 0x08100000, LENGTH = 1024K
RAM_D2 (xrw)   : ORIGIN = 0x10004000, LENGTH =  272K   	/* First 16 kB (at 0x10000000) reserved for M7's ADC buffers. */
RAM_D3 (xrw)   : ORIGIN = 0x38000000, LENGTH =   64K	/* SRAM4 in D3 is shared by both cores. */
/*RAM (xrw)      : ORIGIN = 0x10000000, LENGTH = 288K*/
}

While for CM7 I have:

/* Memories definition */
MEMORY
{
  RAM_D1 (xrw)            : ORIGIN = 0x24000000, LENGTH =  512K
  FLASH   (rx)            : ORIGIN = 0x08000000, LENGTH = 1024K    	/* Memory is divided. Actual start is 0x08000000 and actual length is 2048K */
  DTCMRAM (xrw)           : ORIGIN = 0x20000000, LENGTH =  128K
  NON_CACHED_RAM_D2 (xrw) : ORIGIN = 0x30000000, LENGTH =   16K		/* First 16K of SRAM1 for non-cached ADC buffers. */
/*  RAM_D2 (xrw)            : ORIGIN = 0x30004000, LENGTH =  272K      Remaining SRAM1 in D2 is reserved for CM4. */
  RAM_D3 (xrw)            : ORIGIN = 0x38000000, LENGTH =   64K		/* SRAM4 in D3 is shared by both cores. */
  ITCMRAM (xrw)           : ORIGIN = 0x00000000, LENGTH =   64K
}

Since 0x10004000 is an alias (write-through) of 0x30004000, should I use 0x10004000 when defining the associated MPU region for CM4 or can/should I use the unaliased address 0x30004000?

Thanks very much for your help.

[bramble]

Further update, a look at the CM7.list file reveals where the problem arises:

Clearly the HSEM is using address 0x30004000, which is where CM4 has been told it can start using SRAM1, and CM7 as been told that it can't access any more than 16 kB running between 0x30000000 & 0x30003fff (see the two linker scripts shown in my last update).

Isn't this a bug?