CM7 goes to infinite loop at 0xa05f0001 when enter/exit D1Stop mode on STM32H755(or STM32H745)

[murali.karicheri]

Hi support,

I am trying to have STM32H755 boots simultaneously with following use case and seeing that CM7
encounter an infinite loop execution at 0xa05f0001 for some reason. Could someone help me to
understand why this is happening and what is wrong with code and how to fix it?

1. CM7 boots and enter D1Stop mode (Except Flash controller since we have code running from Flash)

2. CM4 check if CM7 enters D1Stop mode and if success then do some work.

3. CM4 Send an HW semaphore event to CM7 to wake it up on Semaphore ID 1

4. CM4 checks if CM7 has exited D1Stop mode and continue in it's task

So I started with OpenAMP middleware example code generated by STM32CubeMX and modified
it since that does this the other way. i.e CM4 enters D2Stop mode and CM7 wakes it up.
I have setup STM32CubeIDE debugger to Load code onto flash (both for CM4 and CM7) from CM4 (Reset
behavior for STLink GDB server - 'Halt all cores' and None for CM7) and No load
selected for CM7. I put breakpoint just at the While () loop on CM7 and CM4.
I then go to main.c of CM4 and hit F11 to start the debug session. The code stops at main(). Then
I then click and view main.c of CM7. It also stops at main(). I then select main() of CM4 and
CM7 and hit 'Resume' on the IDE. What I observe is on CM4, code stops at the while loop, while on CM7,
it go forever loop at 0xaf05f0001 and not hit the breakpoint at while() loop

Here is the code on CM4

int main(void)
{
int32_t status = 0, timeout;

if (HAL_Init() != HAL_OK)
{
Error_Handler();
}

SystemClock_Config();

/* wait until CPU1 Enters stop mode */
timeout = 0xFFFF;
while((__HAL_RCC_GET_FLAG(RCC_FLAG_D1CKRDY) != RESET) && (timeout-- > 0));
if ( timeout < 0 )
{
Error_Handler();
}

//BSP_LED_Init(LED_GREEN);

/* When system initialization is finished, Cortex-M4 will release Cortex-M7 by means of
HSEM notification */

/*HW semaphore Clock enable*/
__HAL_RCC_HSEM_CLK_ENABLE();

/*Take HSEM */
HAL_HSEM_FastTake(HSEM_ID_1);
/*Release HSEM in order to notify the CPU1(CM7)*/
HAL_HSEM_Release(HSEM_ID_1,0);

/* wait until CPU1 wakes up from stop mode */
timeout = 0xFFFF;

while((__HAL_RCC_GET_FLAG(RCC_FLAG_D1CKRDY) == RESET) && (timeout-- > 0));
if ( timeout < 0 )
{
Error_Handler();
}

while(1); // <==== breakpoint
}

Here is the code at CM7

int main(void)
{
int32_t timeout,status ;

if (HAL_Init() != HAL_OK)
{
Error_Handler();
}

/* System Init, System clock, voltage scaling and L1-Cache configuration are done by CPU1 (Cortex-M7)
in the meantime Domain D2 is put in STOP mode(Cortex-M4 in deep-sleep)
*/

/* Configure the MPU attributes as Not cacheable for D3 SRAM : Shared Memory used for OpemAMP*/
MPU_Config();
/* Enable the CPU Cache */
CPU_CACHE_Enable();

/* STM32H7xx HAL library initialization:
- Systick timer is configured by default as source of time base, but user
can eventually implement his proper time base source (a general purpose
timer for example or other time source), keeping in mind that Time base
duration should be kept 1ms since PPP_TIMEOUT_VALUEs are defined and
handled in milliseconds basis.
- Set NVIC Group Priority to 4
- Low Level Initialization
*/
/*HW semaphore Clock enable*/
__HAL_RCC_HSEM_CLK_ENABLE();

/*Clear Flags generated during the wakeup notification */
HSEM_COMMON->ICR |= ((uint32_t)__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_1));
HAL_NVIC_ClearPendingIRQ(HSEM1_IRQn);

HAL_HSEM_ActivateNotification(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_1));

// code change for M7 enters stop mode

//__HAL_RCC_FLASH_C2_ALLOCATE();
//__HAL_RCC_C2_FLASH_CLK_SLEEP_DISABLE();
HAL_PWREx_ClearPendingEvent();
HAL_PWR_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFE);

/*Clear Flags generated during the wakeup notification */
HSEM_COMMON->ICR |= ((uint32_t)__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_1));
HAL_NVIC_ClearPendingIRQ(HSEM1_IRQn);

while(1); // <==== breakpoint
}

[FBL]

Hello @murali.karicheri , 

First, let me introduce to you the AN5361 in which you can find in section 3.1 How to Set up with ST-LINK GDB server. 
Second, it is possible that 0xa05f0001 is the result of a stack overflow. You can increase the stack size for the CM7. 
Also, you can check AN5617  STM32H745/755 and STM32H747/757 lines inter-processor communications - Application note for further details about IPCC.