-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Don't check for corrupt heap too early; Fix QSPI timing #1418
Don't check for corrupt heap too early; Fix QSPI timing #1418
Conversation
@jerryneedell points out this will affect the Particle boards too. It will cut their QSPI speed in half. They are using MX25L which has 133 MHz max, so they'll run at 16 MHz instead of 32 MHz. I don't know why they appear to work but the Feather does not. I could special-case the Feather but it would be good at some point to understand what's going on. |
I downloaded this PR and built images for the Particle Xenon and Argon boards. Both appear work normally. No obvious impact. Note that neither board was exhibiting any problems without this PR either. I tested MSC by uploading the full py Bundle /lib and comparing it to the one already in place - no errors. I also tried changing the setting for the Argon in mpconfigboard.mk from using SPI_FLASH_FILESYSTEM = 1 |
The particle argon and xenon eagle files spec different flash chips. Not clear what is actually on the PCBs or if this matters (flash on both boards works with CP, but I tested with slower speeds than the CP repo). Would it be feasible to check which chip is actually on the board, rather than getting this information from a configuration file? |
@bboser We do actually check the chip id. We just list the possible chips for each board in |
I tried setting the pin drives to high and it didn't help. Leaving at 16 MHz for now. Did a new push with some minor cleanup. |
@ladyada Could you approve this if it's OK with you for now? That will get a working Feather 52840 build into |
checked! |
The Argon was SPI because QSPI wasn't working on mine even though it should have. I bet this PR fixes the issue I was hitting. I also removed the can from one Argon and one Xenon to verify the chip they shipped with. |
Hey all, sorry to revive a dead thread, but I'm bringing up the 52840 Feather for a Rust project and ran into the same 16MHz QSPI limitation. This was one of the few places I found that mentioned the limitation. Did anyone figure a way to get it working at 32MHz? |
We didn't. I assume your low-level code is completely different, so it's not just some problem in our setup. You could look in https://devzone.nordicsemi.com/ to see if this kind of thing was mentioned by anyone else, or even open a thread about it. |
Okay, thanks! My low level code is indeed different, and I have gotten 32MHz QSPI working with other flash parts using the same low level code, specifically the W25Q128JVS (though with a different nRF52 SOM, the Minew MS88SF2). So my best guess is it is something particular to this flash chip, the SOM in use, or the routing between the SOM and flash chip. Thankfully 16MHz is "fast enough" for my current application, so I probably won't chase this down any further. Thanks again for the confirmation! |
RGB led was being used before
stack_init()
, soassert_heap_ok()
was being called too early. Ignore heap check if stack not allocated yet.Multiple issues with nrf
qspi_flash.c
:Pos
values.Symptoms are that MSC gives errors on enumeration. May appear as an unlabeled drive or not at all.
PCA10056 flash chip is only 8MHz, so we didn't see this problem.
@hathach and @ladyada: either or both review.