STM32: NUCLEO-F767ZI Storage Issue

[johncblacker]

Firmware

Adafruit CircuitPython 6.1.0 on nucleo-f767zi

Bash

make BOARD=nucleo_f767zi

Behavior

Use make V=1, make V=2 or set BUILD_VERBOSE similarly in your environment to increase build verbosity.
QSTR updated
../../lib/tinyusb/src/common/tusb_fifo.c: In function 'tu_fifo_write':
../../lib/tinyusb/src/common/tusb_fifo.c:149:6: error: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Werror=strict-overflow]
   if ((p > p + offset) || (p + offset > f->max_pointer_idx))
      ^
cc1: all warnings being treated as errors
../../py/mkrules.mk:55: recipe for target 'build-nucleo_f767zi/lib/tinyusb/src/common/tusb_fifo.o' failed
make: *** [build-nucleo_f767zi/lib/tinyusb/src/common/tusb_fifo.o] Error 1

Description

CircuitPython drive shows total size of about 90K which is significantly lower than the 2M available on the board.
Flashed MicroPython for same board and it shows the correct amount of available storage i.e. 2M.

Additional Info

I looked at the STM32F767_fs.ld file in each distro and found that the MicroPython version has another line in the file:
FLASH_APP (rx) : ORIGIN = 0x0800x000, LENGTH = 2016K

I believe this line needs to be inserted into the CircuitPython version of the file in order to get the full 2M available to be used. I tried adding that line then performing a build, but ran into a build error (not related to the line I added, BTW).

So, I'm opening this bug report in order for the full 2M of storage for the board to be usable.

[tannewt]

@hierophect Any idea how much work this is?

[johncblacker]

Well, since I didn’t develop the code originally, no I don’t. I did look around in the uPy github repo and see it’s quite a bit different, so I imagine there’s quite a bit of work to accomplish it; but, on the other hand, I strongly feel that the original implementation for these boards wasn’t done correctly. Why waste a good percentage of the on board memory, especially when the board doesn’t have onboard sd card socket with which to overcome the loss of the onboard memory. I understand if Adafruit wants to table this request/issue, but that would leave me and others towards using uPy instead of cPy. In my opinion cPy was and is an offshoot of uPy and it has much of it’s base foundation in uPy, so why diverge in providing flash memory equal to the available ram? Thanks for responding. jb

[hierophect]

@johncblacker hi John, the NUCLEO-F767ZI was added by a community member, so it was probably just a mistake in the setup parameters that never got caught. The big F7/H7 Nucleos don't see as much use as the Discovery boards.

@tannewt this is probably just a typo/parameter problem in either the linker or the flash settings. I can take a look after wrapping up my low power draft today. @k0d might also have ideas, I think he was the one who originally added it.

[hierophect]

Ok, looks like it's just a linker thing. Filesystem size probably just wasn't a priority for whatever @k0d was using it for, and we don't tend to make big internal filesystems for chips in favor of external flash, but none of the F7 boards have external flash, so we can up it. I'll need to refresh on the F767 flash organization briefly to make sure there's nothing that makes using a bigger chunk of the flash a problem (like buffering sizes), but we can probably at least increase it to match the H7 default of 384k.

[johncblacker]

FWIW, I did modify the boards .ld file and made it look more similar to the uPy version. Basically added a single line called FLASH_APP, built the firmware onto the board but it didn’t make any difference, so there’s more to it than that and I don’t know enough about the module structure to go any further myself. I did find one file that defined the flash size as 96k (0x18000) but not know what other dependencies there might be I was hesitant to change that value. The file I looked at is in the supervisor directory, internal_flash.h wherein is has “INTERNAL_FLASH_FILESYSTEM_SIZE set to 0x18000 (96k) but I don’t know what’d happen if that were changed to 0x200000 (2mb)…

[johncblacker]

Just for grins, I made a change in the internal_flash.h file for the 767zi changing the size from 0x18000 to 0x200000, rebuilt, flashed to board, checked size and it was still around 80k – so that didn’t work!

[k0d]

I'll look into this a bit later today....

[hierophect]

@johncblacker I would not expect anything using FLASH_APP in the linker to work, that's a Micropython name and we don't use it. Linker flash sections will need to match our existing definitions, and there may be additional work that needs to be added to the flash buffering system.

Also, just a gentle heads-up: whatever email client you are using for Github is inserting all kinds of weird whitespace and a massive signature into your messages. It's not a big deal for me to edit them down so they're readable, but it might be something to look into.

[tannewt]

Just for grins, I made a change in the internal_flash.h file for the 767zi changing the size from 0x18000 to 0x200000, rebuilt, flashed to board, checked size and it was still around 80k – so that didn’t work!

You'll also need to recreate the file system after changing the space for it. If it starts in the same place, then it will just use the existing smaller file system. You can do storage.erase_filesystem() from the REPL to recreate it.

[johncblacker]

That worked…now when I right mouse click on the cPy drive, I see 2MB. Did an os.statvfs(‘/’) and here’s what I get:

>> os.statvfs('/')

(1024, 1024, 2028, 2021, 2021, 0, 0, 0, 0, 255) Looks good to me…how about you?