Dangerous Prototypes

Dangerous Prototypes => Bus Pirate Support => Topic started by: Fozzy Vis on August 06, 2009, 12:40:30 am

Title: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 12:40:30 am
Hi,

First of all, I'm a mere beginner in electronics without a real college type of background. All I did was read books/magazines/sites/... so there are things that I should know about, but don't. Take it as a disclaimer :)

I'm trying to interface a DS1307 RTC chip with the Bus Pirate. I'm doing this on a breadboard. I've connected the Vcc to the bus pirate +5V, the ground to the ground line, and the Vpu to it's own +5V line.
The crystal is in the same holes as the pins from the IC, I've read that it's good practice to keep distances between an ic and an crystal as short as possible.
Vbat is pulled to ground, as stated in the datasheet when a backup battery isn't used.
 There's a 100uF cap over the GND/Vcc lines, I know it's about filtering but don't really know exactly why it's needed. Will read up on that later.

If needed: this is what I got from the terminal with the "i" command:

*----------*
POWER SUPPLIES ON
VOLTAGE MONITOR: 5V: 5.0 | 3.3V: 3.3 | VPULLUP: 5.0 |
AUX: DEFAULT SETTING (AUX PIN)
High-Z outputs (H=input, L=GND)
PULLUP RESISTORS ON
BITORDER CONFIGURATION NOT ALLOWED IN THIS MODE
*----------*

This is what I did:

-initialised I2C mode ("m", "4")
-enabled the pullups ("p", "2")
-enabled power supplies ("W")
-checked pullup voltage ("i"), is fine at 5.0
-checked IC adress on I2C bus ("(1)"), found devices at 0xD0 and 0xD1 (sometimes it also finds something at 0xD2, not sure why?)
-Started the oscillator and set seconds to zero: "[0xd0 0 0]" Gives 3 times ACK
-Defined the minutes to zero as well, just to make sure it starts there "[0xd0 1 0]", all good again

And this is where I'm not sure I'm doing everything ok and the errors start

- "[0xd0 1 [0xd1 r]" gives 2 writes, one read that seems to return a valid number (depending on the delay between the setting to zero en querying the minutes)

-Then trying that same line again gives some errors. Write 0xD0 gives an ACK, the 0x01 DOESN't give ACK, the read gets an ACK seems like it could be fine.

-Trying it again a minute later gets the same faults, then a third time doesn't give an ACK on the writes, gives a ACK on the read, but returns an invalid number (all of a sudden we're supposed to be 17 minutes later?)

I have used this IC with a easyPIC5 board from MikroElektronika and things went smooth then. I'm not sure what I'm doing wrong here.
I've used the BusPirate to talk to a 7221 SPI to 7segment Decoder without any problems.
It seems to be a bit random, and I don't really know where to look anymore... Any hints/tips/thoughts?

If there's any info I forgot to mention, please ask!
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 06, 2009, 04:41:27 am
I am also seeing some incompatibility with I2C and a random assortment of devices. One issue that I've found is that the software I2C routines clock at only about 3.4KHz, which is too slow for some devices. The hardware I2C routines mentioned in another post will hopefully fix this issue.

What speed is the device that you're trying to interface with?
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 06, 2009, 04:54:06 am
Another thought, does the device support "restarts" where the start command is given again without a stop for the last command? Does it work properly if you specify a stop command before the read?
Title: Re: I2C, no ACK at random times
Post by: Scorpia on August 06, 2009, 05:43:25 am
I have some DS1307 chips at home. hopefully i can fire one of them up tonight and see if i get the same result.

Also being that most of the current buspirates cant use the hardware i2c routines (?) , maybe its worth trying to add some options to change the speed of the current routines.

is there an update to the current v2 software that i can grab that will tell me what type of chip i have. i am pretty sure i checked it under MPLAB and it was the earlier one but i am not sure right now.

Peter
Title: Re: I2C, no ACK at random times
Post by: ian on August 06, 2009, 10:38:34 am
Fozzy Vis and I have been discussing this issue by e-mail before moving it here. I'll have one of these chips to work with in a day.

