You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Did you check current release notes for known issues?
No.
If this is not the latest release, have you checked newer releases?
Latest.
Description:
Cy_Flash_OperationStatus returns 0 but following Cy_Flash_SendCmd return CY_FLASH_DRV_IPC_BUSY, when clock measurements are in use elsewhere ((SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE == 0)). For example, BLE stack uses clock measurements when PILO is used for LFCLK.
Proposed fix:
Cy_Flash_OperationStatus should return CY_FLASH_DRV_OPCODE_BUSY when clock measurements are not done: (0UL == _FLD2VAL(SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE, SRSS_CLK_CAL_CNT1)) → CY_FLASH_DRV_OPCODE_BUSY.
Steps to Reproduce:
Configure BLE to use PILO. BLE stack uses clock measurements for PILO trimming.
Application code checks if flash operation is busy or not with Cy_Flash_OperationStatus. Cy_Flash_OperationStatus returns not busy (return value 0).
Application starts flash operation (for example write) but Cy_Flash_SendCmd returns CY_FLASH_DRV_IPC_BUSY because BLE stack is actively using clock measurements, and so (SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE == 0).
Expected Result:
Cy_Flash_SendCmd should not return CY_FLASH_DRV_IPC_BUSY as preceding Cy_Flash_OperationStatus returned 0.
Actual Result:
Cy_Flash_SendCmd returns CY_FLASH_DRV_IPC_BUSY when preceding Cy_Flash_OperationStatus returned 0.
Can you let me know which code example you are using for this so that we can replicate the issue on our side as well.
If you are not using a code example, can you share your project which shows this issue?
Unfortunately this is not code that I can share. However, issue is related to using PILO for deep-sleep with BLESS stack. BLESS is using measurement timers to trim PILO and BLESS is using clock measurement in async/non-blocking way. When BLESS initiated clock measurement is ongoing, Cy_Flash_SendCmd call fails because clock measurement being busy.
Another issue noticed with BLESS & PILO & clock measurement is that Cy_BLE_Disable does not wait for pending clock measurement to complete but instead stops measured clocks abruptly. This causes clock measurement to never complete and Cy_Flash_SendCmd then never succeed after Cy_BLE_Disable (if BLESS clock measurement was pending when disabling BLE).
We've fixed these issues internally on forked versions of pdl and bless, so there is no urgency for fix for us. Just putting this out here so anyone else running to these issues can have pointers where to look.
Prerequisites
Can you reproduce the problem reliably?
Did you check current release notes for known issues?
If this is not the latest release, have you checked newer releases?
Description:
Cy_Flash_OperationStatus
returns 0 but followingCy_Flash_SendCmd
returnCY_FLASH_DRV_IPC_BUSY
, when clock measurements are in use elsewhere ((SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE == 0)
). For example, BLE stack uses clock measurements when PILO is used for LFCLK.Proposed fix:
Cy_Flash_OperationStatus
should returnCY_FLASH_DRV_OPCODE_BUSY
when clock measurements are not done:(0UL == _FLD2VAL(SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE, SRSS_CLK_CAL_CNT1))
→CY_FLASH_DRV_OPCODE_BUSY
.Steps to Reproduce:
Configure BLE to use PILO. BLE stack uses clock measurements for PILO trimming.
Application code checks if flash operation is busy or not with
Cy_Flash_OperationStatus
.Cy_Flash_OperationStatus
returns not busy (return value 0).Application starts flash operation (for example write) but
Cy_Flash_SendCmd
returnsCY_FLASH_DRV_IPC_BUSY
because BLE stack is actively using clock measurements, and so(SRSS_CLK_CAL_CNT1_CAL_COUNTER_DONE == 0)
.Expected Result:
Cy_Flash_SendCmd
should not returnCY_FLASH_DRV_IPC_BUSY
as precedingCy_Flash_OperationStatus
returned0
.Actual Result:
Cy_Flash_SendCmd
returnsCY_FLASH_DRV_IPC_BUSY
when precedingCy_Flash_OperationStatus
returned0
.Frequency (1/1, 1/50, 1/100):
1/1
Build/Commit:
Target:
PSoC63
Host OS and Version:
Windows, Linux
Compiler:
MTB 2.4.0
Environment
The text was updated successfully, but these errors were encountered: