search

newaetech / sonata-rp2040

rp2040 firmware for Sonata
BSD 3-Clause "New" or "Revised" License
3 stars 3 forks source link

Bitstream reload on switch change #16

Open HU90m opened 1 week ago

HU90m commented 1 week ago

It would be really nice if the rp2040 could reload the bitstream whenever it notices a the bitstream switch change.

GregAC commented 1 week ago

I wonder if we can use the rp2040 boot switch (SW9 the one you hold on power up to get RP2040 virtual USB firmware load) as a reload button? I worry about just reloading on the switch being changed as it's possibly too easy to do by accident and/or is a slightly surprising behaviour.

SW9 is connected to one of the QSPI pins (for the flash that holds the rp2040 firmware) however the datasheet states 'These pins can also be used as software-controlled GPIOs, if they are not required for flash access.'. So I wonder if the firmware could go into an idle mode where it's executing out of SRAM with the flash interface disabled polling the state of that button/watching for USB activity then when it sees a press or sees something on the USB turns the flash back on and execute whatever is needed.

Fiddly perhaps but I think better UX.

GregAC commented 1 week ago

As an alternative we could have the FPGA signal the rp2040 when it sees the reset button is pressed we have some GPIO connected to the FPGA for this very purpose. Though I think there's value in a system reset that doesn't reload the entire FPGA. We could do something slightly fiddly like joystick pressed when reset is pressed reloads the FPGA.

HU90m commented 1 week ago

Good ideas, added this to the next sunburst meeting for discussion

alex-dewar commented 6 days ago

IMO the best way to take over the QSPI pins would be to just load the entirety of the firmware into SRAM. The firmware's more than small enough and it saves any potential issues with users pressing the RP2040 boot pin while it's executing out of flash. It also saves having to figure out which functions need to be in SRAM and which can go into flash.

I don't think it would be too bad to do. It is much higher effort than simply reloading the FPGA on a pin toggle though and I'm not sure what sort of time I'll have to work on it in the near future.

colinoflynn commented 3 days ago

Discussion from meeting:

Seems best plan is to use selector switch change to reload. Logic should be roughly that when a switch change is detected, wait a short time to see "final" position and then reload that position. Make sure LEDs match actual loaded bitstream at all time (and not just position).

So something like switch changes - > LED off - > small delay -> read position, reload bitstream, set LED

Allows toggling switch quickly to "reload" same bitstream without loading an intermediate setting by accident. The LED now always matches the running bitstream and not the switch setting (since the programming uses an offset anyway, and not the switch position as it used to, the switch position is somewhat irrelevant).

Let me know if I captured this correctly?