Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Commit329b8bc

Browse files
committed
core: update SEMID list
Signed-off-by: Frederic Pillon <frederic.pillon@st.com>
1 parentdf22e73 commit329b8bc

File tree

1 file changed

+29
-0
lines changed

1 file changed

+29
-0
lines changed

‎cores/arduino/stm32/lock_resource.h

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -35,12 +35,41 @@ typedef enum {
3535
* HW semaphore Complement ID list defined in hw_conf.h from STM32WB.
3636
* They could be used also for H7 dualcore targets.
3737
*/
38+
39+
/**
40+
* The CPU2 may be configured to store the Thread persistent data either in internal NVM storage on CPU2 or in
41+
* SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config()
42+
* When the CPU2 is requested to store persistent data in SRAM2, it can write data in this buffer at any time when needed.
43+
* In order to read consistent data with the CPU1 from the SRAM2 buffer, the flow should be:
44+
* + CPU1 takes CFG_HW_THREAD_NVM_SRAM_SEMID semaphore
45+
* + CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
46+
* + CPU1 releases CFG_HW_THREAD_NVM_SRAM_SEMID semaphore
47+
* 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.
48+
* There is no timing constraint on how long this semaphore can be kept.
49+
*/
50+
#defineCFG_HW_THREAD_NVM_SRAM_SEMID 9
51+
52+
/**
53+
* The CPU2 may be configured to store the BLE persistent data either in internal NVM storage on CPU2 or in
54+
* SRAM2 buffer provided by the user application. This can be configured with the system command SHCI_C2_Config()
55+
* When the CPU2 is requested to store persistent data in SRAM2, it can write data in this buffer at any time when needed.
56+
* In order to read consistent data with the CPU1 from the SRAM2 buffer, the flow should be:
57+
* + CPU1 takes CFG_HW_BLE_NVM_SRAM_SEMID semaphore
58+
* + CPU1 reads all persistent data from SRAM2 (most of the time, the goal is to write these data into an NVM managed by CPU1)
59+
* + CPU1 releases CFG_HW_BLE_NVM_SRAM_SEMID semaphore
60+
* 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.
61+
* There is no timing constraint on how long this semaphore can be kept.
62+
*/
63+
#defineCFG_HW_BLE_NVM_SRAM_SEMID 8
64+
3865
/*
3966
* Index of the semaphore used by CPU2 to prevent the CPU1 to either write or
4067
* erase data in flash. The CPU1 shall not either write or erase in flash when
4168
* this semaphore is taken by the CPU2. When the CPU1 needs to either write or
4269
* erase in flash, it shall first get the semaphore and release it just
4370
* after writing a raw (64bits data) or erasing one sector.
71+
* Once the Semaphore has been released, there shall be at least 1us before it can be taken again. This is required
72+
* to give the opportunity to CPU2 to take it.
4473
* On v1.4.0 and older CPU2 wireless firmware, this semaphore is unused and
4574
* CPU2 is using PES bit. By default, CPU2 is using the PES bit to protect its
4675
* timing. The CPU1 may request the CPU2 to use the semaphore instead of the

0 commit comments

Comments
 (0)

[8]ページ先頭

©2009-2025 Movatter.jp