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.
I have a N+2 with the latest firmware (which I know has I2C fixes).
I'm using an Adafruit LSM303 compass/accelerometer module.
When I run my program under the Visual Studio debugger everything works great. When I run it standalone all calls to I2CDevice.Execute return 0 bytes transferred. Has anyone run into this? Any ideas of how to fix it? Even if the device was working fine under the debugger and I press the reset button (while still attached to the debugger) it will stop working. Does the debugger somehow to a I2C reset?
I'm not sure if the Adafruit LSM303 has the proper pullup resistors or not (they don't publish their schematic, and on the board I just see two transistors on the SCL/SDA lines). However since it is working while running my code under the debugger I don't think it is a pullup resistor issue.
I've attached my two I2C related files. The CompassSensor module is clearly not done and is doing things like invalid linear math for computing angles, I'm just playing around at this stage.
The board looks like they have logic level converters on there with the accompanying resistors to 5v and 3.3 pullup. I don't believe you need additional pullup resisitors for this to work properly.
Since I cannot see your main program loop I'm not sure if you have any delay's in there. Sometimes the sensors need Thread.Sleep statements to allow them time to initialize and adjust. This could be the case with this sensor which is why it works while stepping through slowly. Also, try to see if setting the clock rate to 100mhz instead of 400mhz make a difference. I've found a few sensors that sayd they worked up to 400mhz but worked much better at 100mhz.
I'm both sleeping for 2 seconds before the initialization and retrying the initialization when I fail. The code looks something like this:
bool enabled = false;
for (int i = 0; !enabled; i++)
{
Thread.Sleep(2000);
oled.DrawString(0, 0, "waiting for compass... " + i.ToString());
try
{
sensor = new CompassSensor();
enabled = true;
}
catch (Exception e)
{
oled.DrawString(0, 1, "e: " + e.ToString());
}
}
oled is a SPI device, not I2C and I'm using it for debugging purposes right now.
When I run this not under the debugger the device will slowly count to infinity showing the exception that is thrown in I2CBus.cs.
When I get home I'll try korbai's solution of using 5v for the sensor instead of 3.3v. Based on the thread that he linked to it looks like he was seeing exactly the same issue. It's a weird bug.
Also, stepping is not necessary to make it work. Running under the debugger (pressing f5 in VS to deploy and run) allows it to work. Running the same program via device reset or removing and adding back power won't allow it to work.
I know that just running on the debugger can have subtle changes to timing and suspected a timing issue, but my retry loop (and longer delays that I've tried) should solve that issue.
I'm both sleeping for 2 seconds before the initialization and retrying the initialization when I fail. The code looks something like this:
bool enabled = false;
for (int i = 0; !enabled; i++)
{
Thread.Sleep(2000);
oled.DrawString(0, 0, "waiting for compass... " + i.ToString());
try
{
sensor = new CompassSensor();
enabled = true;
}
catch (Exception e)
{
oled.DrawString(0, 1, "e: " + e.ToString());
}
}
oled is a SPI device, not I2C and I'm using it for debugging purposes right now.
When I run this not under the debugger the device will slowly count to infinity showing the exception that is thrown in I2CBus.cs.
When I get home I'll try korbai's solution of using 5v for the sensor instead of 3.3v. Based on the thread that he linked to it looks like he was seeing exactly the same issue. It's a weird bug.
According to the design of that breakout board, it takes 5V and has an on board 3.3v regulator. It does need to be powered by 5V.
Where did you see that? The Adafruit page says "Since it's a 3.3V max chip, we added circuitry to make it 5V-safe logic and power, for easy use with either 3 or 5V microcontrollers. Simply connect VCC to +3-5V and ground to ground."
The chip data page says that it wants 2.5V to 3.3V. It looks like previous versions of this chip required 3.3V and 1.8V, but the one used by Adafruit doesn't.
I tried powering the Vin from 5v or using the direct 3.3v hookup (that appears to bypass the onboard regulator) and it doesn't seem to matter. The device works fine when I run under the debugger with no breakpoints or stepping, but doesn't work when run standalone.
Chris Walker? If you have one of these devices I'd be happy to write a <20 line repro module.
Hi Alex,
Do you have a logic analyzer by any chance? What would really help is to see what is going on from an I/O perspective.
A 20-line repro would be very, very useful
Chris
I don't have a logic analyzer. I'm a software guy who is dusting off some old skills and playing with hardware. I've been wanting to play with these devices for a long time and finally came up with a useful application.
I've attached a demo program that repros the bug for me and uses nothing but the LED for output.
The good news is that if we can solve this problem then I have a full demonstration program for the LSM303 working that returns both heading and angles in all three axis. I couldn't find any other Netduino examples with this device.
With 4.2.2.0 this fails every time, not only when running standalone...
I went back to 4.2.1.2 without reverting my SDK DLLs and it works again under the debugger (but still not standalone). It must be a timing issue with this device and the libraries. I'd be interested in recommendations for a known working compass/tilt chip (and would prefer to have a single device instead of two).
Hi Alex,
Okay, very interesting. We're going to pull this chip into the lab after next week's 4.2.2 SDK launch.
We actually work with this family of ST MEMS chips already. It'll take a few days to build a breakout for the chip and Netduino Plus 2. We're also ordering one of Adafruit's breakouts.
I may be pinging you for a bit more info about your wiring setup. The new firmware resets the power during deployment, so we should be at a known-good state (and not "warmed up from before").
Chris
Alex,
If you power the breakout via 3.3V instead of 5V, does that change anything?
Do you happen to have a schematic for the breakout? I couldn't find one. And I2C level conversion chips can be a bit tricky...which I believe are being used here.
Chris
No, I have the same failure using 3.3V as 5V. I've tried it both ways.
I don't have a schematic for the breakout board that I'm using, Adafruit doesn't appear to publish one. Had I known better a week ago I'd have ordered this board:
From board inspection it looks like Adafruit uses a similar schematic. The Adafruit board is using 10k pullup resistors (instead of 4.7k) and uses a single capacitor to handle noise on Vin instead of the 4 on the Pololu board. I don't have a meter that allows me to measure the capacitance values to see if they match on the two boards.
Chris: Any updates on this? I've seen a few other I2C threads pop by too.
In the meantime I've ordered a Netduino 1 (a couple of days before the Netduino 2 announcement) and the I2C on there is working just fine with this device. I won't be able to test this soon on my Netduino Plus 2 because it will be secured away into device.
Hi Alex,
We ordered a few different versions of this breakout to do an analysis. We should have them all by next week. We're working on a small update for Netduino 2 and Netduino Plus 2, but we can slip this into our test queue right after that.
I've been following the I2C threads and it seems like things are working well from a software perspective. There were some hacks with Netduino gen1 that were required (such as for repeated start bit). That tripped things up a bit for users upgrading to Netduino gen2 (which shouldn't need those hacks). Overall it seems like most scenarios and hardware are working well...now we're digging in to help provide guidance on the other 1%
Chris
Hi Alex. I use the MinIMU-V2 from Polulu which uses the LSM303DLHC chip as well as a L3Gd20 Gyro. I run this board along with a Lassen LS20031 GPS and BMP085 with no issues. I run my I2C bus at 100kHz. You shouldnt have to sleep for anything on the LSM303 board.
I had what I thought were I2C issues when I switched to the N+2 but it turned out to be buffer overrun issues with the UART. Once I handled that, my I2C ran flawlessly on 4.2.2.0. I also switched from the I2C code you are using to the toolbox.NETMF multiI2C class and have found much fewer hiccups.
As far as pullups go, I did have to add 880 Ohm pullups to get under 300ns even with both my MinIMU-V2 and BMP085 boards having onboard pullups. I was at about 340ns, which worked but did hiccup now and then. Ive had the board spitting out data continuously for three days now with no hiccups with the extra pullups.
I2CBus.cs 5.79KB
37 downloads
Chris