What happens if you use a full stop and start sequence instead of a repeated start?
Quote
[0xd0 1 [0xd1 r] >>> [0xd0 1 ][0xd1 r]

I'd look at how the code handles the repeated start. I didn't write the I2C library, it's GPL'd code from an example site. It's always worked fine for me, so I've never bothered with it. Maybe we should write a public domain version with more options?

The speed issue is a possibility. I second a speed option that reduces the delays in the I2C library, either as a setup step or as a configuration macro(#). It would probably be worth checking I2C.c and base.c for delay problems too, for a while there was a variable type overflow problem with one of the delays but I think I caught it a while back.

The latest nightly build adds version check with the 'i' menu. PIC revisions: A3/A4=0x3003, B4=0x3042, B5=0x3043
Title: Re: I2C, no ACK at random times
Post by: Scorpia on August 06, 2009, 12:35:30 pm
i have been searching high and low but i cant find a 32k crystal here. i thought i had one but i cant find it.

which gave me a good idea. can the pwm output keep outputting while switching to a diff mode?

the idea being that the bus pirate should be able to generate a osc freq to clock the chip while looking at it.

i know it wouldnt be that accurate but it seems like a good idea to me. maybe some common freq might be a good idea .

anyway i will pick up a couple of crystals tomorrow as i want to test this anyway as well as the ds2404 chip i have.
Title: Re: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 01:20:40 pm
JoseJX:

The datasheet specifies an Fscl of max 100 KHz, I'm not sure if that's fast or not.
I've also tried writing it like: [0xd0 1] [0xd1 r], which gave the same problems as well.

Please also consider it could be a stupid mistake from my side. However it's strange that is sometimes works and sometimes not...
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 06, 2009, 01:28:55 pm
I put a patch up to allow for the original clock speed and 10x faster using software I2C, ~5KHz and ~50KHz. I still haven't had a chance to measure it exactly, but will do so later today. Try it and see if the faster speed helps?

http://dev.gentoo.org/~josejx/bus_pirat ... ster.patch (http://dev.gentoo.org/~josejx/bus_pirate/i2c_faster.patch)
Title: Re: I2C, no ACK at random times
Post by: ian on August 06, 2009, 01:39:22 pm
Patch applied, compiled into nightly. Not tested though.
Title: Re: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 01:52:01 pm
I'll try it as soon as I find out how to update the chip.
I'll need some time figuring it out but will try as soon as possible.
I suppose I'll find the nightly build on the SVN/Google code page, and have to compile it with MPLab and then update it with the bootloader. I've seen instructions for the last part on your site, will look into the compiling asap.
Title: Re: I2C, no ACK at random times
Post by: ian on August 06, 2009, 02:00:30 pm
The nightlies are already compiled. Just grab it from the link on the google code page and upgrade with the quick programmer utility for windows or python.
Title: Re: I2C, no ACK at random times
Post by: ian on August 06, 2009, 02:01:45 pm
http://code.google.com/p/the-bus-pirate ... tly/BPv2go (http://code.google.com/p/the-bus-pirate/source/browse/#svn/trunk/firmware/v2-nightly/BPv2go)
Title: Re: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 02:54:10 pm
Code: [Select]
(1) >4
MODE SET
Set speed:
 1. Slow(~5KHz)
 2. Fast(~50KHz)
SPEED>(1) >1
I2C routines Copyright (C) 2000 Michael Pearce
Released under GNU General Public License
I2C READY
I2C>W
POWER SUPPLIES ON
I2C>p
 1. Pullup off
 2. Pullup on
(1) >2
PULLUP RESISTORS ON
I2C>i
Hack a Day Bus Pirate v2go
http://www.buspirate.com
Firmware v2.1-nightly
DEVID:0x04 0x47
REVID:0x30 0x03
CFG1:0xF9 0xDF
CFG2:0x3F 0x7F
*----------*
POWER SUPPLIES ON
VOLTAGE MONITOR: 5V: 5.0 | 3.3V: 3.3 | VPULLUP: 5.0 |
AUX: DEFAULT SETTING (AUX PIN)
High-Z outputs (H=input, L=GND)
PULLUP RESISTORS ON
BITORDER CONFIGURATION NOT ALLOWED IN THIS MODE
*----------*
I2C>(1)
Searching 7bit I2C addresss space.
   Found devices at:
0xD0 0xD1
I2C>[0xd0 0 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x00
I2C STOP CONDITION
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: NO
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x01
I2C STOP CONDITION
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: NO
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x03
I2C STOP CONDITION
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: NO
WRITE: 0x01 GOT ACK: NO
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x02
I2C STOP CONDITION
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: NO
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x54
I2C STOP CONDITION
I2C>

Same problems, with both speed settings. Also using [0xd0 1] [0xd1 r] doesnt change anything...
Title: Re: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 02:58:32 pm
One thing I've noticed, the first two lines (the setting of the two registers) never seem to give any problems...
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 06, 2009, 03:44:55 pm
Can you do as many writes as you want? Is it only reading that's screwing up?

On my PIC18F that I'm using as a test slave device, I am seeing reads miss the final stop bit (bulk or not). Sending a write with two 0's seems to fix it and let it work again. I missed this before because I was just testing a write followed by a read. :p

I will hook it up to a logic analyzer later today to see if it's properly sending the stop condition after a read.
Title: Re: I2C, no ACK at random times
Post by: Fozzy Vis on August 06, 2009, 04:11:16 pm
I tried sending the same write over and over again.
The first write (which came after a read) didn't work properly, but afterwards, no problems anymore.

I'm not 100% sure if I understand your explanation about the 18F afterwards (with the double "0").

Still wonder if the problem is just with me or not..

Code: [Select]
I2C>[0xd0 1 [0xd1 r]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: NO
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x54
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: NO
WRITE: 0x00 GOT ACK: NO
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 1 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 06, 2009, 05:08:46 pm
Sorry if I wasn't clear, here's what I'm talking about:

Quote
I2C> { 0x52 0x00 0x65 } Write 2 bytes to the PIC at address 0x52, starting at internal address 0x00
I2C START CONDITION
WRITE: 0x52 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
WRITE: 0x65 GOT ACK: YES
WRITE: 0x66 GOT ACK: YES
I2C STOP CONDITION
I2C> { 0x52 0x00 } { 0x53 r r } Write internal address to 0x00, then read two bytes
I2C START CONDITION
WRITE: 0x52 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C START CONDITION
WRITE: 0x53 GOT ACK: YES
READ: 0x65
READ: 0x66
I2C STOP CONDITION
I2C>

This was the test I was running before. It works up to this point. If I follow this up with other commands, the device doesn't respond properly and continues each command as a read as observed by a dump of the internal I2C registers to an LCD on the PIC18F. It stays stuck (no stop rx'd) until I send a command that ends in 0's:

Quote
I2C> { 0x52 0x00 0x00 }
I2C START CONDITION
WRITE: 0x52 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>

After this, I can write to the internal registers and start another read cycle. I'm not 100% sure where the bug is (in my PIC18F code or in the bus pirate) but it should be pretty obvious once I get the Logic Analyzer attached.

On a side note, I2C on PIC is harder than it initially appears. :)
Title: Re: I2C, no ACK at random times
Post by: ian on August 06, 2009, 08:18:09 pm
As you'll note on your LA, the byes come in squirts while the terminal waits to push characters through the serial port. That could also be a potential issue.

There's a three byte UART hardware buffer, but the long term goal (on the issue tracker) is to have a big buffer (2000K?) that feeds the serial TX on an interrupt.
Title: Re: I2C, no ACK at random times
Post by: ian on August 08, 2009, 07:09:07 pm
I got a sample DS307 from Fozzy Vis today. Here's my attempt to interface it with the new hardware I2C module:

Quote
HWI2C>W
POWER SUPPLIES ON
HWI2C>p
 1. Pullup off
 2. Pullup on
(1) >2
PULLUP RESISTORS ON
HWI2C>v
VOLTAGE MONITOR: 5V: 4.9 | 3.3V: 3.3 | VPULLUP: 5.0 |
HWI2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
HWI2C>

Turn on the power supplies, turn on the pull-up resistors, check that voltages are OK, search for I2C address.
Datasheet page 12 says the slave address is 1101000x where x is R/W. 0b11010000=0xd0, so success!

Quote
HWI2C>[0xd0 0 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd0 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd1 r:8]
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x08 BYTES:
0x00 0x00 0x00 0x01 0x01 0x01 0x00 0x03
I2C STOP CONDITION
HWI2C>

I reset the Clock Halt (CH) bit of byte 0 to 0, enabling the clock. I then set the read/write pointer to 0 and read the 8 time-related bytes.

Quote
HWI2C>[0xd1 0x8 3 2 1]
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
WRITE: 0x03 GOT ACK: YES
WRITE: 0x02 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd1 0x8]
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C STOP CONDITION
HWI2C>[0xd0 r:3]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
BULK READ 0x03 BYTES:

Next I wrote three bytes (3 2 1) to the RAM addresses 0x8+. Unfortunately, when I read it back the Bus Pirate freezes waiting for a reply.


So, now I'll try it with the software library at high speed.

Quote
HiZ>m
1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC KEYBOARD
10. MIDI
11. LCD
12. HWI2C
(1) >4
MODE SET
Set speed:
 1. Slow(~5KHz)
 2. Fast(~50KHz)
SPEED>(1) >2
I2C routines Copyright (C) 2000 Michael Pearce
Released under GNU GPL
I2C READY
I2C>W
POWER SUPPLIES ON
I2C>p
 1. Pullup off
 2. Pullup on
(1) >2
PULLUP RESISTORS ON
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
I2C>

Good so far...

Quote
I2C>[0xd0 0 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 0]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x00 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd1 r:8]
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x08 BYTES:
0x00 0x00 0x00 0x01 0x01 0x01 0x00 0x03
I2C STOP CONDITION
I2C>

