SpenceKonde
commented
1 year ago digitalRead() and digitalReadFast() use the same methods to read pins, yeah. It's not like there's any other way.
But that does not explain anything: digitalRead() on the MVIO pins is based on the MVIO voltage. That's the whole point of MVIO. The guaranteed high threshold is 0.8xVDDIO2, guaranteed low 0.2xVDDIO2 - just like it is 0.8VDD and 0.2VDD on the other pins. (note that I2C levels are 0.7xVDD and 0.3xVDD (or VDDIO2) - this might be significant, but I would be surprised, and besides, the voltage on the I2C pins should be = VDDIO2 when not actively transmitting data so...
What you should check:
MVIO.STATUS - if this is 1, either MVIO is disabled and the voltage is assumed to be properly supplied to that power pin (they are NEVER connected internally. If MVIO isn't enabled, I didn't see any odd behavior until I got below minimum VDDIO2, at which point with MVIO enabled, they read 0 and all are tristated. With MVIO disabled, but insufficient voltage on VDDIO2, the pins behave unpredictably; this improperly configured operating regime should be avoided
if (!MVIO.STATUS) {
Serial.println("MVIO voltage below minimum required for MVIO!")
}
analogReference(INTERNAL1V024);
analogRead(ADC_VDDIO2DIV10); // trash the first reading for good measure
int16_t reading = analogRead(ADC_VDDIO2DIV10);
// now since you presumably haven't changed analogReadResolution, you can get 1024 different values back between 0V and 1.024v, so each count is 1mv. But the source was already divided by 10, so that's 10mv.
reading *= 10; // now it's in millivolts before the div10.
Serial.print(reading);
Serial.println(" mV");I would expect that if checkPinLevels is returning 0, that the voltage on the MVIO supply rail is under 1.8V or a malfunctioning I2C device is holding the lines low, or that you forgot to install the required pullup resistors. digitalRead() and digitalReadFast() on the pins should give the same answer (well, certainly digitalReadFast should - both that and checkPinLevels read the pins through VPORTx.IN. Now if digitalRead gives one result and digitalReadFast gives another, compare the value of VPORTC.IN and PORTC.IN. They should always be the same. If there not, congratulations, you've found a new silicon bug, welcome to the Microchip Beta Test team.
I2C always needs external pullups. The internal pullups are not, and never have been strong enough. Unlike the official core, we do not turn on the internal pullups automatically (which will work under favorable conditions, short wires, only one or two devices, that sort of thing, hiding the problem in the simple case, while still failing in more complicated cases), because it seems that most of the Arduino community is only vaguely aware of the necessity of pullups. My feeling is that if I2C doesn't have pullups, it should not work, and the best thing we can do in this case is to always fail, so that people will fix it now, when the system is simple, rather than later when they've added stuff and there are far more places to search for problems.
We provide a usePullups method to turn them on anyway - as we state in the documentation, if that fixes any I2C problems, that means you should install external pullups. Relying on the internal pullups that are almost an order of manitude too weak is a recipe for baffling, timeconsuming problems down the road - for example, you might put new wires that are longer on, you rest your elbow on the wire while using the keyboard and that increases the capacitance, or add another device, and suddenly I2C stops working, then works again as you start to investigate. It's a worst-kind-of-bug-to-debug situation.
But if you had to do usePullups() to make it work, then you know that if anything ever happens to that I2C bus, the first thing you should try is installing external pullups (or really, you should then take that line out, and install pullups immediately to prevent future problems, 4.7k-10k is appropriate.
Some breakout boards for I2C devices do have pullups (usually 10k) on them. Not all of them do. This further muddies the water for Arduino-folks.
What voltage do you measure with digital multimeter between ground and the pins in question?
nomakewan
Not sure if there's actually a way to fix this one if I'm right about what's wrong, but going to put it here for reference anyway.
I have an AVR32DB32 running with VDD = 5V, and have MVIO enabled and VDDIO2 is at 2.5V. I use Wire.swap(2) to move I2C over to PC2/PC3 so that they're handled by MVIO. If I use checkPinLevels on this configuration, it always returns low for both data lines. My assumption is that checkPinLevels is just using the same check under the hood as digitalRead, and since 2.5V is less than 3V, it always returns low.
Otherwise Wire works just fine in this configuration. I was just messing around with checkPinLevels to try to set up a fault check for if for some strange reason the opamp were to fail and both take down my slave device's power as well as the power going to the pullup resistors on the data lines.