Netduino home hardware projects downloads community

Jump to content


Photo

Possible i2c issue from shorting something on Netduino

shorted fried error exception

  • Please log in to reply
5 replies to this topic

#1 dhensel

dhensel

    New Member

  • Members
  • Pip
  • 7 posts
  • LocationBoston, MA

Posted 14 May 2015 - 05:37 PM

Hi everyone, I have been working with a Netduino 2 for a little over a month for a pneumatic solenoid controller for work.  I've used a stack of shields to give me relays, SD/RTC, screw terminals for switches and triggers, and an LCD screen to top it off.

 

While using it yesterday, something moved and an exposed alligator clip touched the solder terminals on my Adafruit LCD screen and it appears to have damaged the Netduino 2 board because the components causing errors (DS1307 raises exception, LCD screen "doesn't work") test fine when put into a known working Arduino Mega 2650. 

 

For more information, I have a link to the thread I posted on the adafruit forum https://forums.adafr...=373595#p373595

 

Since this seems to be related to the Netduino now, I wanted to post here and get your input.  Is there anything that can be done to "save" this, or is a new board on order the best next step?



#2 Chris Walker

Chris Walker

    Secret Labs Staff

  • Moderators
  • 7767 posts
  • LocationNew York, NY

Posted 14 May 2015 - 05:59 PM

Hi dhensel,

Looking at the other thread... Is the LCD damaged in that photo--or is that the normal readout?
image: https://forums.adafr...le.php?id=25627

On the Netduino... With 3.3V power shorts the MCU will often survive okay...and will instead sacrificing individual pins.

Do you have an LED handy? If you plug an LED into each of the digital pins (and GND), you should be able to toggle it on/off via OutputPort.Write. If the I2C SDA/SCL pins are burnt out, that will help you diagnose that as the result.

BTW, to save you a few dollars if the I2C pins are burnt out: it is possible to use software I2C (using one of the NETMF software I2C classes out there) using other digital pins. This would require some wiring between two other digital pins and the SDA/SCL pins--and maybe moving or cutting off the bottom legs of your shield's I2C pin headers.

Netduinos have quite a bit of protection (reverse voltage, USB ESD, etc.). But in the end they're running Cortex cores and Cortex cores are so dense internally that there is physically not a lot of extra room for extra protection against shorts and such. All that said, it still makes me sad when I see a damaged board.

Let me know how we can help you diagnose this further, provide workarounds or tips to get you back up and running, etc.

Here to help,

Chris

#3 dhensel

dhensel

    New Member

  • Members
  • Pip
  • 7 posts
  • LocationBoston, MA

Posted 22 May 2015 - 07:23 PM

Thanks for the quick response and sorry for the long delay!  This project has been put on "hold" a bit, but I did manage to get my controller running on a modified code to perform the minimum tasks I needed.  

 

The LCD screen shield has it's own issue, verified by using it (successfully) on a different microcontroller.  That being said, my SD/RTC shield worked properly on the other microcontroller but raised exceptions on the Netduino.

 

I'll work on debugging the netduino with an LED when I get a chance to, and follow up then.
 
Thanks! 
Dave


#4 dhensel

dhensel

    New Member

  • Members
  • Pip
  • 7 posts
  • LocationBoston, MA

Posted 29 May 2015 - 03:15 PM

So an update:

Pins D0 - D13, SCL, SDA, A0 - A5 will light up an LED when used as an OutputPort. 

Pins A0 - A5 also read realistic values from an accelerometer I have (eg: gravity as a known value)

 

Still, I'm having an issue with the Datalogging Arduino Shield, not writing to the SD card and throws the exception when I try to set the time or synchronize the DS1307.

 

Any ideas of what else to test?  Again, this shield works when used on an Arduino Mega that we have here.

 public void SetTime(DateTime Time)
        {
            // Writing 7 bytes to the buffer, starting at address 0
            int BytesTransferred = this._Device.Write(new byte[] {
                0x00, 
                (byte)Tools.Hex2Dec(Time.Second.ToString()),
                (byte)Tools.Hex2Dec(Time.Minute.ToString()),
                (byte)Tools.Hex2Dec(Time.Hour.ToString()),
                (byte)Tools.Hex2Dec(((int)Time.DayOfWeek).ToString()),
                (byte)Tools.Hex2Dec(Time.Day.ToString()),
                (byte)Tools.Hex2Dec(Time.Month.ToString()),
                (byte)Tools.Hex2Dec((Time.Year - 2000).ToString())
            });
            if (BytesTransferred != 8) throw new ApplicationException("Something went wrong setting the time. Did you use proper pull-up resistors and is there a 3V battery connected?");
        }

This is the exception thrown, so it's not writing bytes to the buffer.  There is a good battery connected, and I have not changed any pull-up resistor modes or anything physically on the board.  This code used to run without errors before.

 

Oddly enough, the onboard LED1 and LED2 do not light up - they're supposed to be tied to D2 and D3.


Edited by dhensel, 29 May 2015 - 04:00 PM.


#5 Nevyn

Nevyn

    Advanced Member

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

Posted 29 May 2015 - 05:06 PM

Is it something as simple as the fact that the shield is a 5V shield and the Netduino only output 3.3V?

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


#6 dhensel

dhensel

    New Member

  • Members
  • Pip
  • 7 posts
  • LocationBoston, MA

Posted 30 May 2015 - 01:00 AM

The shield used to work fine, until something happened - possibly a short to the LCD shield which is known to be damaged now.  After that incident, the n2 does not seem to write to SPI devices and the LCD shield is unresponsive.  At least on the Mega, the LCD shield worked 50% but with visible defects (see earlier link to adafruit forum), but the SD/RTC shield was fine.

 

On a side note, it seems like the n2 can create files on the SD card, but they remain empty and nothing is written to them.  Again, possibly this SPI not writing any bytes, however there is no exception thrown on the SD card... just nothing happens.







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.