Custom I2C sensor problem

[gloomyandy]

Thanks for the diagram. I assume that the pull up on the SDA line really goes to VDD and not back to SDA... Other than that it all makes a lot of sense...

I'll interested to see how you get on with bus pirate. I'd like to get hold of some better i2c test gear, so I'll take a look at that.

[aswin0]

There is some good news, although small.

Using the bus pirate I can detect both the I2C devices on the IMU. The good news is that the both the new and the old IMU react. So instead of one problem I seem to have two.

For this test I have been using the power supply from the bus pirate and external pull ups of 47K. So I know now that these high impedance pull ups do not cause trouble with the IMU. I will now use the power supply I made on my breadboard to see if the IMU works with my power supply as well.

[aswin0]

I ran a new series of tests. I find the results hard to explain. Here is what I have done.
From the previous test with the bus pirate I concluded that the IMU is ok. This time I fed the IMU power from the NXT that I reduced to 3.3V with an LDO. The IMU kept responding to commands sent by the bus pirate. From this I conclude that my power supply cannot be the problem. But when I connected the data and clock lines lines with the NXT the IMU stopped responding. As soon as I disconnected the NXT from the breadboard the IMU responded again, so it could not be the wiring on the breadboard. It didn't matter if the NXT was on or off (when the NXT was off I used the power supply from the bus pirate again). I ruled out cable and connector problems.

So, now I need to find out what is in the NXT that cause these problems. I'll look at the schematics in the NXT hardware guide but if you guys have any suggestions let me know.

[gloomyandy]

Hi,
remember that the NXT may be driving the clock and data lines (even if you don't run a program on the nxt) and so may in effect be a bus master (and you can only have one master), so it may be messing up the bus pirate

[aswin0]

Well I can and will test that, because I can put the bus pirate in sniff mode. It then just listens.
But it does not explain why it still does not work when the NXT is shut down.

Btw. Up to now the bus pirate proves itself to be a fantastic tool.

[gloomyandy]

Even when it is shutdown there are a bunch of components in the NXT that may be doing odd things to the bus lines, so they may be messing things up. Have you tried snooping on the NXT when it uses i2c?

[nikzagvit]

Right at the beginning you wrote about an error-35, Sivan Toledo writes about the same error here in the end of article http://www.tau.ac.il/~stoledo/lego/i2c-8574/.
I hope it to you will help.

[HaWe]

does this help:

Code: Select all

#define ERR_COMM_BUS_ERR        -35 

[aswin0]

does this help:

Code: Select all

#define ERR_COMM_BUS_ERR        -35 

I found that one, it is not very specific, is it?

Even when it is shutdown there are a bunch of components in the NXT that may be doing odd things to the bus lines, so they may be messing things up. Have you tried snooping on the NXT when it uses i2c?

No, but this is the first thing on my list for tomorrow evening. Second thing is to use the bus pirate as a strobe to see if the clock and data lines change when connected to the NXT.

It is a steep learning curve for me. I'm glad I'm not doing this alone but with your help instead.

[aswin0]

Today I ran some more tests.

I have bought this IMU sensor to use with my NXT. Until now I have not been successful in connecting the sensor to the NXT. The NXT gives me error -35 (a general bus error).
I have a bus pirate that allows me to send I2C commands from the pc to an attached sensor. I have been successful in communicating with the sensor via the bus pirate. So I know the sensor is working.
The IMU sensor needs 3.3V, the NXT gives 4.7V. I have a small circuit that reduces the NXT power to 3.3V. I know this circuit is working for the IMU.
I have a blinkM, an I2C driven all color led. I can swap this for the IMU on my breadboard. I can send commands to the blinkM, so I know both my circuit as my I2C drivers must be working.
The only thing that doesn't work is the combination of NXT and IMU.

I can use the bus pirate not only to send commands over I2C but also as a sniffer to see what data goes over the lines. This is what I tested today. When I test this with the blinkM I can see my commands going over the line. So the sniffer is working well. But when I use it with the IMU I see no commands at all. Therefore I am starting to believe that the NXT won't even start I2C communication when the IMU is present.

So the big question now is: Why won't the NXT start communicating over I2C when the IMU is present?

I figured out that it must be a characteristic of the IMU that the NXT doesn't like. But what? Using a multimeter I tested the resistance between the four pins of the IMU, I did the same with the blinkM (VVD or GND versus SCL or SDA). Apart from a small difference in internal resistance I found nothing strange. The answer might also be hidden in the firmware. What kind of conditions must be met before the NXT will start communicating over I2C? I know there is a couple of guys here that know the firmware. Do you have any ideas on this?