Hello Friends,

Started learning SPI. Trying 8-bit transfer from PIC (Master ) to a microcontroller(Slave).
MCC code generated and flashed on device. Tried to see the Clock(RC3 pin ), data on SDI(RC4 pin) and SDO(RC5 pin) lines using oscilloscope. FOSC is 16MHZ. Clock rate set as FOSC/4. Able to see clock at RC3 pin but frequency is different shown on oscilloscope. Also not seeing data on SDO and SDI lines. I generated correct MCC code.
When I debug using Real ICE, I can see SSPBF while sent is getting A1, and receiving B9 in the below code. Slave is selected.

uint8_t SPI_Exchange8bit(uint8_t data)
{
    // Clear the Write Collision flag, to allow writing
    SSPCON1bits.WCOL = 0;
    SSPBUF = data;  //Send Data A1
    while(SSPSTATbits.BF == SPI_RX_IN_PROGRESS)
    {
    }
    return (SSPBUF);  //Received B9
}
void SPI_Initialize(void)
{
    // Set the SPI module to the options selected in the User Interface  
    // R_nW write_noTX; P stopbit_notdetected; S startbit_notdetected; BF RCinprocess_TXcomplete; SMP Middle; UA dontupdate; CKE Idle to Active; D_nA lastbyte_address;
    SSPSTAT = 0x00;  
    // SSPEN enabled; WCOL no_collision; CKP Idle:Low, Active:High; SSPM0 FOSC/4; SSPOV no_overflow;
    SSPCON1 = 0x20;  
    // SSPADD 0;
    SSPADD = 0x00;
}

PIN INITIALIZATION, OSCILLATOR INITIALIZATION has been done by MCC.

Let me know why data is not traceable on SDO, SDI, lines.

--David.

Moderator edit: added code tags.

 

Which PIC are you using as master?

 

PIC16LF1939.

 

Try to blink an led on those kind first. You may be surprised.

 

Dannyf ...I don't have the scope to blink LED on those lines as its manufactured board. Could you please tell what surprise could be? I feel MCC code must work as it is bcoz it takes care of everything. Its PIC16LF1939. Help.

--David.

 

What frequency clock did you expect and what did you see on the 'scope.

For no signal on SDO you need to check the TRISC register. From the datasheet:
For the pins to behave as the serial port function, some must have their data direction bits (in the
TRIS register) appropriately programmed as follows:
• SDI must have corresponding TRIS bit set
• SDO must have corresponding TRIS bit cleared
• SCK (Master mode) must have corresponding
TRIS bit cleared
• SCK (Slave mode) must have corresponding
TRIS bit set
• SS must have corresponding TRIS bit set
Any serial port function that is not desired may be
overridden by programming the corresponding data
direction (TRIS) register to the opposite value.

 

I feel MCC code must work as it is bcoz it takes care of everything. Its PIC16LF1939.

Your experience so far should tell you that that is not necessarily the case.

 

A few things come to mind:
1) What MCU is being used as the slave? Are the devices set to the same SPI mode? What mode do you intend to be using? PIC's are a little different from many other devices in how mode is defined (i.e., CKE vs. CPHA).
2) Fosc/4 gives a clock of 4 MHz. Will your slave device handle that?
3) Is the slave awake? That should not be a problem if you also wrote the software for the slave, but for commercial devices it can cause confusion.
4) Is SDI wired to SDO and visa versa, respectively, for master and slave?

John

 

Albert,

Find my comments:
FOSC is 16MHZ. SCK set as FOSC/4. I must get 4 MHZ bt getting 500 KHZ.

SDI must have corresponding TRIS bit set ----- Its Done
• SDO must have corresponding TRIS bit cleared --- ----- Its Done
• SCK (Master mode) must have corresponding TRIS bit cleared ----- Its Done
• SCK (Slave mode) must have corresponding TRIS bit set ----- Its Done
• SS must have corresponding TRIS bit set ------ I think, this is Chip select. Its Active low and as output pin for PIC so TRIS set as 0. Then before data transfer starts, I do CS=0 (LATAbits.LATA0 = 0) after transfer CS=1 (LATAbits.LATA0 = 1)

Any serial port function that is not desired may be overridden by programming the corresponding data direction (TRIS) register to the opposite value.
Do I need to clear RCSTAbits.SPEN = 0? I feel not required as SDO, SDI pins are not Tx and Rx. Any other reason ?

--David

 

jpanhalt,

My comments:

A few things come to mind:
1) What MCU is being used as the slave? Are the devices set to the same SPI mode? What mode do you intend to be using? PIC's are a little different from many other devices in how mode is defined (i.e., CKE vs. CPHA).
------ Its a freescale MCU as Slave.
2) Fosc/4 gives a clock of 4 MHz. Will your slave device handle that?
----- Slave works at less than 10MHZ.

I was expecting at least SCK and SDO lines from PIC must show data. Any idea?

--David

 

FOSC is 16MHZ. SCK set as FOSC/4. I must get 4 MHZ bt getting 500 KHZ.

Your SSPCON1 is set correctly for Fosc/4 and the 500kHz SCK suggests your actual processor clock is 2MHz. Are you (supposed to be) using an external crystal or the internal clock generator?

 

What mode is the Freescale device expecting? Are you sure it is awake?

As SPI is always an exchange of bits I would not trust the absence of a bit stream on SDO (MOSI) as indicative of the Master transmitting; although, to be clear, I have never tested it.

John

 

Albert,

In Oscillator_Initialization, I have given OSCCON = 0x78, which is 16MHZ.

--David.

 

jpanhalt,

Will get back to you on slave mode.

--david.

 

One more question, In debugging using PICKit3 if sent SSPBUF shows A1 value and received SSPBUF is B9. Does it not indicate that transmission and reception is happening between master and slave?

--david.

 

I would assume that is the case, if doing hardware simulation (i.e., simulation that doesn't use a "stimulus" ).

Back to your #1 post, why do you think the SPI is not working?

John

 

As SDO, SDI lines don't show any data on oscilloscope and SCK frequency value is different on oscilloscope, It seems its not working.
I observed also if chip select is unselected at that time also SSPBUF shows same values which must not happen.

--David.

 

What mode is the Freescale device expecting? Are you sure it is awake?

As SPI is always an exchange of bits I would not trust the absence of a bit stream on SDO (MOSI) as indicative of the Master transmitting; although, to be clear, I have never tested it.

John

Regardless of the slave, the master should still transmit. Once that is happening then there are whole load of other things to get right before getting a sensible reply from the slave.

 

When I troubleshoot a new SPI link, I try to read a known register in the slave, such as the device ID. Usually the R/W bit is <7>, so the address you sent would translate into a read of register 0x21 (if those assumptions hold). The response from the slave can usually be ignored when sending the address. What is in register 0x21 of the slave? I then send a meaningless byte or just clear SSPBUF, which sends zeros. The next byte from the slave is the contents of the register address I sent in the first byte -- in your case register 0x21.

Did you try something like that?

John

Edit: I am assuming 4-wire SPI. Is that correct?

 

don't have the scope to blink LED on those lines as its manufactured board. Could you please tell what surprise could be

Blink it slowly to even a multimeter can see the fluctuation.