#CircuitPython Build for Custom RP2040 Board

1 messages · Page 1 of 1 (latest)

silver wharf
#

Probably should have done a thread initially.

honest saffron
#

i did also recently build circuitpython for the normal pico rp2040, might be able to help some

silver wharf
#

It took me into vim and I was a bit confused

green sorrel
#

@silver wharf Oh right! That's a setting that can be changed. I'd have to look up where, but you can tell it to use Nano by default if you would prefer.

silver wharf
#

It is: git config --global core.editor "nano"

#

Guide is quite good though

honest saffron
#

ive always used $EDITOR

#

that one also affects other programs

green sorrel
#

Fair enough. I use Vim because I know only enough to do what I need.

#

@silver wharf The other thing is that if you do git commit -m "Commit message." the editor never shows up.

#

You really only need git commit without -m if you need to put in a long message under the "title".

silver wharf
#

Oh that is pretty neat, thx!

green sorrel
#

You're welcome!

silver wharf
green sorrel
#

Oh!

#

I didn't realise that's the guide you were using.

#

Please click the "Feedback? Corrections?" link at the bottom left of the page listing on that guide page, and leave feedback regarding the update needed, if you don't mind. 🙂

silver wharf
#

Sure, thanks and I don't mean to bug you!

green sorrel
#

You're not bugging me. I check on Discord every so often.

silver wharf
#

What you linked references what I was using as one of the first steps.

green sorrel
#

Oh ok good!

silver wharf
#

So good news, I was able to (apparently successfully, though not actually tested on a board) build CircuitPython via:

image.png
#

However, the bad news is that when I tried to build for a RPi Pico, I got some discouraging feedback:

image.png
# 
jeremycook@Jeremys-MBP boards % cd ..
jeremycook@Jeremys-MBP raspberrypi % make BOARD=raspberry_pi_pico
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
supervisor/internal_flash.c:35:10: fatal error: genhdr/flash_info.h: No such file or directory
 #include "genhdr/flash_info.h"
          ^~~~~~~~~~~~~~~~~~~~~
compilation terminated.


^Z
zsh: suspended  make BOARD=raspberry_pi_pico
jeremycook@Jeremys-MBP raspberrypi % pre-commit install
pre-commit installed at .git/hooks/pre-commit
jeremycook@Jeremys-MBP raspberrypi % make -C mpy-cross
make: *** mpy-cross: No such file or directory.  Stop.
jeremycook@Jeremys-MBP raspberrypi % make BOARD=raspberry_pi_pico
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
QSTR updated
GEN build-raspberry_pi_pico/genhdr/qstrdefs.generated.h
Module registrations updated
../../py/gc.c: In function 'gc_sweep':
../../py/gc.c:318:68: error: 'MP_QSTR___del__' undeclared (first use in this function); did you mean 'MP_QSTR___new__'?
                         mp_load_method_maybe(MP_OBJ_FROM_PTR(obj), MP_QSTR___del__, dest);
                                                                    ^~~~~~~~~~~~~~~
                                                                    MP_QSTR___new__
../../py/gc.c:318:68: note: each undeclared identifier is reported only once for each function it appears in
make: *** [build-raspberry_pi_pico/py/gc.o] Error 1
jeremycook@Jeremys-MBP raspberrypi %
green sorrel
#

@silver wharf See this message for formatting codeblocks. You can also edit existing messages if you want to fix the one you posted. #welcome message

silver wharf
#

If you have any insight into where things might be getting bogged down here, that would be appreciated.

green sorrel
green sorrel
#

I think mpy-cross is in a different directory also.

silver wharf
#

mpy-cross may be a problem - do I have do to it in that directory?

green sorrel
#

No, you do it overall, I think.

#

I think it fails when trying to use mpy-cross though, not on something else. 😕

silver wharf
#

Hmm, worked with the circuitplayground_express apparently

#

why would it fail for the RPi?

green sorrel
#

Definitely because they require different things. That said, I'm going to tag in the core dev that's around today. Unfortunately I think we've reached the end of my ability to help.

#

Scott is at lunch, but I'll tag him here so he might be able to take a look if he has time.

silver wharf
#

Cool, well I appreciate it!

green sorrel
#

@glad hazel If you have a moment to take a look at this compile error, it would be greatly appreciated. I'm out of my wheelhouse at this point. #1143997801274015774 message

honest saffron
#

is something supposed to generate genhdr/flash_info.h, or is that something your meant to create?

silver wharf
#

Is something supposed to generate it? Not AFAIK
Meant to create? No, but should I have?

honest saffron
#

maybe just delete the #include "genhdr/flash_info.h" line?

#

supervisor/internal_flash.c is meant to provide a few functions, for accessing the drive where code is stored