Write 0 to CH bit, then reset read/write pointer and read the 8 clock-related bytes.

Quote
I2C>[0xd0 0x8]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 0x8 1 3 3 7 ]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
WRITE: 0x03 GOT ACK: YES
WRITE: 0x03 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 0x08]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd1 r:4]
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x04 BYTES:
0x01 0x03 0x03 0x07
I2C STOP CONDITION
I2C>

Now, set to ram 0x08, write 1 3 3 7, read it back. All worked OK.

Quote
I2C>[0xd0 0x08 [ 0xd1 r:4]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x04 BYTES:
0x40 0x01 0x01 0x01
I2C STOP CONDITION
I2C>

If I try a repeated start like you did, I get the wrong data. Don't know who sent what, I'll have to drag out the LA to be sure. I'm almost certain it's a problem with the library.

Quote
I2C>[0xd0 0x08] [0xd1 r:4]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C STOP CONDITION
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x04 BYTES:
0x20 0x01 0x00 0x90
I2C STOP CONDITION
I2C>[0xd0 0x08] [0xd1 r:4]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: NO
WRITE: 0x08 GOT ACK: NO
I2C STOP CONDITION
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x04 BYTES:
0x00 0x00 0x01 0x25
I2C STOP CONDITION
I2C>

I tried several ways to read everything in a single command, including with a delay (&:255). First time I just got the wrong values, the second time I had an ACK problem like you experienced.

For now, try read and write commands in seperate entries. In the long term, it looks like there's a bug in SW I2C and a timeout is needed in the HW I2C.
Title: Re: I2C, no ACK at random times
Post by: ian on August 09, 2009, 10:58:17 am
Found a minor non-problem...

The SW I2C routine is one of two pieces of GPL code in the Bus Pirate. It came with a uS delay routine that used a signed const char as the variable type. For some reason I never migrated it to the bpDelayUS function shared by all other libraries. This wasn't actually a source of a problem because all the I2C delays are less than 128, I initially thought I solved it though. I migrated it anyway, maybe it will be more reliable.

New nightly for v2go with cleaned up delays and terminal I/O is in the SVN.
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 10, 2009, 05:38:52 pm
I think I've found another problem, while reading the specs and some sites about I2C. I've noticed that your software implementation doesn't send a NACK after reading the last byte.

On this site, it suggests that's a requirement:
http://www.robot-electronics.co.uk/htm/ ... 2c_bus.htm (http://www.robot-electronics.co.uk/htm/using_the_i2c_bus.htm)

I've decided to rewrite the software I2C routines using the outline on this website. The size of the code drops by about 250 bytes with my new routines and they'll be licensed the same way as the rest of the BP code, which is nice. I've been busy over the weekend and didn't have time to test the code, but will have a chance in the evening tonight. Once I'm sure it's okay, I'll post the diff and hopefully we'll have something working properly.
Title: Re: I2C, no ACK at random times
Post by: ian on August 10, 2009, 06:12:28 pm
That's fantastic. I'd thought about doing it, but I'm so familiar with the old code that I don't think I could make a non-infringing version.

After reading the page I'm not sure if the SW library does clock stretching, which could also be a problem. It should probably have a timeout.

For NACKing the last byte, I'm not sure. I think it just signals the slave the TX is over, which the stop condition also does. The NACK ends the read high, so SDA still needs to go low again before the stop condition can happen. We can try some tests with the raw2wire library. [] also create I2C style start/stop pulses in that library, and the ack can be simulated by setting the ACK (_) or NACK (-) and doing a clock tick (^).
Title: It's ugly, really ugly
Post by: ian on August 13, 2009, 03:39:16 pm
I used a Saleae Logic to look at the signals. It's not pretty.

All my tests used the search for device ID macro, I didn't bother to look at anything else.

With the software I2C my first search for device scan works fine, but then I always get an extra device (0xd2) on subsequent searches (as noted also by Fozzy Vis):

Quote
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1 0xD2
I2C>

On the first scan (T3) it works, but you can see in the waveform that there's no proper stop condition for the NOACK addresses. On the second time through there's a bunch of garbage for two bytes after the first two addresses which causes the 0xd2 ACK (T4).

I looked at the I2C code and noticed that the getack() function just exists and doesn't complete the clock cycle if there's no ack. I changed this and tried again with prettier, but no more successful results (T6 first try, T7 second try).

My first thought is to go through and make sure every function starts and stops with the proper bus state, etc. But there's no point in doing that to the GPL code if you're going to post a patch to replace it.

*0x68 + W/R = 0xd0/0xd1
Title: Re: I2C, no ACK at random times
Post by: JoseJX on August 13, 2009, 06:16:54 pm
Sorry, I've been kind of busy with work and haven't had time to figure out what's not working with my I2C code (with open drains turned on, it seems to always hold the line low, even if the tristate shouldn't be allowing that). I'll hopefully get a chance next week, but I can't promise anything right now.

