I have two Grove I2C motor controllers (v1.3b). The addressing on these boards seems broken. If you give them an address other than 0x0F, they don’t listen to speed/direction changes until you press the reset button. If they share the bus with another controller, the board with address 0x0E will listen to the commands sent to 0x0F.
Has anyone successfully used two of these boards and addressed them separately?
Hey @bentwookie,
Welcome to the RobotShop community!
Which of the following are you referring to?
I shall wait on your answer to the question above before commenting further.
Sincerely,
I have the Dual I2C motor driver (RB-See-211).
@bentwookie
Please find below answers to your questions/comments!
Good, it helps to know which one you are having issues with! 
How do you change the I2C slave address, exactly? Please provide as many details as possible. I’m assuming using the DIP switches provided.
The documentation does state the address should be changeable (Changable slave address on page 1), listed as a protocol command (“register function”) with 2 arguments (0x83 on page 4) and with an example function to change the slave address (change_adr page 7).
The manufacturer seems to offer a procedure to update the device firmware and said firmware source code here. After a quick look at it, it seems to always initialize the address to whatever is at PORTC (assumed DIP switch) without any way of changing it to something else from the code since command 0x83 is commented (i.e.: only by physical switch & requires a reset/power cycle).
Check the download above and open the file main.c inside (ZIP)\burn firmware for Atmega8 using ISP\AVRStudio Prj\I2CmotorFV1. You’ll see what commands are processed on lines 235-314. Most of the commands seems to make an appearance (0x82, 0x84, 0xA1, 0xA5, 0xAA) but on line 241 you can see the case for 0x83 is commented. It seems this code would’ve otherwise written the new address to EEPROM to store it between power cycles (the right way to do it) followed by code to re-initialize the TWI slave interface with the new address.
But then if you look at line 178 you’ll notice the function MotorAddSet() being called to initialize the address for the device. Looking at that function (line 158) it seems to always use the 4 lower bits of PORTC (PC0/1/2/3) (as expected, this init code makes no mention of EEPROM values from the (commented) 0x83 command) which are (according to the schematic) connected to the 4 pins of the DIP switch (to GND) and with external pull-up resistors:
Following this, I assume you should be able to change the address by using the DIP switch. See details on how the switches relate to an address here.
Another option (non-trivial) could be to use this firmware from the manufacturer’s product to change the init function and reprogram one of your boards (using an Arduino as an ISP programmer) to use a different (hard-coded) address.
Alternatively, if that is not an option for you (or if any of this does not work) I’d recommend contacting the manufacturer directly for some assistance.
Sincerely,
P.-S.: It seems you also posted on the manufacturers forum here. Hopefully someone gets to it sometime soon. If you did buy the boards from RobotShop then we may have an alternative option of contacting the manufacturer for you. Let me know if that is the case.
This post. You found their code, you found me. I’m…I’m speechless. It’s the most beautiful thing I’ve ever seen. No joke, I’ll never buy another product somewhere else if I can buy it here. I’m floored. Thank you!
Back to the board! I think I’ll try reflashing it. I’m embarrassed to admit they aren’t RobotShop boards, and when I ask for their version, they come back as 2, not 4. Maybe that fixes things. If not, I’ll be in a better position to debug the actual problems.
I’m quite happy you appreciate the help.
Now you should see the support we offer for our products (RB-Rbo, RB-Lyn) 
Sounds great. Also, if you don’t find what you are looking for in the RobotShop catalog let us know, especially if it is from a manufacturer we already offer products from.
I’m curious to know how that goes, if you don’t mind posting again here with the results… 
Robotics and embedded systems is really a series of “it doesn’t work… yet” to "oh, it works now! ok, lets add this new feature… " loop! You have to like being regularly “frustrated” and plow through!
After this you’ll probably know way more about this board than most of its users.
Sincerely,
P.-S.: I’ve linked below a list of all the files the manufacturer offers for reference. I’ll ask our web content team to have them added to the RB-See-211 product page (under Useful Links) for ease of access.
RB-See-211_Burn_firmware_for_Atmega8_using_ISP.zip (245.0 KB)
RB-See-211_ST_78M05DataSheet.pdf (1.2 MB)
RB-See-211_Grove-I2C_Motor_Driver_Source_File.zip (210.6 KB)
RB-See-211_I2CMotorDriver12Demo.zip (2.0 KB)
RB-See-211_L298datasheet.pdf (186.4 KB)
If it does end up being a problem with the DIP switches… and if you are considering reflashing it anyway… It may be worth desoldering the DIP switch on one of them and using solder bridges to set the address value physically and see if that works.
Success!
I checked the pads on the switches with a multimeter. They had continuity across the pads in the right spots. I don’t know if the rest of the circuit is any good.
Next I took v4 of the Seeed firmware and hard coded the I2C Begin call to the address I wanted. It comes up correctly each time and doesn’t answer to 0x0F when it’s set to 0x0E.
I’m too out of my depth to know, but I wonder if setting the pullup on the pins and then reading them the next line ends up being a little racey? If just hardcoding that address fixes the problem, something about that process isn’t resulting in a correct value getting passed to the rest of the Wire library…especially on power up.
Anyway. It works! Thanks again for your help. I probably would have given up on it without your reply!
It is easy to check these since there is a schematic available.
Sounds great. As long as it does what you need I think this can be called “success” and you can move on to completing your actual project (i.e.: not fixing your COTS components ).
Not sure why it wasn’t working originally but I feel it might be safe to bet it was a firmware issue. You could upload to it a short sketch just to loop and print the PINC value every 100 ms or something and play with the DIP switch. That would quickly let you know if the connections are working and being read properly.
The code seems to set the pins of PORTC in input mode and then activate the internal pull-ups resistors. Maybe that is causing the issue since there is also external pull-up resistors?.
Glad we could figure out a solution!
Kudos to you! I only provided some basic info… Many customers wouldn’t be able to proceed with that alone!
Good luck with your project!
Sincerely,
