STM32F7 QSPI flash timeouts and 4-byte addressing #152
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
On the STM32769NI at least this patch is required for stable QSPI use. Enable it uncondtionally in case other boards need it too. Further discussions: ARMmbed#10049 ARMmbed#15108 STMicroelectronics/STM32CubeF7#52 STMicroelectronics/STM32CubeF7#82
mbed-os PR 11531 introduced 4-byte addressing in the QSPIF block device: ARMmbed#11531 During testing it was found that this code broke on the NRF52840_DK and DISCO_F769NI. The NRF52840_DK controller seems unable to handle 4-byte addressing at all and has been disabled entirely in another code section. The DISCO_F769NI breakage was attributed to the flash chip but after more research I believe this is related to the QSPI controller, not the 4-byte addressing itself. Now that the QSPI controller has a workaround, enable 4-byte addressing again and hope it works fine this time.
|
Thanks for the patch! Did you test this on hardware? |
|
Yes, I have tested this on hardware.
UNRELATED:
I did find another bug possibly related to the QSPI code: After flashing Zephyr
and playing with it, flashing stock Mbed could no longer do QSPI mode. The chip
would just crash. But Zephyr would work.
I spent a while trying to debug it and found that perhaps setting 4-byte
addressing first then enabling QSPI mode fixed it. This is the only difference
I saw when comparing Zephyr's code and setting it to do that in Mbed fixed
the chip. I can't reliably reproduce this bug or confirm that's the actual fix-
I was throwing things at the wall.
Should I do a PR for that too?
…On Mon, Mar 20, 2023 at 10:29:38PM -0700, Jamie Smith wrote:
Thanks for the patch! Did you test this on hardware?
--
Reply to this email directly or view it on GitHub:
#152 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
|
Awesome, in that case, I'll give it the green light! Regarding the other issue... it's hard to say. It would be good to fix that issue, but I don't want to merge a fix that hasn't been tested on other devices. It's hard to know if it might break something else. It's tough because we don't have any sort of CI setup that can test any of the devices with QSPI. |
multiplemonomials
approved these changes
Mar 21, 2023
|
Thanks for the merge! If the bug happens again I'll try and reproduce it proper and fix it for everyone. :) |
|
You change code inside ST's HALs what is copied into Mbed. How do we ensure that change will be mirrored into new version (during port to MbedOS) if it will be necessary to change it for a reason in future? BR, Jan |
|
I don't know. Any ideas?
…On Tue, Mar 21, 2023 at 10:34:41AM -0700, JohnK1987 wrote:
You change code inside ST's HALs what is copied into Mbed. How do we ensure that change will be mirrored into new version if it will be necessary to change it for a reason in future?
BR, Jan
--
Reply to this email directly or view it on GitHub:
#152 (comment)
You are receiving this because you authored the thread.
Message ID: ***@***.***>
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary of changes
On the STM32769NI the STM32 BSP has an issue where QSPI accesses timeout and require a chip reset. Mbed use to contain a patch to fix this similar to this one but the change was lost during an update.
Enable the workaround ST uses for specific F7 chips but on all chips. There's no downside to this from what I can tell.
The 4-byte addressing was disabled because of timeouts which I think are due to this issue but falsely misattributed to 4-byte addressing. Enable that again.
Further discussions:
ARMmbed#10049
ARMmbed#15108
STMicroelectronics/STM32CubeF7#52
STMicroelectronics/STM32CubeF7#82
Impact of changes
Documentation
None
Pull request type
Test results
I'm not sure how to make a test for this yet. The issue takes an hour to recreate.