Sorry again!
Title: Re: I2C, no ACK at random times
Post by: ian on August 13, 2009, 06:25:33 pm
No problem, today is the first chance I've had to get out the logic analyzer.

In my experience the open drain pin only works for outputs, the OD configured pin won't work as an input until you clear the open drain bit. It's easier to set PORT to ground and then switch TRIS.
Title: Re: I2C, no ACK at random times
Post by: ian on August 17, 2009, 01:18:12 pm
I wrote my own I2C routines using the public domain pseudo code posted here:
http://www.esacademy.com/faq/i2c/general/i2cpseud.htm (http://www.esacademy.com/faq/i2c/general/i2cpseud.htm)

They're not great, just enough to play with. I think I'm going to make a base library of bitbang commands to share among all the software libraries (1-wire, I2c, raw2/3wire, JTAG, LCD).

The address scanner problem is this: when the address scanner sends a read address some chips go immediately into read mode and create bus contention that prevents us from making the stop condition. That's why it's always an extra address after the read address, we send the read address and then the chips clocks out 8bits before it gets a NACK on the final byte. You can see it happen in the attached LA output.

Couple solutions:
1. Just scan write addresses, read address can be inferred as +1. But what about hidden read-only ports?
2. Change current search to send 0 and then NACK when it gets an ACK on a read address.
3. Variations on the above themes.

