SPI slave trouble, port 2 18F8722

lifespeed · Joined: 17 Aug 2005 Posts: 19

I'm having trouble reading in valid data on the second SPI port of the PIC18F8722. Compiler is ver 3.234.

SPI port 1 is currently used to write to 5 other ICs, one of which can also be successfully read using 3-wire SPI with the PIC providing the clock. So, it does seem SPI works . . .

However, this product needs to behave as an SPI slave to the outside world. So, I attempted to configure the SPI port 2 as slave, with the external clock (about 30 KHz in this case) latching the data on the rising edge. I am failing miserably, I cannot even seem to get the spi_data_is_in2() to go true when the three bytes are clocked in while SS2 (D7) is held low by the external master. I have checked the waveforms at the ICE2000 emulator, and they are correct even tho slightly rounded by RC time constants.

A bit-banging routine was written using D5,6 and 7 which successfully imports the data, but I would really prefer to use hardware SPI as this provides a better assurance that data will be received even if the PIC is off doing something else when it starts clocking in.

Will the PIC clock data out on port 2 in 2-wire mode while receiving input, fighting the input data, or will it output the data on SDO2 (RD4) in 3-wire mode causing no trouble with the SDA2 (RD5) input data?

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

What's your PCH compiler version ?

lifespeed · Joined: 17 Aug 2005 Posts: 19

Compiler is 3.234, pretty new.
_________________
Lifespeed

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

The problem is with your parameters for SPI slave mode.
Some of those parameters are only intended for Master mode.
CCS doesn't do any checking. So what's happening is that
you're putting the MSSP into i2c slave mode by accident.

The following code will put it into SPI slave mode, with the
\SS pin enabled.

lifespeed · Joined: 17 Aug 2005 Posts: 19

Thanks! I would have never guessed, and I sure didn't see that in the CCS manual. I would much prefer hardware SPI to bit-banging.

Very Happy

_________________
Lifespeed

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

I saw the problem by looking at the .LST file and the SPI section
of the data sheet.

lifespeed · Joined: 17 Aug 2005 Posts: 19

I'm glad you explained how you came to that conclusion. That technique might help me solve problems in the future.

Thanks again,
_________________
Lifespeed

lifespeed · Joined: 17 Aug 2005 Posts: 19

I am still having trouble getting valid data in using SPI2 slave mode. As best I can tell, it tends to skip the first bit of a 3-byte series, and zero the last bit. The last data bit of the series does not remain high until 50% past the 33 KHz clock, leading me to believe that data latching is not really happening halfway thru the active clock, as stated. Based on the bit patterns, it looks as though the data are latched in between the active clocks ??? Please help! The product is useless without comms to the outside world Sad

Attached is the code, MSSP register states, a scope screenshot, and several bit patterns sent and read. I have tried SPI_H_TO_L, although the data is being sent on a rising-edge clock.

I should note I am using an ICE2000 emulator running at 25 MHz with HS external clock. Also, I'm sending MSB first, although if the bit order were reversed I would think I could easily see it?

I also noticed using spi_read2() with an argument such as
spi_read2(0x55) causes only one byte instead of three to be read in, then another 3-byte send reads in the remaining two bytes:

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

lifespeed · Joined: 17 Aug 2005 Posts: 19

I am using the PCM18SX0 processor module. So far I am unable to find an errata sheet for it, although I hope it does not have the bug described for the PCM18AX0/BX0.

I have been looking at the clock and data (supplied by a National Instruments digital I/O card, the picture is in a previous post) as well as the timing diagrams on p. 210-211 of the PIC18F8722 datasheet. I am using CKP=0, CMP=0. It looks like the transition edge of the data is very near the 50% point between leading edges of the clock. The clock is not 50% duty cycle, which shouldn't matter, but then the falling edge of the clock is *not* where the data is latched in.

Also, the first bit seems to often get screwed up. Is this because the 50% point between clock edges is unknown without the second clock?
_________________
Lifespeed

Guest · Posted: Sat Oct 15, 2005 5:47 pm

OK, here's the scoop. Despite the info on page 210 of the PIC datasheet indicating only two of the four clock timing modes are available, all 4 modes are really available. Not thru the compiler, CCS only supports two modes. A direct write to the registers SSP2STAT and SSP2CON1 to set CKE=0 and CKP=1 accomplished a valid read on the rising edge of the clock. Confused

Ttelmah · Guest

You do presumably realise that there is nothing 'special' about the defines used by CCS, and that you can perfectly well create your own?. The top byte is what goes to the SSPSTAT register, and the low byte is what goes to SSPCON1. In fact CKE=0, CKP=1, is available from the CCS defines, as just SPI_H_TO_L. SPI_X_TO_X, control the bit fed to CKP, and the 'SPI_XMIT_L_TO_H' value controls the bit for CKE. Nowhere in the data sheet that I can see, does it indicate that only two of the clock modes are available....

Best Wishes

lifespeed · Joined: 17 Aug 2005 Posts: 19

PCM programmer · Joined: 06 Sep 2003 Posts: 21708

Actually, if you look at Figures 19-5 and 19-6, they show the four
SPI clock modes for the slave. This is on page 214 with the Acrobat
reader.

In other words, instead of showing all four modes in one timing
diagram as they do with the Master, for the Slave they split it
into two diagrams.