I2C slave issues

[mob1182]

I've been trying to do some work with I2C, sending info from one pic to another, and I'm having some strange difficulties. So I stripped my slave code down as much as I can but I still don't know what I'm doing wrong. Actually everything seems to be working fine until I add a large enough global array. Or if I add few libraries. Basically anything large enough before the INT.

Compiler PCWH 5.066

Slave code

[Ttelmah]

Look at the examples.....

Your I2C_ISR is 'missing the point a little'.

The interrupt will occur when the address byte is received as well as data, so you need to use the value from the I2C_ISR_STATE to determine what the slave is actually to do, and reset the 'i' counter.
Without this, data written to the array _will_ eventually risk overflowing, and this will then overwrite the other variables. Result 'disaster'....

[mob1182]

Thanks Ttelmah, but what I'm trying to say is that the state of the ISR is always 0, even if I change the r/w bit in the address the master is sending for a read instead of a write. I never get 0x80, or 1, or 2... and believe me I looked at the examples and datasheets over and over before I came here. I've read sec 26.9.2.1 on the pic datasheet so I understand it interrupts after an address match and every byte of data. That's why I have the 500ms delay, to allow all the data to come in. And this is just a test program to read the state value and data. The final version will a lot different, more like the ccs example. And the "i" variable does get reset in the while(true) loop. I am currently controlling the data being sent so for know it is only a few bytes to not overflow the array. When I broadcast a command in teraterm, it gets saved to pKeyword[1] and send to the slave. So im personally keeping it to only a few bytes. But maybe I am missing the point a little, and I'm still missing it lol. Obviously I'm doing something wrong cause it doesn't work

[Ttelmah]

Your master needs to send the last byte in the transaction with a NACK. This marks the end of transaction (not actually the stop).
In the 'long' transaction, the slave is looping with the I2C in an error state (since the transaction has not correctly terminated), and overwriting the state bytes, so you just see zero).

[mob1182]

Ok I'm just a little confused. I thought that was only for a slave transmission to the master? To indicate to the master that the slave is done. Not for the master to tell the slave its done.

This is a slave reception. I don't see this in the i2c spec anywhere. Nor in the pic datasheet in 26.9.2.1 for slave reception or 26.10.6.3 for master transmission.

[Ttelmah]

Apologies it is your slave that has the problem here.
The point is you may well have another problem, but lets get your code tidy, and workable to see. You only needed to post about ten lines for the transmit side, and twenty for the receive, instead we have a huge amount that is much too complex.
You are _forcing_ an ACK on everything in the slave, but the hardware handles the ACK/NACK for the slave. Forcing it will cause problems.

[mob1182]

Ok so take the "1" argument out of i2c_read()?
To simplify I removed that from the read and the stream argument since its the only i2c stream.

Still having the same problem

Now this works. When I send the characters "12" from the master I get 0,1,2 for the state array and 160,49,50 for the data array, which is correct. address A0 = 160, acii 1 = 49 and acii 2 = 50.

[Ttelmah]

OK. Now we have something small enough to look at.

There was a very similar thread a few weeks ago, and another that may relate:

<http://www.ccsinfo.com/forum/viewtopic.php?t=55779>
So, what programmer are you using?.

The other was actually using a bootloader, and this was not setup correctly and causing a problem as soon as an array went over a certain size.

[mob1182]

Ha yea that link is my post too from before Christmas. So I can't get the icd-u64 programmer to program correctly for this particular chip. I've used it just fine for other older chips. This chip is fairly new. Came out middle of last year I believe(could be wrong, dnt hold me to that).

I put a support ticket into CCS about it but never heard anything back. Even though I paid the $250 maintenance fee to upgrade my compiler just to support this chip.

What I'm currently doing is using CCS to create the hex file after compile. Then importing that hex into mplabs integrated programming environment app. And using a pickit 3 to program. I am getting programs greater than 640 instruction to program and verify doing this.

[mob1182]

I just used a different programmer, a softlog ICP2, and got the same results. So I don't think this is a programming issue.

[Ttelmah]

OK. I'll see if I can try some programs on your chip and see what is happening. Unfortunately been having problems with my Windows (so with being able to run CCS). Turns out to be with Parallels (which is how I run Windows most of the time, since I use Macintoshes), have had to go back a few versions on this, and have Windows working again OK now, but have lost a lot of time, so it may be a while before I can 'catch up'.

[mob1182]

Problem with windows! Ha never lol. I do appreciate you taking the time in helping me for what its worth.

Just an update, I simplified the code even more. Made the state and data arrays just a int variable. commented out the i2c_isr_state(), all I want is to see if i can get 1 byte of data and continue. Took out "i". "for" loops and stuff. Only thing im sending is the address byte. Again works with get_string array at 65 but not 68.

This is the interesting part. I notice that the SDA line returns to 5V after the address byte is sent. So the slave is sending an ack I assume. If I comment out the i2c_read() and reprogram, the SDA line remains low, so no stop being sent cause its not getting an ACK.

So it appears that the interrupt is firing but the data does not get saved correctly and the i2c_flag value too. Now I don't know assembly language (this is why I use CCS) so it's hard for me to figure out exactly what's going on

Here is the code

[Ttelmah]

The hardware actually releases the clock, when the byte is read.
Now on some chips there has been a problem in the past with this having to be done manually (setting up a CKP bit and setting this at the end of the interrupt handler).
I notice the chip has a really nasty erratum about TBLRD operations. Will have to look and see if CCS are handling this.
What happens if you define the array after the other variables?.

[mob1182]

Wow ok so if I define the array after the other variables it does work.
So this is a chip error then and not the CCS compiler?
And it looks like this only effects rev A2 chips, which is what I have. I wonder if there is anyway to request rev A3 when ordering.
I don't completely know how this will affect the code once I grow it, but hopefully I can work around this now that I know what the issue is, somewhat anyway.
Thanks Ttelmah!

[PCM programmer]