The Netduino forums have been replaced by new forums at community.wildernesslabs.co.
This site has been preserved for archival purposes only
and the ability to make new accounts or posts has been turned off.
Got my DSO Nano, yesterday. Never used an oscilloscope before, so it took 15 or 20 minutes to figure out (1) that I needed to upgrade to the BenF firmware/app, and (2) how to use the basic functionality. I realize that there are downsides to this unit, but I think it's great for any hobbyist that's curious about trying out a 'scope.
I bought it because I wanted to look at the i2c bus, and here's what I've come up with so far:
I think the clock line looks pretty good. Anybody disagree? Here it is:
As for the data line, it looks OK except for some spikes that concern me:
Any theories on what might cause that sort of spike? They're always there, at the same point in the signal. The anomalous spike in this trace will rise up a little higher than this, fall down to near zero, and wander everywhere in between.
Other observations:
I've noticed that the clock rate will sometimes briefly fall to something like (I'm guessing) 50kHz, but that it spends the vast majority of its time at the expected 100kHz. Is this normal?
Before I got the Nano, I noticed that the BMP085 I have on the bus will sometimes return ridiculous temperature values. When it does, I can read tens of thousands of nonsensical values in a row before it returns to normal operation. While watching the i2c clock with the Nano, I've discovered that there is no clock signal while I'm getting the nonsensical temperature values. Since there is no clock signal, I'm assuming that there is no communication with the BMP085 and that the nonsensical values must be coming from uninitialized values in the driver, or something like that. Any other theories?
Hi Spork,
What do you have hooked up to the I2C pins when you are reading its signals? I2C pullups? A device?
Also, when you don't see any clock signal--is the signal LOW or HIGH?
Chris
What do you have hooked up to the I2C pins when you are reading its signals? I2C pullups? A device?
Also, when you don't see any clock signal--is the signal LOW or HIGH?
Hi Chris.
I've got a BMP085, a DS1307, and a 24LC256 on the bus at the same time. The first two are on breakout boards with pullups. The 24LC256 was the third addition, it's not on a breakout, and I didn't add any pullups when it was added.
When I'm getting the nonsensical values, the clock signal remains high.
When I read from the BMP085 and DS1307, I Debug.Print the returned values and the Debug.GC(true) return value. I just noticed two things that might imply that garbage collection is involved:
First, I've noticed that there is always a slight dip in free memory before the problem happens. The converse is not true -- i.e. not every dip in free memory is followed by the problem. For the current run, my free memory is almost always 22,992 for each Debug.GC(true) call, but free memory is always slightly lower at 22,236 before the problem. The free memory is always back up to 22,992 after I get another good reading from the sensor.
Secondly, once a batch of failures begins, they continue for 30 seconds. Every batch of failures has the same elapsed time from first failure to last failure. Is it possible that garbage collection could run this long?
If the clock is high while your netduino gives you values, there's something amiss, as it would be (as the master) responsible for driving the clock low. What happens on the data line when you get those values?
As for the peak, to see if it matters you'd need to time-align both signals - if the peak happens while the clock is low, it's irrelevant for the data transmission.
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"
I always say that the I2C-Bus is somewhat a fantastic protocol: a real masterpiece. The only fault is its slowness, but we cannot ask everything from life!
Bear in mind that the *REAL* I2C-Bus is a synchronous protocol, it means that there is a "clock" that beats the state-machine working over the tx/rx sequence.
-- The spike --
The default state (idle) of both the data and the clock is "high", because no device is tying down the line, so the pullup resistor wins.
The spike is a glitch appearing when the master device (Netduino) ends one byte (8 bits) and releases the data line for the slave acknowledge. The slave must pull down the data line (if ack'ed), thus master "understand" the message could be carried on with the next byte. If the slave is not fast enough to present the ack low as soon the master ends its 8th bit, there'll be a microsec period of "anarchy", where the data line is left alone (so high).
-- The clock frequency --
Normally the clock frequency is driven by the master.
However, if you connect a "good"(*) I2C-Bus slave device, but SLOW, the slave may hold the clock down to instruct the master to wait. So, the master COULD use the maximum frequency, but the slave MAY slow that frequency down.
You may notice this behavior when the clock duty-cycle is not 50%, but it looks asymmetrical.
(*) I meant "good" because this is a I2C-Bus directive for the master, thus a slave can take advantage of it. However not any I2C implementation is really compliant, especially when is software/firmware based.
Hope it helps.
Cheers
PS: I owned a DSO-Quad. I suggest to keep the measurements under 100-200KHz, otherwise the waveforms displayed would be totally different from the truth.
Biggest fault of Netduino? It runs by electricity.
Spork, also please note that your I2C pullup values should be calculated based on the # of devices on the bus, distance, etc. Sometimes you can get odd results if they're a bit out of range.
Chris
Chris, that is no explanation for the "Clock stays high, during that I get weird readouts, then it works again" though ...
Also, his signal looks ok, so the pullup values should be about right. I have a signal like this:
And it still works (It's from http://www.sparkfun.com/products/10252 which has builtin pullup resistors, nothing else on the bus - it's on a breadboard though, so there may be stray capacitances responsible for that ...)
I believe that no discovery of fact, however trivial, can be wholly useless to the race, and that no trumpeting of falsehood, however virtuous in intent, can be anything but vicious.
-- H.L. Mencken, "What I Believe"
Turns out that the BMP085 driver I downloaded from this forum only polls the device every 30 seconds. In between those polls, it returns the value from the most recent poll. That explains two things: (1) No activity on the bus when I was getting bad values and (2) the fact that good values would always resume after 30 seconds.
So, I'll continue debugging over the weekend, but will drill down into the driver to see if there's an issue there.
Chris: I realize that the pull up resistor values should depend on the number of devices, distance, etc. I was going to try the calculations on this excellent page about i2c, but they require that one knows the capacitance of the devices on the bus. The author of the page mentions that the capacitance values should be on data sheets, but I can't find a capacitance value for the BMP085.
Mario: Thanks for the spike info. That seems to make sense and explains why it would vary in height, with each trigger.
