Broken read_spi during migration from 16F877 to 18F458

[trick420]

Hello everyone.

I'm having trouble with read_spi. I have a working 16F877 talking to a Ti DSP via SPI. The protocol is as follows:

PIC is master. We are using SS, but not as built in. We're toggling another pin external to the SPI interface. All communications are 3 bytes. For a write command, the first byte from the PIC contains the target register address. The second and third Bytes contain the data. For all 3 bytes, the DSP responds simultaneously with a 'don't care' byte, which is 0x55. No problem, works fine on either part.

For a read, the pic first sends a write_spi to the DSP that contains a read address bit and the target address. The DSP simultaneously responds with a 0x55. The pic then performs a read_spi(0) twice, and generates the appropriate clocks. During this time, the DSP sends back the requested two data bytes.

Simple enough. The 16F877 works flawlessly. The 18F458 doesn't work. In scoping the Rx, Tx, and CLK lines, the two systems are identical - the correct data is shown on the scope. If I step through the code and watch the SSPBUF register, the first byte on the read routine, which is a 0x55 that is generated from the write_spi appears in the register. The next byte that comes in with the read_spi does not appear in the register, and after calling read_spi, the variable gets assigned the first byte (0x55). The second call to read_spi gets the first read_spi byte.

Attached is the code:

Setup parameters from main();

setup_spi( SPI_MASTER|SPI_H_TO_L|SPI_CLK_DIV_4 );
#asm
/* For 18F458 Only */
bcf SSPCON1,4
bcf SSPSTAT,7
bcf SSPSTAT,6

/* For 16F877 Only */
//bcf 0x14,4
//bcf 0x94,7
//bcf 0x94,6
#endasm

The read fuction used:

void ReadSPI()
{

output_low( PIN_C1 ); //on 16F, 0x55 gets ignored
spi_write( SByte1 );
output_high( PIN_C1 );

output_low( PIN_C1 );
S_in_1 = spi_read( 0 ); //on 16F, data byte 1 gets assigned to S_in_1. on 18F 0x55 from the write gets assigned to S_in_1
output_high( PIN_C1 );

output_low( PIN_C1 );
S_in_2 = spi_read( 0 ); //on 16F, data byte 2 gets assigned to S_in_2. On 18F data that should have been assigned to S_in_1 gets assigned to S_in_2.
output_high( PIN_C1 );

} /* end ReadSPI() */

Now, simply generating another read would get the last data byte, but the protocol says that each communication is 3 bytes, so generating a clock again actually sets the DSP to a read register 0, and thus puts the two processors out of sync.

I'm also using PCWH version 3.218

I'm at a loss on this. I'm convinced at this point that I'm dealing with a compiler bug. Any suggestions?

Thanks,
Jeff

[PCM programmer]

1. If you're convinced it's a compiler bug, download vs. 3.191 and try it.
It may be different.

2. If it's a compiler bug, there's not all that much code in the CCS
spi_read() function. I looked at the .LST file, and there's only
five lines of ASM code in it. There's not that much to go wrong.

3. The fact that you have little blocks of #asm code in there, is
a little disturbing. It seems to me that if you're going to
adjust bits here and there in the SPI setup, then you ought to
write your own complete routine. Ideally it should be written
with C code which accesses registers declared with #byte statements.

4. There is a wacky SPI Buffer Full bug listed in the errata.
I stepped through the code in the simulator and I didn't see it.
It involves the BSR. I stepped through the code in the simulator
with PCH vs. 3.188 and the BSR was always at 0. So that bug
shouldn't apply. It's probably the same in your version, but check it.

5. I would look at it on the scope first, and make sure that the edge
relationships are exactly the same between the two PICs.

6. Also look at the amount of setup and hold time between the chip
select edges and the data and clock. I wonder if you're running
the 18F458 with a higher frequency crystal than the 16F877 ?

7. Also, the 18F458 generates tighter ASM code than the 16F877.
It doesn't have all those bank selects and GOTO statements in it.
If you're running at 4 MHz, each instruction takes 1 or 2 usec, and
that might be significant. Does the DSP have a hardware SPI ?
If so, look at the timing requirements in the data sheet.
I think we might be dealing with a subtle timing bug, unless using
vs. 3.191 fixes it.

[trick420]

[PCM programmer]

[PCM programmer]

Here's some additional information.
Download the errata document for the ICE 2000:
http://ww1.microchip.com/downloads/en/DeviceDoc/80078b.pdf

It says that in i2c Master mode, any opcode of the format xxC9
will clear the SSPSTAT buffer bit. Isn't that sort of what you're seeing ?

This errata is for i2c Master mode, but some of the hardware
for that mode is also used in the SPI mode, and it wouldn't
surprise me if it affected SPI as well.

What do we see in the spi_read(0) function ?
We see tons and tons of opcodes with xxC9 in them.

[trick420]