Problem with Photon and Grove I2C Motor Driver

So I’ve now spent hours reading all kinds of Forum discussions of Photons and Motors but it does not appear that anyone has tried this one yet. I’m working on a hydroponic control system that uses many motors (circulation, dosing, valves, etc) so I need to use i2C in order to connect them to the limited number of pins on the Photon. The Motor Driver ( seems to be pretty nice but I get no joy when I connect it via the Photon Grove Base to a Photon. i’ve now spent 2 days reading everything on this forum and various I2C specs and such with no joy. Any guidance or insights extremely welcome.

@Mattster, looking at the schematics for the board, I noticed there are not pull-up resistors for the I2C lines. You need to add a a pull-up (4.7K or 10K) between Vin and each of the SCL and SDA lines on the Photon (ie, 2 resistors).

I tried that with a pair of 4.7K resistors and still no success. I’m running an I2C scan program and it does not find the motor shield even after I added the resistors.

@Mattster can you post a pic of your setup showing wiring and such?

Pictures coming shortly. In the interim it became more mysterious. I tried hooking my pair of resistors (10K now) to 5vdc instead of 3.3 in case the motor controller required 5V to operate. Then I pressed the reset button on the Motor Controller at the end of a failed scan and it immediately detected the board at 0x10 on the next scan. But it didn’t find it on the subsequent scan. I know it picked it up because I changed the DIP switches between tests and it properly found the configured address. Then I moved the resistors back onto 3V3 and it worked fine, again after pressing reset on the slave but did not work on the following scan.

Just an FYI, if the VCC for your motor controller is 5V, that is going to be troublesome to connect it to the Photon I2C lines, since they are 3.3v. In other words if the Atmel processor on that motor controller is running at 5v then is will be an issue.
Check into that first before continuing, Also 10k is to high for reliable I2C, don’t go higher than 4.7k for 5v and 2.2k for 3.3v.

You may need to use something like this if that is the case.

@mikemoy, I2C is agnostic whether you are running 3.3V or 5V logic as long the pull-up resistors are tied to the correct level.
Since I2C only actively pulls LOW but “delegates” the HIGH level to the pull-ups you are good to use 5V I2C devices on a 3.3V µC without level shifting.

1 Like

Photon docs show that no special conversion is needed for 5V even thought the Photon is a 3V3 device as long as the pull-ups go to 5V. I’m curious what is the basis of your assertion that 10K is too high for I2C - all the docs I’ve seen recommend using either 4.7K or 10K.

1 Like

@Mattster, I2C can be finicky and using 4.7K pull-ups with those “longer” wires may be better. Looking at your pictures, I now realize that the only power to the motor board is via the Grove connector which is supplying 3.3v, not 5v. In addition to that, the 3.3v supply on the Photon can’t possibly supply enough current (max 100ma) to power the motor board.

Looking at the schematics, there is a jumper to isolate the 3.3v from the Grove connector from the rest of the board. You will need to power the motor board via the onboard screw terminal connector with 6-15 Vdc supply. Don’t forget to remove the powe supply jumper BEFORE you connect the external supply.

The lack of a proper supply is what is causing your issues. Let me know how things work after you do this.

1 Like

This comes from many years of designing systems. The majority of people never look at the I2C or even SPI lines with a oscilloscope to actually make sure things are ok. They read something online somewhere from another who just guessed and they assume that’s the way to go, never even bothering to read the data sheet on the part to see what it recommends.

Sure, you can try to use 10k pullup, will it work? It might. But then add more I2C devices, longer wire or speed up the I2C speed and i bet it will stop working. The trouble here is slew rate, and to high of a resistor will drastically affect it.

The other issue is people connecting 5v I/O lines from one systems to a 3.3v system. This is just a all around bad way to design something. Proper design is to have the I/O voltages shifted up/down from one system to the next.

For example, a 3.3v processor data sheet says something like pins 3,4 & 8 are 5v tolerant. “tolerant” does not mean one should allow that pin accept 5v all the time. You see inside the IC, they are protecting that pin from exceeding the 3.3V VCC of the processor. Think of it like a 3.3v zeiner diode tied internally to that I/O pin, ya you can give it 5v and the zeiner will keep it below the 3.3v VCC, but at what cost to the life of the part?

@mikemoy, I dare to contradict - again - about the level shifting for I2C.
I²C is (in parts) specially designed for mixed voltage architectures and so are the 5V tolerant pins.

While it’s best to opt for a homogenous design, sometimes you may be stuck without the choice and for that’s perfectly fine to mix 3.3V & 5V on I2C.

BTW, it’s Zener (that’s the correct spelling from C.M. Zener) diodes.


Mixed voltages for I2C was not even a though when they created it as most things out back then were 5v. It was primarily designed to minimize wire signals & allow many multi-drop parts on the same set of wires, unlike SPI where you need a CS line for each part. If one were to take a look at virtually any I2C part data sheet. You will see that the I/O pins vMAX is typically VCC. So that means if your running the part at 3.3v anything above 3.3v that parts pins are going to do one of 2 things, blow the input pin or clamp down. Being that I2C is pulled up by weak resistors the burn out is not an issue, but its going to clamp after 3.3v. Its just bad design practice all around to mix voltages on different subsystems.

The whole part of my rant, was to tell people to start of with good design practices.

1 Like

@mikemoy, I don’t disagree with your arguments though I don’t agree either within the “off-the-self and hybrid platform” context. Nonetheless, can you please take this “rant” as you called it to another topic so as not to pollute the original post. Also, instead of a rant, providing guidelines, links to articles and such would be much more constructive since I believe your comments are important.

1 Like

@peekay123, I have to take some blame for leading this thread off topic too :flushed:

1 Like

My apologies to all


@peekay123: I don’t think it is lack of power supply. This pictures show a test case with a single controller (with no motors) connected directly to the Photon. In the other corner of the board are three more controllers, two of them with motors and one already connected to 12V (with jumper removed).

So as you suggested I have repeated all the tests using 4.7K resistors and I’m still seeing the exact same results on both configurations. When I run the I2C Scanner program it will discover the controller on the first attempt but then can’t find it again on subsequent scans. Unless I press the Reset button on the motor controller - then it will be found (one time only) on the next scan.

Weelllp. The problem is resolved and working correctly and thanks go to @peekay123 and others for identifying the actual problem was no pull-ups on SDA/SCL. Along the way I wandered down a rathole playing with an I2C Scanner program, changing the address DIP switches and forgot to put them back. A quick adjustment of the DIP switch this morning along with the new pair of resistors and it works fine. Except for one strange thing. I had originally pulled the resistors to 5V because the Motor Driver board is a 5V device. It worked fine. I then moved the resistors onto 3V3 and it continued to work correctly.

BTW, regarding the no pull-ups, I had an assumption that the vendor (Seeed Studios) of a plug-and-play-ish system that included both the master (Grove Base for Photon) and the Slave (MotorDriver) would have accounted for the need to provide pull-ups. Was this an unreasonable assumption on my part? Nowhere in their Wiki blog does it say anything at all about pull-ups. And examining the schematics shows there are none.

1 Like

It’s always recommended to check whether or not there are pull-ups on used shields and either add or remove them as needed.
First because I2C is a bus protocol where only one set of pull-ups is allowed, so not each and every I2C device is allowed to add its own set (especially if you happen to mix 3.3V & 5V).
Second, the lack of info about pull-ups might come from the fact that the intended target are Arduinos which already have their pull-ups on-board.


That helps explain. I understand I2C but this was my first time designing with it and the Photon was a natural fit for the app. I was delighted when I found the Grove Base for the Photon because I knew that I2C would allow me to daisy-chain all the motor controllers that I needed. Seems to me that the Grove Base should have the resistors (along with jumpers to disable) just like the Arduino.