core: update SEMID list

fpistm · fpistm · commit bb5291fe2cef · 2021-07-07T18:46:21.000+02:00
Signed-off-by: Frederic Pillon &lt;frederic.pillon@st.com&gt;
diff --git a/cores/arduino/stm32/lock_resource.h b/cores/arduino/stm32/lock_resource.h
@@ -35,12 +35,41 @@ typedef enum {
  * HW semaphore Complement ID list defined in hw_conf.h from STM32WB.
  * They could be used also for H7 dualcore targets.
  */
+
+/**
+ *  The CPU2 may be configured to store the Thread persistent data either in internal NVM storage on CPU2 or in
+ *  SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config()
+ *  When the CPU2 is requested to store persistent data in SRAM2, it can write data in this buffer at any time when needed.
+ *  In order to read consistent data with the CPU1 from the SRAM2 buffer, the flow should be:
+ *  + CPU1 takes CFG_HW_THREAD_NVM_SRAM_SEMID semaphore
+ *  + CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
+ *  + CPU1 releases CFG_HW_THREAD_NVM_SRAM_SEMID semaphore
+ *  CFG_HW_THREAD_NVM_SRAM_SEMID semaphore makes sure CPU2 does not update the persistent data in SRAM2 at the same time CPU1 is reading them.
+ *  There is no timing constraint on how long this semaphore can be kept.
+ */
+#define CFG_HW_THREAD_NVM_SRAM_SEMID                    9
+
+/**
+ *  The CPU2 may be configured to store the BLE persistent data either in internal NVM storage on CPU2 or in
+ *  SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config()
+ *  When the CPU2 is requested to store persistent data in SRAM2, it can write data in this buffer at any time when needed.
+ *  In order to read consistent data with the CPU1 from the SRAM2 buffer, the flow should be:
+ *  + CPU1 takes CFG_HW_BLE_NVM_SRAM_SEMID semaphore
+ *  + CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
+ *  + CPU1 releases CFG_HW_BLE_NVM_SRAM_SEMID semaphore
+ *  CFG_HW_BLE_NVM_SRAM_SEMID semaphore makes sure CPU2 does not update the persistent data in SRAM2 at the same time CPU1 is reading them.
+ *  There is no timing constraint on how long this semaphore can be kept.
+ */
+#define CFG_HW_BLE_NVM_SRAM_SEMID                    8
+
 /*
  * Index of the semaphore used by CPU2 to prevent the CPU1 to either write or
  * erase data in flash. The CPU1 shall not either write or erase in flash when
  * this semaphore is taken by the CPU2. When the CPU1 needs to either write or
  * erase in flash, it shall first get the semaphore and release it just
  * after writing a raw (64bits data) or erasing one sector.
+ *  Once the Semaphore has been released, there shall be at least 1us before it can be taken again. This is required
+ *  to give the opportunity to CPU2 to take it.
  * On v1.4.0 and older CPU2 wireless firmware, this semaphore is unused and
  * CPU2 is using PES bit. By default, CPU2 is using the PES bit to protect its
  * timing. The CPU1 may request the CPU2 to use the semaphore instead of the
