STM32H755 BCM4 and BCM7 Option Bytes settings

[scuba]

Hello,

In our application, we need the M7 of the STM32H755 to boot first, and after it initializes to allow the M4 to boot.

We set the option bytes per CubeProgrammer such that BCM7 is enabled (checked) and BCM4 is disabled (unchecked).  We also set a handful of other option bytes/bits (Read out protection, BOR Level, Independent WDog, etc).

With this however, both processors boot on power up at the same time.  I have stepped thru the code and noticed that during init, after the "__HAL_RCC_SYSCFG_CLK_ENABLE" call, the registers are loaded and can be read.  At this time, it sees that the UR1 register of the SYSCFG peripheral is set such that BCM7 and BCM4 are both enabled (event thou CubeProgrammer has BCM4 set to 0).

I tested other option bytes and can see if I change the BOR level, its SYSCFG UR2 Correctly updates to match the level changed to in the option bytes via CubeProgrammer...

With that, is there some configuration or HW connection that will prevent the BCM4 and BCM7 option byte settings from being correctly loaded?

Thanks,

-mike

[scuba]

Digging a bit more, I can see the FLASH OPTSR_CUR_ and the OPTSR_CUR registers both have the same value.  One think I noticed is that the boot bits are not decoded by the debugger...  in my case, 0x1880aa3c, the "8" is correctly specifying that M7 boot is on, and M4 boot is off...  But SYSCFG.UR1 register still shows both being on...

[SofLit]

Hello,

I'm wondering why are you using option bytes to just doing the following:

"In our application, we need the M7 of the STM32H755 to boot first, and after it initializes to allow the M4 to boot."

At the beginning of your application, you can use low power modes + Hardware semaphore to synchronize between the cores and let CM7 initializes the system and wakes up CM4 to continue the execution like the examples provided in the STM32CubeH7: 

GPIO as example:

https://github.com/STMicroelectronics/STM32CubeH7/tree/master/Projects/STM32H747I-EVAL/Examples/GPIO/GPIO_EXTI

CM7:

  /* When system initialization is finished, Cortex-M7 will release (wakeup) Cortex-M4  by means of 
     HSEM notification. Cortex-M4 release could be also ensured by any Domain D2 wakeup source (SEV,EXTI..).
  */
  
   /*HW semaphore Clock enable*/
  __HAL_RCC_HSEM_CLK_ENABLE();
  
    /*Take HSEM */
    HAL_HSEM_FastTake(HSEM_ID_0);   
   /*Release HSEM in order to notify the CPU2(CM4)*/     
    HAL_HSEM_Release(HSEM_ID_0,0);

CM4:

 /*HW semaphore Clock enable*/
  __HAL_RCC_HSEM_CLK_ENABLE();
 
  /* Activate HSEM notification for Cortex-M4*/
  HAL_HSEM_ActivateNotification(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_0));
  
  /* 
    Domain D2 goes to STOP mode (Cortex-M4 in deep-sleep) waiting for Cortex-M7 to
    perform system initialization (system clock config, external memory configuration.. )   
  */
  HAL_PWREx_ClearPendingEvent();
  HAL_PWREx_EnterSTOPMode(PWR_MAINREGULATOR_ON, PWR_STOPENTRY_WFE, PWR_D2_DOMAIN);

  /* Clear HSEM flag */
  __HAL_HSEM_CLEAR_FLAG(__HAL_HSEM_SEMID_TO_MASK(HSEM_ID_0));

[scuba]

Hello, since our application is very power sensitive, we wanted to use the most power efficient method.  We figured this would be to keep the M4 completely off as long as possible, and then enable only when our system has sufficient energy to power both cores...

So, we definitely prefer just having M4 gated until our system is ready for it...

Any thoughts as to why the option byte for the M4 is not being honored?

Thanks,

-mike

[murali.karicheri]

Hi,

This is Murali, Mike's colleague. Any update on the issue please?