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

I2C Bus Problem - Debugging

I2C I2C bus

  • Please log in to reply
39 replies to this topic

#21 CW2

CW2

    Advanced Member

  • Members
  • PipPipPip
  • 1592 posts
  • LocationCzech Republic

Posted 17 March 2014 - 10:13 PM

That file lives in two places:

C:\MicroFrameworkPK_v4_3\DeviceCode\Targets\Native\Netduino_STM32\DeviceCode\STM32_I2C\STM32_i2c_functions.cpp

and

C:\MicroFrameworkPK_v4_3\DeviceCode\Targets\Native\STM32\DeviceCode\STM32_I2C\STM32_i2c_functions.cpp

 

(I modified both)

 

For Netduino 2 you need to modify only files in Targets\Native\Netduino_STM32. The STM32 folder contains the original Oberon's implementation, which is not used - Netduino_STM32 is basically STM32 + Secret Labs' modifications.

 

In fact, you could delete all subdirectories in Targets\Native and Solutions that do not have Netduino,Template or Windows in their name - I usually do that to reduce code search result noise...



#22 yogotie

yogotie

    Member

  • Members
  • PipPip
  • 16 posts

Posted 18 March 2014 - 01:47 AM

gismo,

 

My original fix is only applied to when the device is initialized.  It looks like your problem is occurring at some time later during a transaction.

 

If you are able to get a debugger, cost is $21.25 at mouser, you can check to see if the busy bit is set when the bus locks up.  If that is true then you will need to create a more sophisticated way of reseting the I2C module make this work.  You maybe able to hack something in at the start or stop call and have something spin on the busy bit and cause a reset if it takes too long.

 

If you do get the debugger and find this is the case I'm sure that would be interesting to Chris as well.



#23 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 18 March 2014 - 09:59 AM

We're using I2C here extensively without glitches, but our power supply or data lines may be too clean to exhibit the issue.

If we can narrow this down to a specific device and specific wiring setup which reproduces this issue, we can wire that up here and dive deep into I2C code. We have good debugging tools here...we just need a fairly solid repro.

Chris

#24 Frode

Frode

    Advanced Member

  • Members
  • PipPipPip
  • 202 posts
  • LocationNorway

Posted 18 March 2014 - 10:54 PM

Hi guys, I've been trying to put together a solution to reproduce the error, and discovered something interresting.

 

When the .Execute method of the I2CDevice is called it will sometimes just return 0. I now wrote a loop to doublecheck that the returned value is OK, and if it is not then rerun the Execute method.

int transferred = -1;
int i2cAttempt = 0;
while (transferred != writeBuffer.Length)
{
    Debug.Print("WriteBuffer.Length " + writeBuffer.Length + " != transferred " + transferred);
    Debug.Print("I2C attempt " + ++i2cAttempt);
    transferred = _slaveDevice.Execute(writeXAction, transactionTimeout);
}

After making that change I see that the FIRST time the OLED display is called it will always fail, but when rerun it works. After making that change it has been working rock steady.

 

So then the question is - why does Execute return 0 the first time?



#25 jrlyman3

jrlyman3

    Advanced Member

  • Members
  • PipPipPip
  • 67 posts
  • LocationNorth St Paul. MN

Posted 19 March 2014 - 02:14 AM

Hard to say without a logic analyzer ... but, it sounds like the I2C lines are in a bad state when the board initializes and after the first operation the I2C lines are left in the correct state so that the subsequent operations all work.  It seems to me there is another topic where this is discussed, I think that they set the pins to "1" before using them as I2C ...

 

Glad that that you found a work around.



#26 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 19 March 2014 - 03:18 PM

Hey Guys,

 

I've been doing a little more testing to find a re-producible setup and have found it to be quite difficult to do so with consistent results. 

 

To start, I've simplified the code down to only execute I2C commands for one device. I've only plugged one device into the I2C bus. In doing so, the behavior is still intermittent, but it works more often than it does not work. The only major change in the simplification of the code is removing PWM code. 

 

 

 

