View previous topic :: View next topic |
Author |
Message |
lglenat
Joined: 08 May 2011 Posts: 8
|
Byte error rate 10% with SPI |
Posted: Sun May 08, 2011 12:35 pm |
|
|
Hi !
I'm trying to use SPI communication between a master and a slave, both PIC18F2523.
I think I'm doing that right, but when I compare the byte returned by the slave after a request of the master (using SPI twice), I get 5 to 15% of wrong bytes, depending on the different delays I chose between the different spi_read, spi_write calls, and other parameters (see after the code).
Here is my code :
MASTER
Code: |
#include <18F2523.h>
#FUSES INTRC_IO, NOWDT, NOPROTECT, NOLVP
#use delay(clock=8M)
#byte SSPBUF = 0xFC9
#define SSBAL PIN_A3
long a=0,b=0,i=0;
void main()
{
enable_interrupts(GLOBAL);
//setup_timer_2(T2_DIV_BY_16,3,1);
// Initialize the hardware SSP for SPI Master mode.
//setup_spi(SPI_MASTER | SPI_L_TO_H | SPI_XMIT_L_TO_H | SPI_CLK_T2);
setup_spi(SPI_MASTER | SPI_L_TO_H | SPI_XMIT_L_TO_H | SPI_CLK_DIV_16);
output_high(SSBAL); // Initial Slave Select to a high level
while(1)
{
delay_us(100);
a++;
output_low(SSBAL);
delay_us(50);
spi_write(0b10101010); // Send command to slave
output_high(SSBAL);
delay_us(10); // Give slave some time to respond
output_low(SSBAL);
delay_us(50);
result = spi_read(0);// Read response from slave
output_high(SSBAL);
if (result==0b11001100)
{
b++;
}
else
{
i++;
}
}
}
|
SLAVE
Code: |
#include <18F2523.h>
#FUSES INTRC_IO, NOWDT, NOPROTECT, NOLVP
#use delay(clock=8M)
#byte SSPBUF = 0xFC9
long a=0,b=0,c=0;
int8 command;
#int_ssp
void ssp_isr(void)
{
disable_interrupts(INT_SSP);
a++;
command = SSPBUF;
if (command==0b10101010)
{
b++;
SSPBUF = 0b11001100;
}
else
{
c++;
SSPBUF=0;
}
enable_interrupts(INT_SSP);
clear_interrupt(INT_SSP);
}
//======================================
void main()
{
// Initialize the hardware SSP for SPI Slave mode 0.
setup_spi(SPI_SLAVE | SPI_L_TO_H | SPI_XMIT_L_TO_H);
// Enable interrupts for the SPI slave.co
enable_interrupts(GLOBAL);
clear_interrupt(INT_SSP);
enable_interrupts(INT_SSP);
while(1)
{
}
}
|
Maybe you can give me your opinion on the followings things, because I don't what can be the source of my problem :
- I'm using the internal oscillator (8M).
- If I use SPI_CLK_T2 as parameter in setup_spi, I get worse results than using SPI_CLK_DIV_16 (or 64), and the error rate depends also on the parameters of the timer2.
- if I don't add delay_us(50) after putting low the SS pin, the result is worse.
- the master seems to receive the byte 0 when it receives a wrong byte, and only 0, as he could not communicate with the slave. Maybe there is a problem of timing...
Thank you for your help !
Lucas (I'm french) |
|
|
temtronic
Joined: 01 Jul 2010 Posts: 9229 Location: Greensville,Ontario
|
|
Posted: Sun May 08, 2011 2:39 pm |
|
|
Two issues..
1) master enables global interrupts but no ISRs are defined. Bad practice to enable without ANY ISRs....
2) internal oscillator is NOT a crystal, so check the datasheet for accuracy vs. operating voltage. Also the master could be say 8.001 and the slave 7.998 Mhz, within spec(?) but too far off for reliable interPIC communications. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Sun May 08, 2011 4:14 pm |
|
|
Are these two PICs on separate boards ? Or are they on the same board ?
Is this a real hardware project, or is it a Proteus project ?
Post a list of connections between the two PICs for the SPI.
What is your compiler version ? |
|
|
lglenat
Joined: 08 May 2011 Posts: 8
|
|
Posted: Mon May 09, 2011 11:02 am |
|
|
Ok I will try with a crystal as soon as possible...
@PCM programmer :
- The two PICs are not on a PCB but on a prototyping board (white, with components linked with wires)
- The PICs are connected as below :
MASTER SLAVE
SDI SDO
SDO SDI
SCK SCK
RA3 SS (RA5)
- My compiler version is 4.093
I hope it will help, thank you both for your quick answers. |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Mon May 09, 2011 11:44 am |
|
|
temtronic wrote: | Two issues..
1) master enables global interrupts but no ISRs are defined. Bad practice to enable without ANY ISRs....
2) internal oscillator is NOT a crystal, so check the datasheet for accuracy vs. operating voltage. Also the master could be say 8.001 and the slave 7.998 Mhz, within spec(?) but too far off for reliable interPIC communications. |
That shouldn't matter here since SPI is clocked.
-Ben _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Mon May 09, 2011 11:54 am |
|
|
Are the two PICs on one (solderless) board, or are they on two boards ?
In other words, do you have a common ground connection between the two PICs ?
What is the power supply voltage for the PICs ? Is this a good, clean,
stable power supply voltage ? |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon May 09, 2011 2:19 pm |
|
|
Try running the SPI at 1/10 speed and see if that makes a difference. Can you tell if the bad bits are always 1 or if they are always 0? The best thing is to put a dual trace oscilloscope on the lines. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
lglenat
Joined: 08 May 2011 Posts: 8
|
|
Posted: Mon May 09, 2011 3:34 pm |
|
|
@ PCM programmer
The PICs are on the same board, with same ground, same power supply.
The power supply voltage is 5V from a 1.5A DC regulated power supply, that is good power supply I think. I tried with a voltage regulator and with filtering capacitors (100u and 100n between gnd and vcc) but it didn't change anything.
@SherpaDoug : bad bits seem to be always 0, error is always 0 instead of 1.
I will try with an oscilloscope. |
|
|
SherpaDoug
Joined: 07 Sep 2003 Posts: 1640 Location: Cape Cod Mass USA
|
|
Posted: Mon May 09, 2011 6:48 pm |
|
|
lglenat wrote: |
@SherpaDoug : bad bits seem to be always 0, error is always 0 instead of 1.
|
From that info I would guess your SPI pull-up resistors are too high, or you have too much capacitance on your lines. If the 1/10 speed cures the problem then it is resistance/capacitance. If 1/10 speed does nothing then you have a pure voltage problem, like differing PIC voltage levels or leakage currents. Your scope should help find the problem. _________________ The search for better is endless. Instead simply find very good and get the job done. |
|
|
lglenat
Joined: 08 May 2011 Posts: 8
|
|
Posted: Tue May 10, 2011 12:28 pm |
|
|
Quote: | From that info I would guess your SPI pull-up resistors are too high |
I didn't kwow that spi required pull-up resistors. On what lines do you suggest I have to put pull-up resistors ? |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Tue May 10, 2011 1:09 pm |
|
|
No, SPI doesn't need pull-up resistors as a requirement.
I haven't looked closely at your test program, and I haven't bread-
boarded it for a hardware test. But I suggest that you try two
different PICs from a different PIC family. The PICs that you are
using do have some erratas on the SPI. They might seem not to
apply in your case, but I think it's a good test to try it with different PICs. |
|
|
lglenat
Joined: 08 May 2011 Posts: 8
|
|
Posted: Wed May 11, 2011 12:46 pm |
|
|
- I just tried with two PIC18F2520 and I got the same problem.
- I change the board to eliminate this parameter.
- I tried to use a 20MHz crystal, pull-up resistors, changed nothing.
- When I debug the slave sometimes it's working (all the bytes received by the slave are those sent by the master), but i don't know why...
- Maybe there is a soft issue, or as Sherpadoug said a voltage issue.
PS : I haven't tried yet with a scope. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Wed May 11, 2011 12:57 pm |
|
|
Or it could be a test program issue. I didn't really look too closely at your
test program. I don't have time to put together a hardware test setup
today. Maybe I could do that tomorrow and test the problem. |
|
|
lglenat
Joined: 08 May 2011 Posts: 8
|
|
Posted: Wed May 11, 2011 2:16 pm |
|
|
PCM programmer wrote: | Or it could be a test program issue. I didn't really look too closely at your
test program. I don't have time to put together a hardware test setup
today. Maybe I could do that tomorrow and test the problem. |
It would be great !
Thank you anyway. |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu May 12, 2011 6:14 pm |
|
|
I made a test that worked for the 16F877, but I haven't been able to make
it work for 18F PICs yet. There's something different with the compiler
or the MSSP modules in those PICs. I don't what it is yet. I'll investigate
it more tomorrow. |
|
|
|