# 
void supervisor_flash_init(void);
uint32_t supervisor_flash_get_block_size(void);
uint32_t supervisor_flash_get_block_count(void);
void port_internal_flash_flush(void);
mp_uint_t supervisor_flash_read_blocks(uint8_t *dest, uint32_t block, uint32_t num_blocks);
mp_uint_t supervisor_flash_write_blocks(const uint8_t *src, uint32_t block, uint32_t num_blocks);
#

ah, but your on the rp2040

#

so it should be the standard stuff, disable XIP, issue a cmd, re-enable XIP

#

so, what is that header doing..

#

./ports/raspberrypi/build-raspberry_pi_pico/genhdr/flash_info.h

#

there is a copy in my build dir, which means it was auto-generated during the build

#

by ports/raspberrypi/Makefile

#

and gen_stage2.py

silver wharf
honest saffron
#

try make BOARD=raspberry_pi_pico V=2

#

i think you dont want to delete it, having read more

#

what does the build say, with V=2?

silver wharf
#

just a sec

#

Wow, quite a bit of "feedback"

honest saffron
silver wharf
#

there is no flash_info.h file in that directory

honest saffron
#

what about make BOARD=raspberry_pi_pico genhdr/flash_info.h V=2 ?

silver wharf
#

no

honest saffron
#

what did that output?

silver wharf
#

sorry misunderstood, will try

# 
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
make: *** No rule to make target `genhdr/flash_info.h'.  Stop.
jeremycook@Jeremys-MBP raspberrypi % ```
#

Hopefully I ran that out of the correct directory

honest saffron
#

what does pwd report?

silver wharf
# 
/Volumes/CircuitPython-Dev/circuitpython/ports/raspberrypi```
honest saffron
#

yeah, i would expect that to just work

#

is flash_info.h mentioned in ports/raspberrypi/Makefile ?

silver wharf
#

let me look

#

yes it is

honest saffron
#

can you paste the lines around it?

silver wharf
honest saffron
#

should be a block of 3 lines

silver wharf
#

just a sec

honest saffron
#

yep, identical

#

it feels like your make is not following the rules

#

oh, wait, i forgot part of the path

silver wharf
# 
    $(STEPECHO) "GEN $<"
    $(Q)$(PYTHON) gen_stage2.py $< $@ $(EXTERNAL_FLASH_DEVICES)

$(BUILD)/supervisor/internal_flash.o: $(HEADER_BUILD)/flash_info.h```
honest saffron
#

make BOARD=raspberry_pi_pico raspberry_pi_pico/genhdr/flash_info.h V=2

#

try that?

silver wharf
#

k

# 
make: *** No rule to make target `raspberry_pi_pico/genhdr/flash_info.h'.  Stop.
jeremycook@Jeremys-MBP raspberrypi % ```
honest saffron
#

not sure then, will need another mac user

silver wharf
#

It's OK, thanks for trying.

glad hazel
#

whenever you get a qstr error, try doing a clean and building again

silver wharf
#

OK, I'll hack around a bit more, thx. What seems strange to me about this is that I've just started trying to do this sort of thing, so one wouldn't think things would be too off.

glad hazel
#

ya, case sensitive is important for some ports

silver wharf
# glad hazel ya, case sensitive is important for some ports

Am I missing something here?

- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
rm -rf build-raspberry_pi_pico 
jeremycook@Jeremys-MBP raspberrypi % make clean                        
- Verbosity options: any combination of "steps commands rules", as `make V=...` or env var BUILD_VERBOSE
rm -rf build- 
jeremycook@Jeremys-MBP raspberrypi %
glad hazel
#

@silver wharf It looks like the first one worked

#

I tend to do BOARD= before clean but I think either should work

silver wharf
#

I don't get an error per se, but shouldn't I get an output to the effect of:

image.png
#