I've implemented #2, it's rock stable so far (second image below).

Quote
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
I2C>(1)
Searching 7bit I2C address space.
   Found devices at:
0xD0 0xD1
I2C>(1)

I am open to other suggestions. I'd eventually like to display the 7bit I2C base address as well as the raw read/write address so it's consistent with my logic analyzer.

Now I'm going to implement the rest of the new library and see if I can clear up the other issues.
Title: Re: I2C, no ACK at random times
Post by: ian on August 18, 2009, 11:53:20 am
This should solve the problem with reads on the DS1307. I've uploaded the latest compile to SVN, but I'm going to test all the changes and release as 2.1RC1 since this was such a huge bug.

These examples read and write from the DS1307 RAM located at 0x08 to 0x3f.

Quote
I2C>[0xd0 8 7 6 5 4 3 2 1 ]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
WRITE: 0x07 GOT ACK: YES
WRITE: 0x06 GOT ACK: YES
WRITE: 0x05 GOT ACK: YES
WRITE: 0x04 GOT ACK: YES
WRITE: 0x03 GOT ACK: YES
WRITE: 0x02 GOT ACK: YES
WRITE: 0x01 GOT ACK: YES
I2C STOP CONDITION
I2C>[0xd0 8 [ 0xd1 rrrr]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x07 ACK <<
READ: 0x06 ACK
READ: 0x05 ACK
READ: 0x04 NACK <<
I2C STOP CONDITION
I2C>

The I2C library now uses a delayed ACK/NACK on reads. When I2C reads begin, the Bus Pirate won't issue a (N)ACK until the next operation. If the next operation is a stop (or start in case of repeated starts) the Bus Pirate sends a NACK on the 9th bit. On all other operations it sends an ACK. This doesn't effect writes where the slave ACKs to the Bus Pirate. The terminal output now shows the (N)ACK status.

Quote
I2C>[0xd0 8 [0xd1 r
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
READ: 0x07 *(N)ACK PENDING <<
I2C>r
 ACK <<
READ: 0x06 *(N)ACK PENDING <<
I2C>r
 ACK
READ: 0x05 *(N)ACK PENDING
I2C>r
 ACK
READ: 0x04 *(N)ACK PENDING
I2C>]
 NACK <<
I2C STOP CONDITION
I2C>

If you leave a read without an additional operation, then the read isn't complete because the 9th bit (ACK) hasn't been sent. The Bus Pirate will warn you of this.

This should work fine for every chip I've tested or demoed in the past. It might have issues if there's protocols that switch reads and writes between START ([) and STOP (]) statements, but I'm not aware of anything that does this.

I've moved all the software library bitbang functions to bitbang.c, and adapted the I2c, raw2/3wire, and LCD libraries to share them. 1-wire and Jtag will also be added eventually. All software libraries now have a speed option, for the moment only low speed is tested, high speed seems to have some unresolved timing issues.

EDIT: Also works for bulk reads.
Quote
I2C>[0xd0 8 [0xd1 r:5]
I2C START CONDITION
WRITE: 0xD0 GOT ACK: YES
WRITE: 0x08 GOT ACK: YES
I2C START CONDITION
WRITE: 0xD1 GOT ACK: YES
BULK READ 0x05 BYTES:
0x07 ACK 0x06 ACK 0x05 ACK 0x04 ACK 0x03 NACK
I2C STOP CONDITION
I2C>
Title: Re: I2C, no ACK at random times
Post by: ian on August 18, 2009, 02:42:05 pm
Release candidate info and link (http://http://dangerousprototypes.com/2009/08/18/bus-pirate-firmware-v2-1-rc1/). Please let me know if this helps.
Title: Re: I2C, no ACK at random times
Post by: ian on August 25, 2009, 10:36:47 am
Here's a full update guide and "incident analysis" (http://http://dangerousprototypes.com/2009/08/25/bus-pirate-i2c-updates-in-firmware-v2-1/) of the I2C problem.
Title: Re: I2C, no ACK at random times
Post by: ian on September 04, 2009, 10:50:06 am
I finally posted a demonstration of this chip:
http://dangerousprototypes.com/2009/09/ ... ime-clock/ (http://dangerousprototypes.com/2009/09/04/chips-ds1307-i2c-real-time-clock/)
Title: Re: I2C, no ACK at random times
Post by: tiopepe123 on October 02, 2009, 11:44:00 pm
I are tested  eeprom of the series 24CXX, 24c02 and 24c04
I am writing and reading are correct but it always finishes with NACK

Vcc =5V
VPU=5V


Bus Pirate v2go
http://dangerousprototypes.com (http://dangerousprototypes.com)
Firmware v2.2
DEVID:0x0447 REVID:0x3043 (B5)

1. HiZ
2. 1-WIRE
3. UART
4. I2C
5. SPI
6. JTAG
7. RAW2WIRE
8. RAW3WIRE
9. PC KEYBOARD
10. MIDI
11. LCD
(1) >4
Modalidad seleccionada
Modo I2C:
 1. Software
 2. Hardware
(1) >1
Elegir velocidad:
 1. Baja(~5KHz)
 2. Alta(~50KHz)
(1) >2
LISTO

I2C>W
ALIMENTACIÓN ENCENDIDA
I2C>P
 1. Pull-ups activadas
 2. Pull-ups desactivadas
(1) >1
Activar resistencias Pull-up
I2C>I
Bus Pirate v2go
http://dangerousprototypes.com (http://dangerousprototypes.com)
Firmware v2.2
DEVID:0x0447 REVID:0x3043 (B5)
*----------*
ALIMENTACIÓN ENCENDIDA
Sensores de tensión: 5V: 4.9 | 3.3V: 3.2 | VPULLUP: 4.9 |
a/A/@ controla pin AUX
Salidas en drenador abierto (H=entrada, L=GND)
Activar resistencias Pull-up
Configuración de orden de bits no permitida
*----------*


I2C>(1)
Buscando direcciones I2C de 7bit.
   Encontrados dispositivos en la dirección:
0xA0(0x50 W) 0xA1(0x50 R) 0xA2(0x51 W) 0xA3(0x51 R) 0xA4(0x52 W) 0xA5(0x52 R) 0xA6(0x53 W) 0xA7(0x53 R) 0xA8(0x54 W) 0xA9(0x54 R) 0xAA(0x55 W) 0xAB(0x55 R) 0xAC(0x56 W) 0xAD(0x56 R) 0xAE(0x57 W) 0xAF(0x57 R)



I2C>{0xa0 0 0}
BIT DE START I2C
ESCRITURA: 0xA0 ACK
ESCRITURA: 0x00 ACK
ESCRITURA: 0x00 ACK
BIT DE STOP I2C




I2C>{0xa1 r}
BIT DE START I2C
ESCRITURA: 0xA1 ACK
LECTURA: 0x01 NACK
BIT DE STOP I2C


or

I2C>{0xa1 r:5}
BIT DE START I2C
ESCRITURA: 0xA1 ACK
LECTURA 0x05 BYTES:
0x01 ACK 0x02 ACK 0x03 ACK 0x04 ACK 0x61 NACK
BIT DE STOP I2C

to end NACK?

failure : Hardware and software, low speed (5k,50k and 100k)
Title: Re: I2C, no ACK at random times
Post by: ian on October 03, 2009, 12:06:11 am
@tiopepe123 - http://dangerousprototypes.com/2009/08/ ... ware-v2-1/ (http://dangerousprototypes.com/2009/08/25/bus-pirate-i2c-updates-in-firmware-v2-1/)
Title: Re: I2C, no ACK at random times
Post by: tiopepe123 on October 05, 2009, 12:30:07 am
Sorry, sorry....thank you

I am read slow this link