Here are some test results when i2C is not working.

  • Main: Both SDA and SCL seem to be stuck at High Level and can't/won't be pulled down from the execute command. If I remove and insert the I2C device from the bus, this seems break it out of this stuck state and it will start working...(note: this works, but it's not an ideal solution)
  • Other: SDA was stuck low while SCL was clocking at the defined I2C clock speed. <- have only been able to produce this once.

 

Anyway, I have two devices on the bus, a DS1307 and an ATTtiny85 with i2C slave firmware loaded which measures frequency of a pulsed signal. The pulse/PWM is disabled for this exercise.

 

The best way I've been able to reproduce this:

  1. Both devices on the bus and connected to the Netduino. SDA & SDA are pulled up..
  2. Unplug Netduino from USB.
  3. Start Debugging in VS
  4. Plug in Netduino to USB and it will being debugging.
  5. Pause Code at breakpoint before initializing the DS1307.
  6. Attach/Setup Logic Analyzer. Trigger on SDA line low. Verified SDA & SCL are pulled up.
  7. Resume Code (f5)
  8. Exception will occur when trying to read the DS1307. Break.
  9. Nothing is triggered in logic analyzer. Still waiting for trigger. Both SDA and SCL are high.
  10. Remove Attiny from the bus. SDA & SCL still high. No "noise" when removed.
  11. Rewind code back up to the execute line
  12. Resume code/Execute and Exception will occur. Logic Analyzer still not triggered.SDA SCL both High.
  13. Insert Attiny into the bus. Logic analyzer is triggered and SCL and SDA are pulled and held LOW...32mV.
    • option A  - Resume Code/Execute and I2C will work fine moving forward. SCL & SDA are pulled up again
    • option B - Insert Attiny Back into Bus.. SCL & SDA remain LOW, then Resume Code. I2C works again moving forward. 

 

If I try the above steps, but instead start ONLY with the DS1307 on the bus, many times the I2C will throw an exception, but sometimes, it will work on the first shot! When it throws and exception, I will plug the Attiny into the bus, SDA and SCL will then jump to and be held LOW and I rewind the code and execute again and it works!

 

I'm not sure what else to try from this point onward, but maybe my steps will give a clue as to what's going on.

 

Also, that all being said, I'd be happy to send my entire hardware setup to someone if they want to poke around and see if they can figure this out. I also have a suspicion that PWM has some effect on this, As now I'm able to do something repeatable.

 



#27 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 03 July 2015 - 12:57 AM

I'm resurrecting this....

 

Fast forward... I'm running netmf4.3 and I've Isolated the issue with the ATTiny85 running as I2C slave mode. This communicates just fine with an arduino, but works about 5% of the time with the Netduino. I can't necessarily repeat the steps to get it to work. When it doesn't work, sometimes the SDA and/or SCL are stuck pulled LOW. I don't know how this happens. I've tried disconnecting the bus but the only thing that resolves this is to reboot the Netduino. This also happens when there are other devices on the bus causing all I2C to fail. I do know that the ATTiny Code uses clock stretching as well. I really have to dig deeper into the I2C Slave Code, but quite hairy at this point.



#28 tonycampbell

tonycampbell

    New Member

  • Members
  • Pip
  • 2 posts

Posted 22 August 2015 - 02:59 PM

Definitely something flakey with the I2C on Netduino. It seems to stop (SCL/SDA locked high) at the drop of a hat.

I can reproduce this simply by connecting my Fluke DVM or Scope probe (1M, 100pF) onto the SCL line (it survives SDA probing). Hooking SDA/SCL into a P82B715 also kills it.

I love my netduino but I need reliable I2C. May need to change hardware if there is no fix for this soon (Hope its not a Netduino board hardware layout issue!).



#29 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 24 August 2015 - 07:57 AM

I started yesterday to play with the i2c and the Netduino 3 but without success.
I think this is not a netduino 'hardware' problem (I have tried also with a Netduino 2 Plus with the same effect).
The same 'circuit' used with an Arduino works fine.
 
Have you any idea on how to solve the problem?
 
PS: I'm using a PCF8574N to expand the I/O of the Netduino, but I'm not able to use it!


#30 KiwiDev

KiwiDev

    Advanced Member

  • Members
  • PipPipPip
  • 100 posts
  • LocationNew Zealand

Posted 24 August 2015 - 11:23 AM

Hi Gigos

 

I have found my Netduino devices to be more "sensitive" to cable lengths & the fitting of termination resistors than my Arduino devices.

 

I use seeedstudio grove gear and found that 5CM cables ok anything longer breaks. 

 

Could you post some more detail or even a photo of you setup?

 

@KiwiBryn

blog.devmobile.co.nz



#31 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 24 August 2015 - 12:42 PM

Hi Gigos

 

I have found my Netduino devices to be more "sensitive" to cable lengths & the fitting of termination resistors than my Arduino devices.

 

I use seeedstudio grove gear and found that 5CM cables ok anything longer breaks. 

 

Could you post some more detail or even a photo of you setup?

 

@KiwiBryn

blog.devmobile.co.nz

 

Currenlty I don't have the possibility to send a photo but, I'm using a breadboard to test all and the 'cables' are about 10 cm (cables used to connect the SDA/SCL to the PCF8574, all others connections are made with breadboard jumper).

 

I have used two 4.7 Kohm resistors (pull-ups to +5V) connected the SDA/SCL of the PCF8574N. All the connections are made on a breadboard and I'm using the +5V directly from the Netduino.

 

Edit: I have added a sketch of my test condition:

sketch01.jpg



#32 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 24 August 2015 - 03:32 PM

Shouldn't you be connecting to the SDA (or SD) and SCL (or SC) lines (top left of the Netduino in your diagram)?

 

Regards,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#33 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 24 August 2015 - 03:33 PM

Definitely something flakey with the I2C on Netduino. It seems to stop (SCL/SDA locked high) at the drop of a hat.

I can reproduce this simply by connecting my Fluke DVM or Scope probe (1M, 100pF) onto the SCL line (it survives SDA probing). Hooking SDA/SCL into a P82B715 also kills it.

I love my netduino but I need reliable I2C. May need to change hardware if there is no fix for this soon (Hope its not a Netduino board hardware layout issue!).

 

@Tony,

I've also experienced this where SCL/SDA are locked high.BTW, which Netduino board are you using?

 

 

Currenlty I don't have the possibility to send a photo but, I'm using a breadboard to test all and the 'cables' are about 10 cm (cables used to connect the SDA/SCL to the PCF8574, all others connections are made with breadboard jumper).

 

I have used two 4.7 Kohm resistors (pull-ups to +5V) connected the SDA/SCL of the PCF8574N. All the connections are made on a breadboard and I'm using the +5V directly from the Netduino.

 

Edit: I have added a sketch of my test condition:

sketch01.jpg

@Gigios, do you have a scope?(you can use an arduino as a basic scope and/or logic analyzer). Also, at the very least, when your device doesn't work, can you put a multi-meter on the SDA/SCL lines and see if they are high or low?



#34 gismo

gismo

    Advanced Member

  • Members
  • PipPipPip
  • 110 posts

Posted 24 August 2015 - 03:35 PM

Shouldn't you be connecting to the SDA (or SD) and SCL (or SC) lines (top left of the Netduino in your diagram)?

 

Regards,

Mark

 ^^ what he said. Your diagram shows an arduino SDA/SCL hookup.



#35 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 24 August 2015 - 03:39 PM

@Gigios, do you have a scope?(you can use an arduino as a basic scope and/or logic analyzer). Also, at the very least, when your device doesn't work, can you put a multi-meter on the SDA/SCL lines and see if they are high or low?

 

Unfortunately, at the moment, I don't have a scope (probably tomorrow or the dey after I can have one to test but I don't have a 'logic analyzer').

