Netduino home hardware projects downloads community

Jump to content


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.
Photo

Does I2C actually work on the N+2?


  • Please log in to reply
13 replies to this topic

#1 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 01 April 2013 - 08:54 PM

Ive been trying for the life of me to get I2C to work on the N+2. This is my second board. The first I more or less had to reprogram the firmware every time I tried programming with VS2012. Sent it back and gt this one. Its  a little better, but I have to constantly disconnect and reconnect to program it.

 

I cant however get I2C to work for me. Do these new SDA and SCL pins actually work? Is there something that were supposed to do differently with this board aside from firmware? I have  a netduino 1 with 3 i2c devices and two uarts working perfectly.



#2 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 01 April 2013 - 09:28 PM

As long as the firmware is upgraded to the latest there is no I2C issue.  I have it working with several ND+2 and several different types of devices.

 

Perhaps you can share a little more about what firmware you are running, are your projects using the correct SecretLabs DLL or the ND+2 and what sensors are you using?  Do they have the proper pullups?



#3 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 02 April 2013 - 12:56 AM

Hi Dave.

 

Current Setup:

 

4.2.2.2 firmware

Netduino SDK 4.3

.NetMF 4.3

 

N+2 Board

MinIMU-9 V2 from Polulu   1 - LSM303DLHC and 1 - L3GD20 onboard

Lipo Fuel Gauge from Sparkfun 1 - MAX17043G+U

Barometric Sensor from Sparkfun   1 - BMP085 onboard

Lassen LS20031 GPS

 

Attached File  20130401_165037.jpg   243.45KB   18 downloads

 

Pullups are 800 Ohm. Scoped the clock line to verify them under 300 nS.

 

All work perfectly on my netduino 1.



#4 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 02 April 2013 - 01:02 AM

Pretty standard setup.  The Sparkfun sensors have Pullups built in so they shouldn't need them, but even if a few don't have them some of the sensors should work.

 

Are you using the secretlabs.netmf.hardware.netduino DLL in your project?  Just making sure as you should not be using the secretlabs.netmf.hardware.netduinoplus DLL with ND+2.

 

It is also possible it's a NETMF 4.3 issue which I cannot help diagnose as I am still running VS2010 and NETMF 4.2 for now.



#5 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 02 April 2013 - 01:16 AM

They do have pullups built in, but there is a bit of capacitance inside that breadboard hence the need for more resistance. Its still a little high on the time rise at about 310 nS, but the I2C communication is solid on the netduino 1. Once I make a board, the extra capacitance will be taken care of.

 

I am using the secretlabs.netmf.hardware.netduino DLL in the project. I didnt think this would be an issue. When creating a new project in VS2012, you select which board you are using. I chose the netduino plus two and it loaded the secretlabs.netmf.hardware.netduino DLL automatically instead of the secretlabs.netmf.hardware.netduinoplus DLL. I assume that would e a netduino SDK issue?

 

Ill try with the secretlabs.netmf.hardware.netduinoplus DLL and see what I get.



#6 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 02 April 2013 - 01:56 AM

Actually as my message said you should NOT be using the secretlabs.netmf.hardware.netduinoplus DLL with the ND+2.  So this will only make your issue worse if you switch.

 

Have you tried with just one sensor to see what results you get?



#7 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 02 April 2013 - 01:58 AM

And has become usual with this board, Ive lost the firmware again. Kept getting unable to connect over and over again. Ran MFDeploy and got the Not Supported message multiple times in a row.

 

Attached File  Capture.JPG   125.33KB   6 downloads

 

Reprogrammed with 4.2.2.2 firmware and same thing, 'Unable to communicate with device USB:Netduino'.

 

Im doing a one for one swapping the N1 with the N+2. What else is supposed to change between them?



#8 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 02 April 2013 - 02:00 AM

Yeah, went back and removed it again after re-reading the post. Still nothing.

 

I tried a new program with just a 500mS blinking led and all connects and works fine. Then added one I2C sensor and kaboom, no connection again.

 

Attached File  Capture1.JPG   114.98KB   9 downloads

 

This make sense?

 



#9 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 02 April 2013 - 04:24 AM

Hi Jon, The buffer overflow message from NETMF is indicating that something is getting way too much data too quickly. Have you tried a simpler I2C app, with a logic analyzer/o-scope, to just verify that the I2C signals are being sent with a simpler function call? The NETMF 4.3 SDK should work fine with 4.2.2.2 firmware--for what you're using here. The main limitation is that there are some glitches in the NETMF 4.3 SDK related to debugging older firmware. Can you share a repro (<=20 lines) which exhibits the I2C issue on Netduino Plus 2 -- without a device attached? Sorry for the troubles; let's see what we can do to get you up and running here. Chris