If I then run: BOARD=raspberry_pi_pico make, I get the following, plus quite a bit of stuff after.
```- Verbosity options: any combination of "steps commands rules", as make V=... or env var BUILD_VERBOSE
supervisor/internal_flash.c:35:10: fatal error: genhdr/flash_info.h: No such file or directory
#include "genhdr/flash_info.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.

glad hazel
#

I think someone else saw that issue too

#

can you run the build with V=1?

glad hazel
#

just merged the fix

#

so pull the latest and it should work

silver wharf
#

Cool, thx will try!

#

To ensure I've done this correctly, from the main branch, I enter "git pull" correct?

#

Well seems "make BOARD=raspberry_pi_pico" is doing something, though it is certainly taking its time to think. Maybe that is normal.

#

Well it generated the file and it seems to work as firmware, so looks like a success. Thanks so much for your help on this @glad hazel @green sorrel & @honest saffron ! 👍 💪

honest saffron
#

ah, i would never have guessed it was qstr related

green sorrel
glad hazel
#

the first build tends to be longest because it builds everything. after that, it'll only do what has changed

green sorrel
#

@silver wharf Hey we have a circuitpythonistas role here on Discord, if you'd like to be added to it. We use it to notify folks about our weekly community meeting. Also, we do a weekly community meeting. 😄 It's held on Discord on Mondays at 2pmET, except when it coincides with US holidays, such as next week, when it will be on Tuesday. You're welcome to join us and listen in, or participate. That Discord role gets pinged twice a week usually, once before the meeting, and once after for the link to a notes doc where folks put their updates for the next meeting. This is completely optional! I simply wanted to let you know.

#

Reply or ping me if you decide to reply. That way I'll see it. Thanks!

silver wharf
green sorrel
#

I'll add you now!

#

Also your name now shows up purple. 😉

silver wharf
silver wharf
#

Customizing my board to use 16 MB of FLASH as that's the chip I'm using. I seem to have succeeded, subbing in a Winbond chip per below:

USB_PID = 0x80F4
USB_PRODUCT = "Pico"
USB_MANUFACTURER = "Raspberry Pi"

CHIP_VARIANT = RP2040
CHIP_FAMILY = rp2

EXTERNAL_FLASH_DEVICES = "W25Q128JVxQ"

CIRCUITPY__EVE = 1
CIRCUITPY_PICODVI = 1

But wow, USB 1.1 or what have you is really slow. I mean I knew it was, but I thought I'd done something incorrect. I assume this is just the limits of the RP2040? Maybe there's some way to make it better?

#

Or maybe I need to re-adjust my Flash usage down?

honest saffron
#

its a full-speed usb phy, which runs at 12mhz

#

under ideal conditions, and ignoring protocol overheads, that would be 12mbit

#

there are also limits to programming the flash and erasing it

#

over there, i wrote an rp2040 flash benchmarking tool

silver wharf
#

12mbit/s doesn't seem that bad - seems like it took somewhere around a minute to copy ~4MB

honest saffron
#

it will benchmark how long it takes to erase and program chunks of the flash

silver wharf
#

Hmm, OK thanks - so maybe I'm running into a flash limitation?

honest saffron
#

which is between 9142 and 82,248 bytes per second

#

9142 bytes/sec is the worst case rate for programming the flash

silver wharf
#

Well that is quite a difference!

honest saffron
#

82,248 bytes/sec is based on the typical program and erase times from the spi flash datasheet

silver wharf
#

Hmm, well I have some research to do

honest saffron
#

this claims 150ms to erase 64kb

#

and 0.4ms to program 256 bytes

# 
single erase took 5262908
2 mb erase done in 32 blocks of 64 kb
164465 uSec per block
#

my benchmark util measured 164ms to erase 64kb

#

single 256 byte write, 598 uSec

#

and 0.59ms to program 256 bytes

#

slightly slower then the quoted typical

honest saffron
silver wharf
#

OK, thx I'll do a bit of digging

#

In other news, know of any documentation around renaming pins? Assuming you edit pins.c, but would be nice to see a guide.

honest saffron
#

pins.c is all i know of

silver wharf
#

OK, thx

honest saffron
#

ah, and my benchmark isnt tuned for circuitpython

#

the pico-sdk does erase in 64kb chunks

#

which is far slower

silver wharf
#

Hmm

honest saffron
#

a 4kb erase typically takes 45ms, giving you 11.25ms per kb

#

while a 64kb erase typically takes 150ms, giving you 2.34375ms per kb

#

but doing 64kb erase's, would require a filesystem that co-agrees with that, and now you would need to swap out fat

#

or have a smarter write cache and block allocation

#

due to that design issue, erasing blocks takes 4.8 times as long

silver wharf
#

So we are talking somewhere on the order over a minute per MB?

honest saffron
#

hmmm

silver wharf
#

Actually that seems too long for my limited experience.

honest saffron
#

256 bytes can be programmed in 0.4ms typical
so 1024 bytes would be 4x that, 1.6ms

#

plus the 11.25ms per kb to erase

#

gives you 12.85ms per kb, to erase and program

#

or 77.82kbyte/sec

#

compared to 80kbytes/sec if you had done 64kb erase

silver wharf
#

Hrmm

honest saffron
#

with a far smarter fs, designed for flash, you could pre-erase blocks, and then you can get 625kb/sec

#

it may be possible to hack that ontop of fat with some effort

#

which is about half of full-speed usb

#

oh, and the UF2 format the rp2040 uses, wastes half the usb bandwidth!

#

so those numbers are somewhat in perfect alignment

silver wharf
#

Doing a bit more testing, flashing the UF2 file takes a number of seconds, but transferring the same file with a different extension seems to take more than a minute.

honest saffron
#

UF2 is sort of a hack to send commands to a usb device without root and without sepcial drivers

#

each 512 byte block of the uf2 file is a single packet
each packet contains 256 bytes of data to program to flash

#

so there is 50% overhead in the uf2 file

#

the rp2040 bootrom is a very cheaty fat fs, it basically ignores all writes, but will check each sector for a UF2 header, and do what the UF2 packet said

#

the circuitpython fat is more intelligent, and somehow allows 2 kernels (usb host and circuitpython) to share a single fs, i'm not sure how

silver wharf
#

Hmm

honest saffron
#

oh, and i just realized, i was getting some of the above figures mixed up

#

circuitpython using 4kb erase and stuff, only applies when circuitpython is running

#

so it has no impact on copying the uf2 over when in the rom

silver wharf
#

I build CircuitPython for my board, customized a few things, and all seemed well, but when I try to import adafruit_midi it tells me I have an incompatible .mpy file:

code.py output:
Traceback (most recent call last):
  File "code.py", line 9, in <module>
ValueError: incompatible .mpy file

Code done running.

Press any key to enter the REPL. Use CTRL-D to reload.

Adafruit CircuitPython 9.0.0-alpha.1-16-g0a1842e3e-dirty on 2023-09-01; Raspberry Pi Pico with rp2040
>>> ```
#

