chipKIT® Development Platform

Inspired by Arduino™

Uno32, Rev. C: I2C doesn't work???

Created Thu, 09 May 2013 05:14:28 +0000 by Tenacious Techhunter

Tenacious Techhunter

Thu, 09 May 2013 05:14:28 +0000

I put 4.7k Ohm pullup resistors on SCL and SDA. I tried setting JP6 & JP8 to RG3 & RG2. I tried setting JP5 & JP7 to Slave instead of Master (still don't know why). I even tried setting JP4 to SPI Slave instead of PWM, which makes no sense whatsoever.

Regardless of what I do, I can't generate a clock signal of ANY frequency on A5, much less data on A4. All I see is the 3.3V from the pullup resistors.

The Master Write Wire Library example just doesn't work, and even replacing the ".send"s with ".write"s doesn't work either (What's up with that, anyway?). I even added some blinks to make sure the code was being loaded, and it is.

I am absolutely out of ideas. Can someone PLEASE explain what the hell is wrong here? I2C shouldn't be this hard, as loading the equivalent sketch (see the bit about ".send" vs. ".write") on a real Arduino Uno proves.

Jacob Christ

Sun, 19 May 2013 01:05:57 +0000

Here are some snips of code that work on one of my boards using 20120903 MPIDE.

I don't know if this helps..

#include <Wire.h>

void setup()
{
  Wire.begin();

  pinMode(led1, OUTPUT);     
  pinMode(led2, OUTPUT);     

  // initialize serial ports:
  Serial.begin(115200);
  Serial0.begin(115200);
  Serial1.begin(115200);
  Serial2.begin(115200);
  Serial3.begin(115200);

  delay(5000);
  Serial.println("Serial - USB Open");
  Serial0.println("Serial1 - TTL Kard");
  Serial1.println("Serial1 - RS-232");
  Serial2.println("Serial2 - RS-485");
  Serial3.println("Serial3 - RS-485");
}

void PrintEE(us8 address)
{
  Wire.beginTransmission((int)address);  //0x53 quicK 0x50 Kard
  Wire.send(0x00);
  Wire.endTransmission();
  Wire.requestFrom((int)address, 6);    // request 6 bytes from slave device #2
  
  while(Wire.available())    // slave may send less than requested
  { 
    char c = Wire.receive(); // receive a byte as character
    MySerial.print(c,HEX);         // print the character
    MySerial.print(".");
  }
}

void loop() {
  Wire.beginTransmission(0x50);
  Wire.send(0x00);
  Wire.send(0x00);
  Wire.send(0x01);
  Wire.send(0x02);
  Wire.send(0x03);
  Wire.send(0x04);
  Wire.send(0x05);
  Wire.send(0x06);
  Wire.endTransmission();
}

Jacob

jRobert

Sun, 19 May 2013 06:13:15 +0000

Have you tried changing the device address in the example code? I don't know why, but for some reason the addresses in the examples don't work.

les1943

Sun, 19 May 2013 08:22:18 +0000

Slave addresses are defined shifted 1 bit right so device address H'90 is coded as H'48. wire does this to add the R/W bit

Tenacious Techhunter

Mon, 20 May 2013 18:18:51 +0000

Thanks for responding, guys. The problem I'm having is that the example generates neither a clock nor data. Any code examples or address issues are kind of immaterial under those circumstances; but thanks for replying... I was beginning to think this thread wouldn't get any traction at all.

The example code should generate a clock with an address and some data bytes on it. Please confirm that it does on your boards; any address issue, while possibly relevant later, isn't relevant just yet. I can't do anything about the correctness of the data if I can't even get a clock, much less data, to look at.

mikes

Mon, 20 May 2013 18:49:48 +0000

Are you sure you have the jumpers set correctly?

JP6/JP7 – A4/A5 Signal Select Jumpers These jumpers are used to switch pins 9 and 11 on connector J7 between analog inputs A4 and A5 or the I2C signals SDA and SCL.

Tenacious Techhunter

Tue, 21 May 2013 03:41:30 +0000

Try that and show me that it generates a clock. Other material says to switch 6 and 8 rather than 6 and 7, not that I haven't switched both by now. Generate a clock on a scope, and then take a picture with the clock and data signals displayed. I'll copy that, and honestly, I won't be much surprised if I don't get output, even if you do. If I don't, I'll just follow up with an otherwise identical picture, but no output.

Tenacious Techhunter

Tue, 11 Jun 2013 23:37:47 +0000

Can someone please show me this board generating I2C clock and data values on the I2C SCL and SDA pins? No bit-banging need apply, please...

majenko

Wed, 12 Jun 2013 00:13:49 +0000

I can't show you the actual signals, but I can show you an I2C display running on the Uno32. J6 and J8 are selected to be closest to the analogue header (set to RG2 and RG3). [attachment=0]disp1.jpg[/attachment] This is using the standard Wire.h library, and Adafruit's MCP23017 library. No code changed at all from running on an Arduino.

majenko

Wed, 12 Jun 2013 00:21:25 +0000

And just for you, here's the scope traces. [attachment=0]scope1.jpg[/attachment]

majenko

Wed, 12 Jun 2013 00:29:22 +0000

Oh, by the way, I'm on a revision B, not C. The code is the example in this library:[url]http://scratchpad.majenko.co.uk/I2CDisplay.zip[/url]

You can check that the right connections are routed through by toggling ports G2 and G3 manually and seeing if they get through to the pins:

void setup()
{
  TRISGCLR = 0b1100;
  while(1) {
    LATGSET = 0b1100;
    LATGCLR = 0b1100;
  }
}

void loop()
{
}

Check that a clock signal appears on both A4 and A5, and on the RG2 and RG3 pins of J6 and J8.

Tenacious Techhunter

Wed, 12 Jun 2013 21:48:47 +0000

Oh, by the way, I'm on a revision B, not C.

I appreciate your effort, but I need to see this on a Rev. C. If the board's at fault, the revision matters a great deal. I'll make a point of trying the toggling tip, though.

Tenacious Techhunter

Wed, 12 Jun 2013 21:54:14 +0000

This is using the standard Wire.h library, and Adafruit's MCP23017 library. No code changed at all from running on an Arduino.

Now that makes even less sense. So you're using ".write" instead of ".send"?

majenko

Wed, 12 Jun 2013 23:04:06 +0000

No, it's using Wire.send():

static inline void wiresend(unsigned char x) {
#if ARDUINO >= 100
  Wire.write((unsigned char)x);
#else
  Wire.send(x);
#endif
}

majenko

Wed, 12 Jun 2013 23:17:30 +0000

As far as I can see there are only 3 differences in the schematics between REV B and REV C.

  1. Removal of 2 ground test points
  2. Inclusion of JP9 for disconnecting SS2/RG9
  3. Inclusion of clamping diodes on the input to the comparator for power switching to protect against over-voltage.

There are no changes to the main operation of the board, so what works on a REV B will work on a REV C.

I suggest you download my I2CDisplay library (linked above) and try the "counter" example. If that doesn't work, then

  1. You have fried the IO ports on the chip somehow
  2. The jumpers are in the wrong position
  3. The jumpers themselves are faulty (check continuity between the pins)
  4. Your oscilloscope is broken

Tenacious Techhunter

Wed, 03 Jul 2013 02:21:48 +0000

I suggest you download my I2CDisplay library (linked above) and try the "counter" example. If that doesn't work, then

  1. You have fried the IO ports on the chip somehow
  2. The jumpers are in the wrong position
  3. The jumpers themselves are faulty (check continuity between the pins)
  4. Your oscilloscope is broken

I don't see what trying your code over the I2C Wire Library Example Code is supposed to accomplish. If the example doesn't work, something needs to be fixed, period.

I'd be tempted to believe 1, except I've barely used the damn thing. If it's just a matter of proving that pin still blinks, I'm pretty sure it's still fine, though I'll check, especially if someone gives me something more specific to test; but do pins really get stuck high like that? Sounds fishy. I'd be tempted to believe 2, except no one's proven a valid pin configuration exists through a working scope and/or analyzer trace. Board configuration doesn't mean a damn if it shipped from the factory with bad firmware loaded. I'll certainly check 3, but that's kind of grasping at straws. 4 is flat-out wrong, because as I've said, the Arduino signals showed (and continue to show) up just fine AFTER I tried the UNO32 Rev. C; the scope works fine for other things as well.

So far, no one has proven that THIS model generates I2C, so testing purely hypothetical jumper settings that I've already tried seems pretty damn pointless. For goodness sake, someone post some damn pictures already; that's the only thing that's going to lead anywhere, because it's the only way to verify or disprove the problem for all boards of this make; if mine is an exception somehow, I need to see it, not just hear it from people who only SAY they've tried it, but might not have, just to defend their choice of platform. :P I need to see results, not talk.

les1943

Wed, 03 Jul 2013 09:00:37 +0000

Understand your frustration , I have 3 UNO's have used I2C with EEprom, expanders RTCC no problems , however I recently got a microstick 2 with PIC24FV16KM202 and my first attempt with I2C failed to move the pins from the 5v (pull up ) , apprently previous 24F chips had a bug setting the clock and data as outputs did not set the masters clock latch correctly so all you get is bus collisions , ( clock always high) I don't think this PIC has a bug my setup may be missing some code with UNO32 I think with wire.(I2C ) errors are largely ignored . on my microstick I had to make I2C pins outputs... TRISB bits 8-9 =0 and driving them low with LATB 8-9 = 0 ,then returning them to inputs .... I2C then came to life !

(PIC24F also has an alternate pin setup for I2C but this was ok.)

Note The state of port latches LATB etc on reset are usually unknown .

I am not saying UNO32 has this problem , just posting my experience.

Tenacious Techhunter

Wed, 03 Jul 2013 22:30:32 +0000

Yes, this is exactly my complaint about people offering advice without actually trying to put it up on the scope. Until people DO that, they assume the hardware and firmware are actually working as intended, which damn well might not be the case! I'm not saying I'm not getting it wrong, either; I certainly might be. But if getting it to work was that simple, WHERE ARE THE DAMN PICTURES I ASKED FOR?

majenko

Thu, 04 Jul 2013 08:36:36 +0000

One question that nobody seems to have asked yet:

What version of the IDE are you using?

I believe some work was done on the Wire.h library at some point in the past that transitioned it from not-working to working.

les1943

Thu, 04 Jul 2013 13:58:33 +0000

Dare I say in PICxx.asm the first and most important thing to do is clear all the device ports and latches , looking at the PIC port circuits you will see direct connections from LAT to PORT flip-flops , as I said LAT status on reset is unknown , so if its high and as wire sets I2C pins as inputs , then reads the port expecting to see clock low... a bus collision could be detected. try adding LATGCLR = 0b1100; to setup before wire.begin.

edit.

errr according to my PIC32MX3xxx data sheet DS61143G-page 26 RG2 RG3 are inputs or I2C ?

Your SET / CLR loop should not work ?

KeithV

Thu, 04 Jul 2013 19:33:04 +0000

Hi,

I decided to jump in on this because I am running a Rev C Uno32 using I2C just fine. Below are pictures of the board so you can see it is Rev C, how the jumpers are set up, and the Logic Analyzer Trace.

I am using 4.7K pullup resistors and the latest drop of MPIDE 20130626. You might want to make sure that your jumper pins are not loose, make sure the signal connection is good. Otherwise I have no clue why you are not working.

Rev C [attachment=2]2013-07-04 12-26-20.394.jpg[/attachment]

Jumper setup and pin connections [attachment=1]2013-07-04 12-25-40.372.jpg[/attachment]

Logic Analyzer trace [attachment=0]I2CTrace.jpg[/attachment]

Tenacious Techhunter

Sun, 07 Jul 2013 22:34:17 +0000

O.K., I get why a newer build might work, but what I don't get is why ANY newer build is not available here: http://chipkit.net/started/install-chipkit-software/

Are these newer builds not ready in some capacity, or did someone just fail to update the link? Which build should people be using for real prototyping work?

majenko

Mon, 08 Jul 2013 09:22:24 +0000

I guess a bit of both really. Development is on-going all the time, and I for one don't know whose job it is to keep the link up to date, or what it should be updated to.

Ricklon and co do regular releases, which are available here, but which of those are considered "stable" I can't say. They're pretty good at the testing though, so the latest one is usually your best bet.

KeithV

Mon, 08 Jul 2013 15:35:20 +0000

Microchip owns chipKIT.net and I can ask them to update the link. Test builds always have the word test in them, release builds do not have the word test in them.

Here is the link to all of the test and release builds

http://chipkit.s3.amazonaws.com/index.html

les1943

Wed, 10 Jul 2013 15:55:37 +0000

Be interested to know if MPIDE version was the solution ???? :?:

hdphilip

Sun, 11 Aug 2013 14:28:27 +0000

I have a rev B board and had the same problem, so i put my arduino on my metal detector shield board i made and was able to access my I2C chips just fine. hummm, i thought, I've been usuing MPIDE 20111221 build, upgraded to the latest 20130715 build, problem solved.

Philip