MicroPython Forum (Archive)

I've got a Pyboard D talking to an Adafruit PN532 breakout board over I2C. It works -- however I have to use a wiring with a pull up resistor on the I2C connection to get it working (although it's not a pyboard in this image, this is the setup I'm using otherwise).



It looks like there is an internal pull up on the X9 and X10 pins. It would be nice not to have to use a physical resistor to get this working -- however I don't know how to activate those internal pull ups or whether I'm understanding this correctly. I tried setting the values on `Pin("PULL_SCL")` and `Pin ("PULL_SDA")` but this did not seem to work. Not sure what to try next, or if this is even possible.

You should be able to use the optional pull-ups (on X) at least. Can you share the exact code you used to set the pins high? (e.g. I always forget to pass Pin.OUT to the constructor).

The internal pullups on the STM chips are unsuitable for I2C as their value is too high. So physical resistors are required somewhere.

The Pyboard 1.x has physical resistors on the board. From a look at the Pyboard D schematics resistors R16 and R17 appear to have this role, but they are annotated "DNP" so I'm not clear if these are actually fitted.

pythoncoder wrote: ↑

Sat Jun 08, 2019 6:52 am

From a look at the Pyboard D schematics resistors R16 and R17 appear to have this role, but they are annotated "DNP" so I'm not clear if these are actually fitted.

I think this might be an earlier revision of the pybd schematic.

So I adopted the last resort of a scoundrel. Experimentation

On my SF2W fitted to a WBUS-DIP28 I checked pins Y9 and Y10. Initially these were hi-z. I then instantiated I2C(2) and they were pulled up to 3.3V. However if I pulled them down with 10KΩ to Gnd the voltage dropped to ~0.67V. This suggests that the 3.3KΩ resistors on the schematic are not fitted and it's relying on the internal pullups on the STM chip.

This is disappointing. The use of switchable physical resistors on the board is something I suggested a few years ago: being able to disable the pullups avoids current being dumped into external hardware when the board is in deep sleep mode. I was pleased to see this on the D series, but if the resistors are not fitted we've taken a step backwards.

Unless, of course, I have an old version of the SF2W.

I've now tested an SF6W bought very recently with the same result.

Lacking a layout drawing I've no means of checking if the resistors are fitted. If they exist perhaps the pins driving them are not driven to 3.3V when the I2C is instantiated.
[EDIT]
I have raised an issue.

pythoncoder wrote: ↑

Sat Jun 08, 2019 8:32 am

On my SF2W fitted to a WBUS-DIP28 I checked pins Y9 and Y10. Initially these were hi-z. I then instantiated I2C(2) and they were pulled up to 3.3V. However if I pulled them down with 10KΩ to Gnd the voltage dropped to ~0.67V.

This is entirely the built-in pull-ups in the STM32. Which is unfortunately all that the board has for the "Y" position.

pythoncoder wrote: ↑

Sat Jun 08, 2019 8:32 am

This suggests that the 3.3KΩ resistors on the schematic are not fitted and it's relying on the internal pullups on the STM chip.

I don't see 3.3kΩ resistors on the schematic. There are 5.6k R16 & R17, which you have to manually enable using machine.Pin.board.PULL_SDA / PULL_SCL. On my SF2W they are populated (they are on the bottom side, to the right of and below the M micropython logo on the silkscreen, sort of diagonally either side of the "eye").

But these are only connected to the "X" position. (I2C 1).

I have verified this using the similar setup (12k to ground on X9, X9 in hi-z mode, and setting PULL_SCL high/low) and got the expected 2.2V and 0V on the multimeter.

What I tried was

Pin("PULL_SCL").value(1)
Pin("PULL_SDA").value(1)
i2c = Pyb.I2C(1, Pyb.I2C.MASTER)
i2c.scan()

However that didn't work where the physical resistors did. I'm not sure how tolerant the PN532 board I'm working with is.

You'll need to put the pull pins into output mode first. e.g.

jimmo wrote: ↑

Sat Jun 08, 2019 10:28 am

...
But these are only connected to the "X" position. (I2C 1)...

Oops. You're right. An odd design decision to omit pullups from I2C 2, especially as it is the one brought out on the WBUS-DIP28.