#10 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 02 April 2013 - 01:02 PM

Ill try to work something up tonight.



#11 Paul Newton

Paul Newton

    Advanced Member

  • Members
  • PipPipPip
  • 724 posts
  • LocationBerkshire, UK

Posted 02 April 2013 - 04:40 PM

Hi Jon, I might be mistaken here, but looking at first picture you posted I think your "pull ups" are actually "pull downs". Hope this solves it - Paul

#12 JerseyTechGuy

JerseyTechGuy

    Advanced Member

  • Members
  • PipPipPip
  • 870 posts

Posted 02 April 2013 - 05:43 PM

Good catch Paul. I couldn't see the image on the mobile version of the forums.  Looking at it from my PC it does look like the resistors are in the (-) channel on the breadboard.



#13 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 03 April 2013 - 02:47 AM

Yeah I had caught that after taking the pic. Its actually only the right one. I had pulled it out just to measure it and post the right value in that post and put it back in the wrong place. In that pic, both resistors are actually connected to the clock line with the other ends positive and negative respectively. It was only wrong for the pic and as soon as i hooked the netduino 1 back up and had a problem i caught it and fixed it. It isnt the cause of my N+2 problem.

 

I did get the N+2 working with only the MINIMU-9 V2. Here is the clock line on the scope.

Attached File  ADS00001.BMP   329.12KB   14 downloads

 

And exploded

Attached File  ADS00002.BMP   329.12KB   8 downloads

 

Should the clock be intermittent like it is in the first pic? It only shows one burst in the pic, but it is consistent...burst.high.high.high.burst.high.high.high.

 

Im gonna put the N+2 back on my main board and connect to the i2c bus I have setup there with all the sensors connected but only run the software which initializes and uses the MinIMU-9. This should at least verify if I have a physical bus problem or not.

Attached Files



#14 Jon Henry

Jon Henry

    Advanced Member

  • Members
  • PipPipPip
  • 43 posts

Posted 03 April 2013 - 04:34 AM

So i used the new program with the one sensor and slowly started copying code and libraries over and running the program after each transfer. I also connected the rest of the I2C sensors. They all work perfectly.

 

Naturally, the very last piece of code I copied over is where I found the problem.

static void spComm_TransmitTelemetry()        {            led.Write(true);            UTF8Encoding enc = new UTF8Encoding();            navData = enc.GetBytes("$TELEM," + nmea[0] + "," + nmea[1] + "," + nmea[2] + "," + nmea[3] + "," + nmea[4]                + "," + nmea[5] + "," + nmea[6] + "," + nmea[7] + "," + nmea[8] + "," + nmea[9] + "," + nmea[10] + ","                + nmea[11] + "," + nmea[12] + "," + nmea[13] + "rn");            //nmea[0] = UTC                       nmea[10] = Target Bearing            //nmea[1] = Latitude                  nmea[11] = Temperature            //nmea[2] = N/S                       nmea[12] = Pressure Altitude            //nmea[3] = Longitude                 nmea[13] = Fuel Gauge            //nmea[4] = E/W                       nmea[14] =             //nmea[5] = Altitude                  nmea[15] =             //nmea[6] = Ground Speed              nmea[16] =             //nmea[7] = Course                    nmea[17] =             //nmea[8] = Date                      nmea[18] =             //nmea[9] = Target Distance           nmea[19] =             //spComm.Write(navData, 0, navData.Length);            Debug.Print(sensor.GetHeading().ToString());            led.Write(false);        }

It seems the N+2 doesnt like my line navdata = enc.GetBytes..................

Commenting this out lets my original program run fine. Uncommenting locks it up and forces a firmware reprogramming of the N+2.

With the Netduino 1, this ran fine uncommented.

Should this be?

 

 

UPDATE (3/3/13):  Its not the UTF8 encoding itself, its my data it doesnt like.

Adding this and the program runs fine. Just have to add the rest of my payload in somehow.

UTF8Encoding.UTF8.GetBytes("$TELEM", 0, 6, navData, 0);





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

home    hardware    projects    downloads    community    where to buy    contact Copyright © 2016 Wilderness Labs Inc.  |  Legal   |   CC BY-SA
This webpage is licensed under a Creative Commons Attribution-ShareAlike License.