Gregory's Serverfirst, since i always seem to do stuff the hard way, i designed a board from scratch for the 2350. i call it the Rotten Pi 2350[A] mostly because i threw it together in a huge hurry two weeks ago.
|
58 comments
 then, i built my own curve tracer on a breadboard. i'm driving a sawtooth waveform from my Rigol scope through a 1K sense resistor, and this chip amplifies the voltage drop and runs it into channel 2. channel 1 goes to the downstream side of the 1K resistor so the voltage is accurate. i have a pico 2 that i loaded with the "debugprobe" app and connected it to the Rotten Pi. i need to do this to directly program the GPIO control registers. here is the complete configuration. the curve tracer is tied to GPIO0 and, using the debugprobe, i can turn the pullup or pulldown on and off and observe the results on the scope. when you power up the chip without loading any software, the pulldown resistor is turned on by default so you can see it sinking current here. there's a very odd peak as you cross above VDDIO + 0.3V which makes me think there is an internal diode. above that, i think the fault tolerant circuit kicks in and the current goes back down again. if you turn on the pulldown, the whole curve shifts up a bit, which is expected. the "glitch" is still there, trying to source current, but part of that current is canceled out by the pulldown. if you turn on the pullup resistor, it shifts the whole curve down (also expected). the flat part is the measurement limit of my quick-and-dirty curve tracer, not the chip. well this is weird, you can turn on the pullup and pulldown at the same time! you get this strange effect where the pulldown takes effect at low voltages and the pullup takes effect at higher voltages, after the glitch. i wonder if this is related. 🤔 the glitch is affected by the Schmitt trigger setting. this tells me that whatever circuit is sourcing current out of the pin depends on the state of the input *after* the first input buffer stage. when i turn off the IE bit (input enable), the glitch goes away completely and the pullup/pulldown modes behave correctly. when both pullup and pulldown are turned on, the pulldown takes priority. so with VCCIO running at 1.8V, the glitch is only around 30uA. in general, the lower the VCCIO, the smaller the glitch. anyway i did this whole experiment because i'm investigating the 5V tolerance. the little spike at VCCIO+0.3V is my current focus. note that the leakage current goes up to about 3uA on the other side of the spike.  @tubetime Quite interesting stuff. They removed the mention to 5V tolerance from the datasheet IIRC, so maybe they're not very convinced it will work. @tubetime Oh you're right. They removed some references though (about that and the 10 uA DVDD sleep mode) here's the voltage sweep around the little spike and all the way up to 6.4V (!) you can see the ESD clamp kicking in at around 6V. it is a Zener-style clamp, so it doesn't depend on VCCIO. the trick to this measurement is to set the voltmeter in high impedance mode (1GOhm) instead of the usual 10Mohm mode which would pull too much current and throw off the measurement oh this is odd, when VCCIO=1.8V and the pullup is on, the GPIO pulls 150uA at 3.8V but then it drops again. (abs max is 3.63V so we are in uncharted waters) @tubetime They are, in fact, not in uncharted since you just posted a chart? I'm going to leave it this way at least overnight and see how it goes. 5V on GPIO0 with no voltage on VDDIO (which is sitting at around 150mV due to some back bias leakage)   @tubetime shouldn't the protection diodes bring it almost all the way up? the results? a *very slight* change in the curve trace. but it's basically identical, you could handwave this away with a temperature difference between the two sets of measurements. somewhat more concerning is that the threshold (vih) of the pin has shifted up by about 50mV. ~1.36V -> 1.41V. EDIT: i measured it again with the curve tracer instead of directly with the voltmeter/ammeter combo, and it appears to be identical to the other GPIO pins. it's tricky to measure the threshold with the source current bug affecting the measurement. hmm, there does seem to be an effect on the Schmitt trigger circuit. GP0 has a lower falling threshold than the other pins when Schmitt trigger mode is turned on. i'm thinking about the effects of hot carrier injection (HCI), which usually causes the threshold voltages to shift. then there's also negative bias temperature instability (NBTI). both of these could cause timing issues. to sum up the results so far: beating the crap out of this GPIO pin, taking it up to over 6V, letting it sit at 5V for 24h, etc, has resulted in a tiny shift in the falling threshold with Schmitt trigger mode turned on. no functional changes. the next step is to write a little PIO program to copy the input state of the pin to another GPIO configured as an output. and then i can start measuring timing. or maybe copy the state of two pins so i can do a side-by-side comparison. the program is written: and the propagation delay data is in. i increased persistence. as expected, the variation in the delay is approximately 6.6ns which is one sysclk cycle. this is the synchronization time. minimum delay is 36.4ns which seems long--i'm going to try and figure out why. ahh, they have a 2-flop synchronizer on each input to the pio. but there's a way to disable them on a per-pin basis. i halved the sysclk, so now we have a variability of 13.2ns and a minimum delay of 35.2ns. did a little math and it looks like there is a 2 sysclk delay plus the input propagation delay and output propagation delay. the prop delays total about 8.8ns. hmm so i understand why there is 1 sysclk delay because it takes a cycle to go from the WAIT instruction to the SET instruction. but why 2 sysclk delays? anyway i can overclock to 300MHz sysclk, and now the minimum delay is 15ns. that is 2 cycles of 3.3ns plus 8.4ns propagation through the input and output. argh, i forgot that i put 20MHz BW on the two input channels. anyway, this looks better, the rise time is super fast and the propagation delay is 13.7ns. all right, i'm going to run another 24h aging experiment with 5V on the unpowered pin. let's see how it does. i'll do the measurements at 150MHz. my suspicion is that hot carrier injection could increase the propagation delay of the input, but we shall see. i could dig into this some more, but for now, it looks like the RP2350 is 5V tolerant. i didn't see any evidence of HCI or metal migration. these aren't exhaustive tests since i didn't do them over the full supply voltage and temperature range, so i wouldn't use it for 5V tolerance in a commercial project, but this should be fine for hobby projects. @tubetime Sorry if you already said it and I lost the info, but did you test only on FT pins or also no non FT pins?  @tubetime now do the RP2040, that one is a bit more of an open question 😅  @tubetime excellent, this means we can work around this by running it at 0V @grishka the connector is terrible, the PCB layout tolerances are really tight, and the connector is hard to solder. @tubetime lol at "magical misery inductor." it's such a weirdly precious part they want you to use. @polpo i'm not using their recommended part, this is just a plain old inductor from Mouser.  @tubetime I just noticed the text, "Fake DVI - not HDMI for legal reasons". Shared it with some friends and we're all chuckling at that one!  @tubetime I made this layout you might be interested in, which is designed to be assembled by JLCPCB |
(i did the layout on a Twitch stream but I forgot to turn on VoD, sorry about that.)