This evening I will try to check the 'state' of SDA/SCL with a multimeter.



#36 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 24 August 2015 - 03:42 PM

 ^^ what he said. Your diagram shows an arduino SDA/SCL hookup.

 

I have found many examples for Netduino that use the analog pin 4 and 5.

This evening I will investigate if it is a my wrong 'interpretation' of the samples (sketchs) and if all works fine with the ping SD/SC (before I check in the forum to avoid 'hardware' problems :D).

 

Edit: Probably it's true, the problem is the wrong pins usage:

inputandoutput.jpg



#37 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 24 August 2015 - 03:48 PM

The original Netduino did used to use the analog pins for I2C.

 

Regards,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#38 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 24 August 2015 - 03:54 PM

The original Netduino did used to use the analog pins for I2C.

 

Regards,

Mark

 

Yes, I have checked now the 'hardware' configuration and I have seen that the sample used to 'test' the i2c was for the 'original' Netduino and not for the 'Netduino 2 Plus' and 'Netduino 3' that I have used.

 

Thanks a lot :)

Luigi



#39 Nevyn

Nevyn

    Advanced Member

  • Members
  • PipPipPip
  • 1072 posts
  • LocationNorth Yorkshire, UK

Posted 25 August 2015 - 03:37 AM

Knew there was a post about the I2C pins moving:

 

Netduino Plus 2 and Arduino R3 Pinout for I2C

 

Regards,

Mark


To be or not to be = 0xFF

 

Blogging about Netduino, .NET, STM8S and STM32 and generally waffling on about life

Follow @nevynuk on Twitter


#40 Gigios

Gigios

    Member

  • Members
  • PipPip
  • 13 posts
  • LocationItaly

Posted 25 August 2015 - 06:41 AM

Knew there was a post about the I2C pins moving:

 

Netduino Plus 2 and Arduino R3 Pinout for I2C

 

Regards,

Mark

 

Thanks

 

I have updated my sketch to 'fix' my 'error'.

116p8ip.jpg

 

Now I'm investigating on how the PCF8574N (or Netduino) works with the input. At the moment seems that the Netduino, when all the input are off, read a value of 255, this value changes only when one (or more) input is connected to GND.
 
Regards
Luigi
 
Edit: Fixed the fritzing diagram to fix some small errors (thanks TechnoGuy)






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.