-
Notifications
You must be signed in to change notification settings - Fork 6.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
modules: hal: nxp: update to include fix for CACHE64_GetInstanceByAddr() #81103
modules: hal: nxp: update to include fix for CACHE64_GetInstanceByAddr() #81103
Conversation
The following west manifest projects have been modified in this Pull Request:
Note: This message is automatically posted and updated by the Manifest GitHub Action. |
@danieldegrasse , please update the HAL SHA |
CACHE64_GetInstanceByAddr() function was asserting when an instance was requested for an invalid address that the CACHE64 controller does not manage. This behavior is not correct, as the CACHE64 management functions check to see if the instance number returned by this function is out of range (and if so, simply return without modifying the cache). This assertion was causing a failure within the USDHC driver, which performs a cache clean/invalidate for tx/rx transfers within the HAL layer. When a transfer was run using a data buffer not in the CACHE64 address range, this assertion failed and caused the application to crash Fixes zephyrproject-rtos#80901 Signed-off-by: Daniel DeGrasse <[email protected]>
Done, thanks for the ping |
bf75e3b
to
109185b
Compare
@danieldegrasse this pr fix part of this sdmmc issue, still another one
|
Locally the sdmmc test passes for me with this fix. Do you still see a failure on your board? |
sorry my bad. this PR fixes all issues.
|
CACHE64_GetInstanceByAddr() function was asserting when an instance was requested for an invalid address that the CACHE64 controller does not manage. This behavior is not correct, as the CACHE64 management functions check to see if the instance number returned by this function is out of range (and if so, simply return without modifying the cache).
This assertion was causing a failure within the USDHC driver, which performs a cache clean/invalidate for tx/rx transfers within the HAL layer. When a transfer was run using a data buffer not in the CACHE64 address range, this assertion failed and caused the application to crash
Fixes #80901