I2C PIC Slave at 8MHz and PIC Master at 48MHz

[bwhiten]

I am using two PICs in a Master/Slave pair. The clock differences are as listed in the title. The writes from master to slave work well as long as the slave is fully running before the master is released from reset. If not, the slave catches the first state == 1 of the i2c_isr_state (address) but never sees state == 2 (data). I am using the samples from EX_SLAVE and EX_EXTEE for code so I won't post those now. Any idea if the large clock differences could be playing a part? Is there any simple way to resynch these two or clear the slave to get back on track?

[PCM programmer]

Here's something to try. Have the master call the get_ack_status()
routine in the following post. Give it the i2c write address of the slave
as the parameter. Wait until you get an 'ack' back from the slave before
you proceed with your normal i2c code.
http://www.ccsinfo.com/forum/viewtopic.php?t=32753&start=11

[bwhiten]

Thanks. I'll try that tonight.

[bwhiten]

No success. The master continues to write, slave_address, data_address and data, but the slave never sees state == 2 for the data value. I put a long delay at the beginning of the master boot up to ensure the slave is always ready and that solves the problem, ugly for now. Seems like an out of synch issue I should be able to clear on the slave side.

[ckielstra]

I remember a thread a few months ago where they had a lot of problems with the I2C clock at higher speeds.

Please post:
- The I2C clock speed you are using.
- The type number of your sending and receiving PICs, including the silicon revision number.

[bwhiten]

Slave PIC is 16F887-E
Master PIC is 18F4550-I or "1" can't tell with my old eyes

I have them both set for SLOW in there #use i2c statements.

[ckielstra]

The silicon revision level is a code not printed on the chip package. Some programmers or an In-circuit debugger like the ICD2 show you the silicon revision code when connecting (looks like A3 or B5 or ...).

It seems like the 16F887 is still at it's first revision because I can only find one errata document: http://ww1.microchip.com/downloads/en/DeviceDoc/80302D.pdf.
There is a bug when using this chip as an I2C slave which I don't think is handled by the compiler. Please check Issue 5 of the above document.

For the PIC18F4550 the A3 revision has many issues, some affecting an I2C master. The newer B4, B5 and B6 steppings look ok.

What is your compiler version number?
In the v4 compilers you can specify the exact I2C speed. It would be worth a shot to try a slower frequency and / or check the clock signal with a scope.

[bwhiten]

I suppose I can't see the silicon rev with the ICD-U40?
I'm using 4.068 but don't have a scope at home to check the waveform.
I'll look at the errata on the 16F887 and the work around.
I don't seem to find what the SLOW setting for I2C relates to unless it is the 100KHz standard.
I'll also try setting a slower I2C bus speed.

[ckielstra]

[PCM programmer]

This post has code read the Device ID and silicon revision:
http://www.ccsinfo.com/forum/viewtopic.php?t=20257

[bwhiten]

Thanks for the code:

18F4550 Device ID: 1202

16F887 Device ID: 2082

I'll have to interpret these tomorrow.

[bwhiten]

From the Device ID registers it appears both of these are silicon revision 2. I need to see if this makes any sense with the errata listings.

[KD5UZZ_]

In one of your posts you say that you have them both set to 'slow'. I thought you only 'set' the master's I2C speed, and the other follows it.

[bwhiten]

I didn't find any issue in the manual nor did I get any type of error or warning during compile so I left it there for now. I had listed it origionally hoping some compatibility problem was causing the lock-up.

[ckielstra]