<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
Volker<br>
I have a scan from Silicon Chip Mar 2008 for an I2c Debugging tester
using the Phillips URD312.exe program.<br>
<br>
If you are interested I can get it to you...(Its 11MB pdf as I always
scan at 300/400dpi).<br>
<br>
<br>
Not many parts, email me and I send you the cct I chopped out of the
pdf.<br>
<br>
If anyone else is interested, let me know and I'll print out some
copies for the 20th.<br>
<br>
Mark<br>
<br>
<br>
Volker Kuhlmann wrote:
<blockquote cite="mid:20110604042439.GF11877@paradise.net.nz"
type="cite">
<pre wrap="">On Sat 28 May 2011 13:51:54 NZST +1200, Mark Atherton wrote:
Thanks Mark + Charles. Sorry for late reply, days are too short.
</pre>
<blockquote type="cite">
<pre wrap="">Have you tried other AD I2C devices using the
same master you attempted to read the AD part you referenced ?
</pre>
</blockquote>
<pre wrap=""><!---->
I am using other I²C devices with the same master (Arduino) and they
work fine. I don't have other AD parts to test.
</pre>
<blockquote type="cite">
<pre wrap="">What is the mode of failure - no ack ?
</pre>
</blockquote>
<pre wrap=""><!---->
If I knew better, I'd be closer to a solution... A decent storage scope
would help, but they're $$$$$^15 for home use, though I could access one
at work.
I am not getting the values from registers that I am expecting, though 1
or 2 are close. Writing into registers seems not to do much either.
</pre>
<blockquote type="cite">
<pre wrap="">Are you sure you have the address correctly set -
some datasheets place the addr bits shifted from
the R/W bit so addr 0xA0 could be interpreted as
a write to 0x50, and 0xA1 could be interpreted as a read from 0x50 etc.
</pre>
</blockquote>
<pre wrap=""><!---->
I tried both, and checked this sevral times, and one worked better than
the other.
</pre>
<blockquote type="cite">
<pre wrap="">If you want to mail me a device, I have several
sources of I2C masters and have never had a
failure with a slave the way that you describe.
</pre>
</blockquote>
<pre wrap=""><!---->
I might take you up on that just for couriosity - thanks!
The problem might also be that I damaged the chips soldering. They're in
ceramic tiny cases with no pins, just strips of metal surface
underneath. I'm pretty sure the soldering job is ok, but I certainly
exceeded the temperature/time limits mentioned in the datasheet. They
shouldn't have ESD damage.
I have had some signal issues with an Atmel flash chip connected via
SPI, sticking wires into Arduino female headers. There was the
occasional data corruption. Using the "screw shield" (a small PCB with
screw terminals and pins to stick into the Arduino board) made things
hugely worse. I couldn't find a soldering problem anywhere (soldered
wires onto tracks to be sure), and total line length would have been
<~120mm, but the tracks going round the corner a few times seems to
damage the signal sufficiently to make this protyping approach basically
useless.
On Mon 30 May 2011 09:17:02 NZST +1200, Charles Manning wrote:
</pre>
<blockquote type="cite">
<pre wrap="">I would do three things:
(1) Slow the clocking right down. Start with 10kbits/sec or so.
(2) Check the pull-ups.
(3) Us short-sh wires (30cm or so max).
</pre>
</blockquote>
<pre wrap=""><!---->
(1) I tried with the lowest clock the AVR could be set to, no
difference. Couldn't try snail's pace because I couldn't find a software
I²C library online and didn't want to make my own just for this test.
(2) CPU internal. Adding some resistors made no difference.
(3) Would have been 10-15cm total.
The I²C software I have works fine with the DS3231 (using the CPU
interface), so there shouldn't be a major systematic bug.
Hence I had given up for the time being. :(
Thanks again,
Volker
</pre>
</blockquote>
<br>
</body>
</html>