PicoBoot
PicoBoot copied to clipboard
webhdx
Bus contention on data line
The installation guide indicates that the data output line of the Pico is directly connected to pin 9 of the IPL chip - ie the SPI output.
And reading through the code, it seems the approach currently in use is to intentionally cause bus contention when injecting data, using two GPIO pins in parallel to drive enough current to overpower the IPL’s output.
As it is essentially shorting the two signals together, doesn’t this risk damaging the IPL in the long term? An alternative approach would be to lift pin 9 and have the signal pass through the pico before going to the processor, multiplexing between the actual IPL code and the injected data in software.
I apologise in advance if there is some factor I’m overlooking that causes this to not be an issue, but I thought I’d try to get some clarification before committing to the mod on my hardware.
I’ve also been curious about this same issue as this seems to be a key differentiator compared to previous mods. It also explains why so many issues are caused by long wires or insufficient thickness - not enough current to override the bus.
I’ll be following this issue with interest!
This is fully intentional. The same principle made some older IPL modchips work: ViperGC, QoobSX/Pro, HyperBoot. They all overpowered RTC-DOL chip to avoid lifting MISO pin. I've never heard about broken console due to modchip install in the past 20 years. Lifting a pin is definitely safer from electrical standpoint but I guarantee you we'd see a lot of consoles with broken legs on U10.
Also I can't stress this enough - I don't take any responsibility for the damage done by PicoBoot: https://github.com/webhdx/PicoBoot#i-installed-your-modchip-and-now-my-console-doesnt-work
Understandable. I suppose it’s a bit of an unavoidable tradeoff between electrical separation and ease of installation.
I’ve done some continuity probing on a DOL-101 board, and found that the pin in question leads directly to the CPU, without any convenient places to separate the signals. There is an exposed via, but it’s a much smaller soldering point, and the trace runs very close to other data lines, making cutting it risky.
Perhaps the ideal solution would be to remove the IPL chip from the gamecube board and add an interposing daughterboard to break out the various signals, but I understand that would go against the low cost nature of the project.
Either way, thank you for the prompt response!
I’ve also been curious about this same issue as this seems to be a key differentiator compared to previous mods. It also explains why so many issues are caused by long wires or insufficient thickness - not enough current to override the bus.
I’ll be following this issue with interest!
are there any guidelines on wire length/gauge?
Keep it at reasonable 10-15cm length, 28 AWG for data and 26 AWG for 3.3V and GND and you should be good.
I'll just weigh in on this and shed some light on how this all works to begin with.
An input pin is generally connected to the gate of a transistor. It is a current sink. An output pin is generally driven by two transistors. One for the high state, a current source. One for the low state, a current sink.
So what we're doing when we're ganging multiple pins together to "overpower" the output from the ROM chip is really this:
- When both outputs are in the same state, nothing unusual happens. Current only flows when there's a potential difference ("voltage").
- When the ROM chip outputs high, and PicoBoot outputs low, the two outputs on the Pico can sink more current than the ROM chip can source, which prevents the input gate on the Flipper from charging, so it sees a low level.
- When the ROM chip outputs low, and PicoBoot outputs high, the two outputs can source more current than the ROM can sink, so the input gate on the Flipper gets charged, and it sees a high level.
Keep in mind that all this hardware will only ever source and sink as much current as it is designed to, because IO pins generally have current limiting resistors built into them. Since we're not overvolting the circuit, current flow is nominal, so it's perfectly safe.
Additionally, PicoBoot disables itself once the payload has been injected. This means that for a 2MiB payload at 27Mbps, it is only active for less than 80ms. Even less considering the payload is actually more along the lines of 150KiB.
I hope this helps.
@9ary Thats pretty informative, thanks a lot. Helps a lot to understand what really is happening ❤️ Even tho for some this might be "obvious", at least for me it is not. This would be a nice candidate for a FAQ-entry.
It's not all that obvious. I've made my own IPL replacement modchip before but at the time I couldn't have explained how this trick actually works. It just comes with experience when working with electronics.
I’ve also been curious about this same issue as this seems to be a key differentiator compared to previous mods. It also explains why so many issues are caused by long wires or insufficient thickness - not enough current to override the bus.
I’ll be following this issue with interest!
I just saw this message so I'll address this as well.
The currents involved are measured in single digit milliamps, low 10s at most, so you can actually get quite thin with your wires.
Wiring issues are much more likely to be signal integrity problems than current problems.
To mitigate these, keep your wires short and equal in length, run the ground close to your data lines, make sure you use a ground pin on the pico that's close to the IO pins as well. The Pico is actually nicely designed for signal integrity so there's plenty of ground points. You can even add a second ground wire to be safe.
why not just lift the IPL pin and put a resistor in series to limit the current draw - maybe 100ohms
That's really unnecessary and from experience it's very likely that you'll rip the pad off the PCB doing that. Just stick to the recommended install or use one of the known alternate points. It's safe.
well to correct my last comment anyway, to limit the current to a level that wont stress the pi or the IPL you would need 330 or 470ohms (10ma / 7ma limit) personally i wouldnt rip the pad, i could even lift the chip to lift the pin - but i know people will be trying to install this with a $10 soldering iron and no experience other than utube!!
As I wrote above, current limiting resistors are already built into the silicon. There is no point in adding external ones.
The currents involved are measured in single digit milliamps, low 10s at most, so you can actually get quite thin with your wires.
Wiring issues are much more likely to be signal integrity problems than current problems.
To mitigate these, keep your wires short and equal in length, run the ground close to your data lines, make sure you use a ground pin on the pico that's close to the IO pins as well. The Pico is actually nicely designed for signal integrity so there's plenty of ground points. You can even add a second ground wire to be safe.
Thanks for confirming this, and your thorough explanation. I assumed that’s what was going on but couldn’t find anything in the repo that specifically stated it. Good call on the wire usage too - I would imagine an inappropriate mod would have 20-30 inches of wire rather than the minimum recommended. I also agree with @FibreFoX - this would be an excellent addition to the FAQ!