Could this have something to do with that I'm building for version 9 of CircuitPython apparently @glad hazel - if so is there alpha bundle I can/should be using?

silver wharf
#

I tried using: adafruit-circuitpython-bundle-py-20230829.zip
Which seems to avert the incompatible error, however, now the debouncer library is giving me grief about adafruit_midi not being defined:

  File "code.py", line 27, in <module>
NameError: name 'adafruit_midi' is not defined

Code done running.

Press any key to enter the REPL. Use CTRL-D to reload.

Adafruit CircuitPython 9.0.0-alpha.1-16-g0a1842e3e-dirty on 2023-09-01; Raspberry Pi Pico with rp2040
>>> [D```
silver wharf
#

I seem to have made some progress using the -py bundle after doing a nuke and reinstalling my build of CircuitPython

#

Seems I have a misnamed pin though, so still have some debugging to do

silver wharf
#

...And I soldered in a pair of surface mount resistors at 90 degrees. Seems the journey never ends!

silver wharf
#

So I seem to be getting the hang of things, but on my RP2040 build my renamed pin 29/GPIO18 doesn't seem to be working in a capacitive touch role (says I need a resistor). I believe I have my resistor correctly installed here, and the other pins I've tested work. Is there anything unique about this pin?

#

Or any other ideas? Certainly possible that pad is not connected/connected well.

glad hazel
#

@silver wharf you'll want to use the py bundle for main until we make 9.x mpy files

#

we have one more micropython merge to do before we're ready to do that

silver wharf
glad hazel
silver wharf
#

Fooling around with this issue more, I attempted to desolder and reattach the RP2040. Now my computer recognizes it as an RP2040, but does not let me flash a .UF2 or anything else apparently. Any guesses as to what I damaged?

honest saffron
silver wharf
honest saffron
#

then its probably errors with the qspi, you would need to poke around with picotool, try flashing and dumping it and see what happens

silver wharf
#

Hmm, thanks

silver wharf
#

So FWIW, I did not use Picotool (though need to explore this). Replaced the flash chip and resoldered a few bits and now is working!

#

Also Pin 29 seems to be working @glad hazel - still a bit of a mystery. I did re-seat (if that's the correct terminology) the RP2040 chip so that could have something to do with it.

#

So mostly YAY!
But a little bit yay???

silver wharf
#

Returning to this project, with a new version of the board. Mostly the same, but attempting to use a W25Q32JVSSIQ memory chip rather than the W25Q128JVSIQ I was using before.

RPi shows up, allows me to flash it with firmware, then doesn't show up again unless I do the reset button. So it SEEMS to be storing something. I changed the mpconfigboard.mk around as shown below and recompiled.

So is there something I am doing wrong here, and/or is there something off about how this particular memory module compiles. Or might something else not be correct?

USB_PID = 0x80F4
USB_PRODUCT = "Pico"
USB_MANUFACTURER = "Raspberry Pi"

CHIP_VARIANT = RP2040
CHIP_FAMILY = rp2

EXTERNAL_FLASH_DEVICES = "W25Q32JVxQ"

CIRCUITPY__EVE = 1
CIRCUITPY_PICODVI = 1
#

What is interesting is that when I flash an older board with this firmware, it still says it has ~16MB of memory even though I put in the 32mbit version which should be 4MB. Does this mean I'm not compiling it correctly?

image.png