8000 Wrong filesystem size on Arduino RP2040 Connect · Issue #4874 · adafruit/circuitpython · GitHub
[go: up one dir, main page]

Skip to content

Wrong filesystem size on Arduino RP2040 Connect #4874

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

Closed
tannewt opened this issue Jun 9, 2021 · 2 comments · Fixed by #5035
Closed

Wrong filesystem size on Arduino RP2040 Connect #4874

tannewt opened this issue Jun 9, 2021 · 2 comments · Fixed by #5035
Assignees
Labels
board New board or update to a single board bug rp2040 Raspberry Pi RP2040
Milestone

Comments

@tannewt
Copy link
Member
tannewt commented Jun 9, 2021

Firmware

All with Arduino RP2040 Connect

Description

Filesystem size is 1MB instead of 15MB.

My guess is that the flash chip isn't correctly reporting its size. So, we hit the default case of 1 MB. Related code is here: https://github.com/adafruit/circuitpython/blob/main/ports/raspberrypi/supervisor/internal_flash.c#L67-L79

The fix would be to use the flash size from nvm.toml if the value is out of range.

@tannewt tannewt added bug board New board or update to a single board rp2040 Raspberry Pi RP2040 labels Jun 9, 2021
@tannewt tannewt added this to the Long term milestone Jun 9, 2021
@fivdi
Copy link
fivdi commented Jun 23, 2021

Hi, I ended up here in this issue after noticing the file system size for the Arduino Nano RP2040 Connect is 1 MB rather than the expected 15 MB. Of course, this also means it's not possible to copy more that 1 MB to the file system so the remaining 14 MB go unused 😄

My guess is that the flash chip isn't correctly reporting its size.

I wrote a small pico-sdk application to see what the call to flash_do_cmd here returns in array data. Here is what I saw in the array:

0xff 0x1f 0x89 0x01

This is what the datasheet says it should return. See section 7 on page 14 of the data sheet here for further details.

The datasheet refers to the "device identification" instruction (0x9f) as being a legacy instruction which somehow implies that it's no longer the best of ideas to use it, at least that is how I interpret the word legacy in this case.

Anyway, byte 3 in the array data is 0x01 which is the important byte for the calculation performed after calling flash_do_cmd. Unfortunately, 0x01 for the AT25SF128A flash memory used by Arduino Nano RP2040 Connect doesn't appear to mean the same thing as 0x01 for other flash memories on other RP2040 boards.

The fix would be to use the flash size from nvm.toml if the value is out of range.

The pico-sdk has a define called PICO_FLASH_SIZE_BYTES, maybe this could be used? Then again, maybe not, I'm not sure how tightly coupled CircuitPython and pico-sdk are.

@tannewt
Copy link
Member Author
tannewt commented Jun 24, 2021

We generally don't use the pico-sdk for board defines because we supported more out of the box. Both GigaDevice and Winbond flashes will report 0x21+ for capacity.

For this, I think we'll want a small Python script similar to https://github.com/adafruit/circuitpython/blob/main/tools/gen_nvm_devices.py that generates a header file that either allows for the current detection or a fixed flash size. Then,the detection code could be overridden.

@tannewt tannewt modified the milestones: Long term, 7.0.0 Jun 30, 2021
@tannewt tannewt self-assigned this Jul 15, 2021
dhalbert pushed a commit that referenced this issue Jul 21, 2021
For RP2040 boards, we now change the default flash size based on
the configured flash. We will still try to read the size from the
flash first.

Fixes #4874
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
board New board or update to a single board bug rp2040 Raspberry Pi RP2040
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants
0