Gregory's Serverthe 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
|
29 comments
@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 😅  |
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)