PIC18F25K22 SPI interfacing program

If someone is knowing PIC18 spi programming, please do help me.
if(SSP1STATbits.BF ==1 ) is never met, i tried

KlausST said:

Guessing?
In my eyes the picture of a scope says more about the real world conditions than a simulation.

Click to expand...

There is difference between simulatio, debuging and scope.
Of course on the scope you have real word, but it is confluence of events. Your role is to analyse and check every step, and correct wrong one.
This example is very didactic. There is byte of SPI data received and there is no LED reaction.
lets start GUESSing.

1. There is no power on the board...
2. There are wrong solder,
3. There are .......
.......
4124. SPI has wrong config
......
12321. LED is reverse biased.
and more, more.

There is no response of slave so there is real word guess case. We do know NOTHING

The PIC advantage is that there is possibility to debug code. Lets set breakpoint on line of read SSP1BUF code and we are able to find what to do, even without analyse code. I mean in such situation we are able to decide if we should analyse code, or PCB or so.

BTW
the slave code is very strange:

that mean
if we receive data

PORTB = SSP1BUF; do something, but rather nothing - write to PORT or LATCH??

SSP1BUF=0; send 0 via SPI it mean wait for next clock to send

Hi,

correct me if I´m wrong:

LATBbits.LATB5 = 1; //led------- this led never gets on
--> LATB writes one pin of port B

PORTB = SSP1BUF;
--> and in this folowing command the value of LATB5 is overwritten.

Klaus

its no problem. reading of SSP1BUF clear BF flag.

From my point of view eveything should work - at least first time SPI should receive char. I would prefer to check hardware.
If you are not able to debug chip try to set like this:

if(SSP1STATbits.BF)
{
LATBbits.LATB5 = 1; //led on
while(1); //infinite loop
}

it means to be sure if there is nothing to disable LED, put it in infinite loop after receive.

- - - Updated - - -

KlausST said:

PORTB = SSP1BUF;
--> and in this folowing command the value of LATB5 is overwritten.
Klaus

Click to expand...

In fact this command do nothing except clear BF

- - - Updated - - -

I am wondering how about SSP1OV. If there is no problem?
Try to run slave without master, and then connect master, if it change anything?

- - - Updated - - -

And another idea - you have enabled GIE without any int handling. Check rest of your code if there is any int enabled and chp coues to infinite int??
Try to disable GIE

Hi,

In fact this command do nothing except clear BF

Click to expand...

I have to believe this...

***
Check the mcu pin for the LED (PB5?) with a scope. No activity? Not even for a microsecond?
--> Then the BF flag is never set.

Then we should test if the main loop is running.
Try to toggle another port pin in main loop.
Check with a scope. if there is activity.

If there is activity, then I assume there is something wrong with the SPI setup.

If there is no activity then I asssume there slave mcu is not running at all. Power supply, clock, reset...

Klaus

sir i tried by disabling global interrupt and using

but LATBbits.LATB5 = 1; // doesn't get on
SSP1STATbits.BF is not satisfied.

is there anything wrong in the configuration?
SSP1STAT =0x40; //In SPI Master or Slave mode:
1 = Transmit occurs on transition from active to Idle clock state
SSP1CON1=0x24; //In SPI mode:
1 = Enables serial port and configures SCKx, SDOx, SDIx and SSx as the source of the serial port pins and
0100 = SPI Slave mode, clock = SCKx pin, SSx pin control enabled

Hi,

I just reviewed the voltages on the scope picture of post#19.

--> CH1 and CH4 Y axis setup seems to be wrong. Please correct it.
Please post a new picture... or at least give us the correct HIGH and LOW values of both channels.

***

CH2 and CH3 are correct as long as you are working on a 5V system.

Klaus

KlausST said:

I just reviewed the voltages on the scope picture of post#19.
Klaus

Click to expand...

sir the chn-1 signal i.e. clk is of 5 V, it is showing incorrect value due to probe issue. ch4 is of 1.5 volt ie. ss bar (select line). i'm having 1 slave.

Config looks OK.
to initialise I would add SSP1CON3 = 0x00; but it is default state.

Maybe try to add

char dummyRead

dummyRead = SSP1BUF;
SSP1CON1bits.SSPOV = 0;
SSP1CON1bits.WCOL = 0;

just before main while loop

- - - Updated - - -

If all this fails I see two ways:
Start use debug function of PIC, stop program after a few seconds and read SPI registers, TRIS, LATCH and PORT states.
The other way is to use LEDs as debug functions. I would search for solder problems. for instance SS pin (don't forget enable pin initialisation, and do not enable SPI)

while(1)
{
LATBbits.LATB5 = PORTAbits.RA5;
Nop(); //some delay - important!!
}

Hi,

ch4 is of 1.5 volt ie. ss bar (select line). i'm having 1 slave.

Click to expand...

But it should be 5V also.

1.5V is no valid voltage level. It is somewhere inbetween low (<0.7V) and high (>2V for TTL, or >0.7 x VCC for CMOS)
--> This may be the case, why the slave is not properly selected.

Therefore I assume both connected devices are set to be "outputs" then they fight against each other. Check on this. Usually then one or both IC become warm.
.. or both are set to be "inputs". Floating.

In either case you have to ensure valid logic levels.

Klaus

KlausST said:

Hi,


But it should be 5V also.

1.5V is no valid voltage level. It is somewhere inbetween low (<0.7V) and high (>2V for TTL, or >0.7 x VCC for CMOS)
--> This may be the case, why the slave is not properly selected.

Therefore I assume both connected devices are set to be "outputs" then they fight against each other. Check on this. Usually then one or both IC become warm.
.. or both are set to be "inputs". Floating.

Click to expand...

KlausST good piont.

unfortunatelly lack of high state on select pin with PIC makes only out of sync problem. SS works as SPI reset. So it is not reason of absence of BF.

In the code there is:
master
TRISCbits.RC2 =0; //SS
and
LATCbits.LATC2 = 0; // ss bar
....
LATCbits.LATC2 = 1; // ss bar

what from the program side os OK

slave side:

TRISAbits.RA5 = 1; // SS i/p

so there is no software conflict, but there should be hardware problem

can i use usart to receive data in slave controller from master ?

In my oppinion as KlausST found it looks like you have hardware problem - mixed pins - your SS master pin C2 is not connected to SS slave pin A5 (or not only). All your pins except SPI and LED pins are low, and from the scope it looks like there was SS master output connected to pulled low pin.
If it is true (and it could be only one of reasons) change to UART won't solve problems. maybe one wire, but first you have to check if it is properly connected