|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
|
I've used the Raspberry Pi Pico for several fun projects related to the ZX Spectrum micro. It works fine, but there's a nagging problem with it which is raising its head again now I'm looking at a project based on the RP2350B (as opposed to the RP2040 which the Pico uses). The issue is the 5V tolerance of the RP2040. It's known that the RP2040 is tolerant of 5V inputs on its GPIOs, as long as certain rules are obeyed. The rule I'm concerned with is this one: GPIO pins ... can accept a maximum of 3.6v without IOVDD being powered This is an important point for retro-computing applications. The RP2040 is tolerant of the 5V signals those machines put out, but not if the retro machine puts a 5V signal on a Pico's GPIO input before the Pico is powered with its IOVDD (i.e. the 3.3V) supply. Is that a problem? Consider the typical use case. I've got an interface hanging out of the back of the Spectrum, and that interface has a Raspberry Pi Pico on it. The Pico is powered from the Spectrum's 5V supply. When you power it all up, the Spectrum's 7805 regulator produces the 5V which goes into the Pico. The Pico has a RT6150 buck-boost regulator which starts up and produces the 3.3V supply for the Pico and RP2040. But what sequence does this happen in? The Z80 in the Spectrum will start up as soon at the 7805 powers it, and will start to produce signals on its output pins as soon as it has got going. Meanwhile, the RT6150 will start up as soon as it gets 5V from the Spectrum's edge connector, and the Pico will start up as soon as the 3.3V is available from the RT6150. Which is all fine, except for this question: What happens if the Z80 comes up sooner than the RP2040? The answer for a Pico-based Spectrum interface would appear to be that the Z80, even when held in reset for a few milliseconds at the start of the Spectrum's power up, will emit a 5V signal onto a RP2040 GPIO pad before that pad is powered with 3.3V, which is exactly what the guidance says shouldn't be allowed to happen. The RP2040 can't handle that and will presumably be damaged. So what does actually happen? Look at this oscilloscope trace: The yellow line is the 5V line from the Spectrum's rear edge connector. It goes up, then down, then up again. I'm not sure why. It could be bounce on the switch I use, but it's very consistent. Maybe that's a feature of the 7805? It probably doesn't matter. The significant point is that 5V is up and stable about 200 microseconds after power up. The purple line is the Pico's 3.3V signal from the RT6150. It takes almost 10 divisions to get up to 3V3, which is 1 millisecond. Which leaves the cyan line, which shows the Z80's MREQ signal (chosen on an arbitrary basis, I think it's going to be one of the first Z80 signals to show signs of life). As you can see, that 5V signal appears (and is applied to the RP2040 GPIO pad) after about 460uS. That means 5V is on the GPIO pad for about 300uS before the pad is properly powered with IOVDD. This is a bad thing! What are the implications of this? Well, it could be that the RP2040 hardware is more resilient to the pad receiving 5V before it's powered with IOVDD than is believed, in which case maybe it's all OK. It could be that the stress this places on the RP2040 doesn't do it any good, but in practise it doesn't do any significant harm. Most Spectrum interfaces probably only power up a few thousand times over their lifetime, and maybe that's not enough to actually damage the RP2040. Or maybe the RP2040 is being damaged, but the consequences of that damage have simply not yet been observed. Maybe I'm worrying about nothing here? Then again, right in front of me I have a Pico with a faulty GPIO pad. Signals on that GPIO can't be read. I don't know how I damaged that Pico. It might be unrelated to any of this. Or maybe not. As a hobbiest I probably won't worry too much about this. But I think if I create something to be sold, I'll not take any chances. I'll either stick with level shifters, or have the Spectrum's power plug go into my interface, and have that chain, under the Pico's control, into the Spectrum. That way the Pico always powers first and will only turn on the Spectrum when the Pico's up and ready. As far as I'm aware the Pico2, which is based on a RP2350A, uses the same RT6150 buck-boost power supply chip, and has the same limitations on 5V tolerance. Thus the same issue will apply to the Pico2. However, the RP2350B based Stamp XL board doesn't have a buck-boost converter, it has a regulator, an ME6211. Unfortunately the datasheet doesn't give its settling time, so I'll have to measure it when I get hold of one. Update: I picked up one of the Stamp XL boards, which features the RP2350B chip with its 48 GPIOs and ME6211 5V->3V3 regulator. I tried to recreate the power up test, and rather struggled with the bounce from the switch I was using. No matter, I learned what I needed to. Here's the trace: The yellow line is 5V from the Spectrum's rear edge connector, as before. It's all over the place, sorry about that. But note the cyan line, that's the 3V3 from the Stamp XL board. It responds immediately the 5V line starts going up, and is at 2V within 50 microseconds of the 5V supply hitting 5V. It then starts to decay as the 5V disappears, but increases again pretty much immediately when the 5V comes back. Even with this silly 5V supply as input, the 3V3 supply is up and available within 250uS of the 5V first appearing. That easily beats the 460uS the Z80 takes to assert one of its control signals. I suspect with a solid 5V supply, the ME6211 would have the 3V3 ready inside 100uS. So the answer to the problem of the Z80 applying 5V to a GPIO input of a Pico before the Pico is powered up appears to be to not use a Pico where the issue might represent a reliability problem. The regulator is too slow. Instead, use a Pico-alternative. The Stamp-XL is one such, there are probably others. Just make sure the onboard regulator comes up fast enough. Derek Fountain, November 2024 |
||||||||||||||||||||||
Site and content Copyright 2023 Derek Fountain - All Rights Reserved |