SPI problems with PIC 18F2525

[maozohad]

I’m having problems working with the SPI module of the PIC18F2525 rev a4.
After exchanging some e-mails with CCS and Microchip , where I couldn’t get any final solution to my problem, only that
a) CCS claimed that if the code worked on the PIC18F252 , than it should work on the PIC18F2525, and there is no problem on their side
b) Microchip claimed that it might be a h/w bug but they can’t tell that for sure.

Here is a description of my problem

I’ve migrated a working code and environment from PIC18F252 to PIC18F2525.
I’m using PIC18F2525 revision A4 and PIC28F252 revision C0.
MPLAB IDE version V7.31
CCS compiler V3.249
SPI clk is 1 MHz, PIC frequency is 16 MHZ
Same code with the same environment works perfect with PIC18F252.

I’m getting a strange problem using the SPI, Where the PIC is used as a slave and a TI DSP is used as a master.
I’m working in the following scenario


*Master sends data - Slave sends dummy data
*Master sends dummy data - Slave sends data
The clock idle state is low '0'
Both master and slave change the data pin while clock change its state from low (idle) to high (active), so the other device samples the data when clk change its state from high to low - I've verified this using a scope.
What is very odd, is that when using the correct mode which is being used with the PIC252
SSPCON = 0x05;
SSPSTAT=0x00;
TRISC=0x98;
//TRISA = alllready cinfiguredl SS' is not used
SSPCON=0x25;
I’m not using the SS’, only SCK,SDI,SDO

The data is being sent/transmit via the #int_ssp ISR , and timer2 is used as a watch dog for the communication. , above setting achived by
setup_spi(SPI_SLAVE|SPI_L_TO_H|SPI_CLK_DIV_4|SPI_SS_DISABLED(;

Using the setting above data is received in most of the cases (but not in all of them) correctly at the master side (TI DSP), and while the master transmits the data correctly (verified that using a scope) , data is not received at all / or received with error at the slave side

When I'm doing something which is totally wrong, and that is configuring the port with
SSPSTAT.bit6 (CKE) to be 1 - which is wrong , and moreover configuring SSPSTAT.bit7 (SMP) to be 1 - which is wrong - "SMP must be cleared when SPI is used is Slave mode" section 17.3.1 in the data sheet
In this configuration - Data is received correctly at the slave side, and the slave sends garbage to the master. This setting achived by setup_spi(SPI_SLAVE|SPI_H_TO_L|SPI_CLK_DIV_4 | SPI_SAMPLE_AT_END | SPI_SS_DISABLED);
The response I got from microchip was
a) This may be a h/w bug and I should wait for rev B to come out
b) It could be a problem with the design and the TI DSP which did not show up for some reason with the PIC18F252 but has with the PIC18F2525. It is more likely though that it is something to do with the PIC18F2525 I think.

Any suggestions ?

[Ttelmah]

Seriously, there are a hell of a lot of faults in the SSP module on the 18F2525. If I remember correctly, something over 20 errata for this component!...
There are some that might apply. One in particular, is that the actual SDO line, can change state, at a point in the timing, that it is not meant to do!. This might explain why fiddling with the clock timings partially fixes the problem. As a seperate comment, are you sure that the DSP leaves enough time between clocking the first byte, and clocking to get the 'reply'?. The latter chips have extra registers that are saved in the interrupt handler, and the latency will therefore be slightly worse at a given clock rate.
I must admit, I have 'steered away' from the 2525, pending a version that has rather less visible faults in this area...

Best Wishes