search

TinyTapeout / tt-micropython-firmware

TinyTapeout demo pcb's RP2040 functionality
GNU Lesser General Public License v2.1
2 stars 5 forks source link

Not easy to automatically boot to a chosen design if input pins are driven #11

Closed MichaelBell closed 1 month ago

MichaelBell commented 1 month ago

On boot, the demoboard attempts to read the ROM to determine which shuttle file to load. If any inputs are held high, then this fails as the pin control won't assume ownership of those pins. If any inputs are driven low then I think they would have contended access as the SDK tried to read the ROM. Either way - the demoboard then falls back to assuming the chip is TT03p5, and then selecting the user's design fails.

It should be possible to configure the SDK to boot to a chosen design on a chosen shuttle, without attempting to read the ROM, so that startup with some other hardware plugged into the inputs can be done safely.

It looks like ProjectMux already takes an optional argument for the board index file, so I think all that is needed is a key added to the config so that the user can specify which shuttle index to use.

MichaelBell commented 1 month ago

I tried to fix this but there is too much magic!

The globals table creates the ProjectMux automatically so it seems a bit wrong to pass the name in there, but I am struggling to prevent the ProjectMux constructor from automatically reading the ROM.

psychogenic commented 1 month ago

Yeah, I ran into this when testing stuff using the Analog Discovery 3. My solution was to high-Z the DIO prior to reboot, but it was annoying.
Not sure what the best approach is here... do we add an optional "fallback_shuttle" to the ini file? and, in cases where chip ROM access fails, if that option is present, we'd use that?

Or maybe a "force_shuttle" so you could do force_shuttle = tt05 and skip the chip_rom completely.
Basic question is: what do we do when chip_rom fails?

MichaelBell commented 1 month ago

I think a "force_shuttle" option in the config that meant it didn't even try to query the chip_rom would be the best option.

psychogenic commented 1 month ago

Ok, required a bit of changing on the underside to keep things clean (i.e. the project mux class no longer takes a file in the c'tor but a shuttle run, if you were relying on that), but the config now supports a force_shuttle = tt05 and it works well to avoid all the issues with having a board plugged in, driving pins, on boot. Am closing this, if bugs found issue me anew. But seems to work well.