Argg - hi2c slave problem with 28X-1

[Brietech]

I'm using a 28X-1 with the A.0 firmware, and version 5.1.1 of the programming editor. Reading from the chip works fine. Whenever I attempt to write to my 28X-1 chip, though, the data never seems to get written to the chip. I'm using the following code for the i2c slave chip:

hi2csetup i2cslave,%10100000
ptr = 0
@ptrinc = 1
@ptrinc = 2
@ptrinc = 3
main:
for b0 = 0 to 10
ptr = b0
sertxd(#@ptr)
next b0
sertxd("hi2clast: ",#hi2clast)
if hi2cflag = 0 then main
sertxd("i2c works&quot
hi2cflag = 0

goto main


The thing writing to it does the following:
1) writes out a start bit and the i2c address
a) wait for acknowledge
2) writes one address byte
a) wait for acknowledge
3) write one data byte
a) wait for acknowledge
4) stop bit

From looking on a scope:
After writing the i2c address, the chip successfully acknowledges by holding the 9th bit low, but after writing the address byte and data byte, the chip doesn't hold the 9th bits low. The data on the chip never changes.

Any thoughts? (The i2c master is an FPGA, but it works fine with normal 24LCXX chips)

 

[Technical]

Try reducing the i2c bus speed. Remember 0-127 are the only valid data addresses. We presume you have remembered to remove the eeprom from the bus to prevent an address clash! Also try simplifying your program for initial testing:

hi2csetup i2cslave,%10100000
main:
pause 1000
if hi2cflag = 0 then main
sertxd("hi2clast: ",#hi2clast, cr, lf)
hi2cflag = 0
goto main

 

[Brietech]

It's only going at 100 khz, and it is the only thing on the bus. The I2C ID I'm using is the same as a typical EEPROM (10100000), per the example in the BASIC manual. Am I correct in thinking that the 28X-1 should be holding the bus low for 1 bit after receiving the address byte and data byte? Devices with only 1-byte addresses don't have any weird rules, do they? Like I said previously, it worked fine using a 24LC512 I had lying around (2-byte address).

 

[Technical]

No special rules for single byte address. If you can read from the PICAXE over the i2c bus using a single byte address, there is no obvious reason why you shouldn't be able to write. Have a look at a 24LC16B datasheet for i2c explanation of when bits are low (ACK and NACK) - the PICAXE behaves in the same way. On the FPGA make sure the r/w bit in the slave address is correct, and you could try increasing the time delay between transmission of the slave, address and data bytes - the PICAXE does need a small amount of time to process the i2c interrupt for each of the three bytes as they are received.

 

[Brietech]

Still no luck. I upped the speed of the 28X-1 to 16 mhz (from 4 mhz), and dropped my i2c clock down to 50 khz. I am getting the exact same response, where the picaxe acknowledges after I send the ID byte, but won't acknowledge on the address or data bytes. Does it need like a couple milliseconds or something? Does it use clock-stretching, possibly? Has anyone gotten a non-picaxe device to talk to a picaxe in i2c slave mode?

 

[Technical]

There doesn't seem to be anything obvious wrong. Do you have spare 28X / 28X1 knocking around? We would suggest hooking this up a master, and then comparing the waveforms with your FPGA setup.

 

[Brietech]

I do actually (I have a spare 18x and a spare 28X-1), but won't have access until tomorrow. I'll give it a shot.