1. Home
  2. Embedded Programming
  3. SPI problem

SPI problem

Hi all, We are stuck here with the spi problem. We have with us two AT89C51ED2 boards. We trying some small experimentation on the SPI before we start our actual work. The board have a 40MHz crystal.

We want to use one board as MASTER and other as the SLAVE. Problem is when we transmit something from the MASTER we are not able to read the same value from the slave ISR. I have put below the excerpt of both the master and slave code. could anyone shed some light please.....? Connections done are as follows....

MOSI of master to MOSI of Slave MISO of master to MISO of Slave SCLK of master to SCLK of slave SS of master to VCC SS of slave to P1_0

Please note that we make the P1_0 low when we write something to the SPDAT and Make it high again when the SPIF in the Master is set ie after transmission is done.

The master init is as follows SPCON |= 0x10; /* Master mode */ SPCON |= 0x20; /* set SSDIS bit */ SPCON |= 0x01; /* Fclck / 4 */ IEN1 |= 0x04; /* enable spi interrupt */ SPCON |= 0x40; /* run spi */ P1 |= 0x01; /* Deselect the slave first */ EA=1; transmit_completed = 0; /* clear software transfert flag */

The master isr excerpt void it_SPI(void) interrupt 9 /* interrupt address is 0x004B */ { switch ( SPSTA ) /* read and clear spi status register */ { case 0x80: serial_data=SPDAT; /* read receive data */ transmit_completed=1;/* set software flag */ break; } }

The Slave init is as follows SPCON &= ~0x10; /* slave mode */ IEN1 |= 0x04; /* enable spi interrupt */ SPCON |= 0x40; /* spi run */ transmit_completed = 0; /* clear software transfert flag */ EA=1; /* enable interrupts */

The slave ISR excerpt

void it_SPI(void) interrupt 9 /* interrupt address is 0x004B */ { switch ( SPSTA ) /* read and clear spi status register */ { case 0x80: serial_data=SPDAT; /* read receive data */ transmit_completed=1;/* set software flag */ break; } }

Thanks and regards pachu

Reply to
pachu
Loading thread data ...

SPCON |= 0x01; /* Fclck / 4 */

If I understand correctly your settings indicate an SCLK speed of 10MHz. We have used other micros with SPI ports and found them to be rather sensitive to system noise and lead lengths. I built an SPI sniffer to help diagnose problems and found that I needed to use very short lead lengths, and even then it worked better if I used small pieces of twisted pairs with one wire grounded.

If for testing you are connecting two boards together you should be very careful with the connections from board to board. I would avoid flat cable and use twisted pair or sheilded wiring if possible.

Scott

Reply to
Not Really Me

I'm not familiar with SPI operations on the ATmel chips, but on Motorola chips, you must disable the SPI port before you change the control registers. Is there any similar requirement on the Atmel SPI port that could be preventing it from accepting some of your command bits?

Do you need to clear a receive-complete flag also, or is that done automatically when you read SPDAT?

Mark Borgerson

Reply to
Mark Borgerson

Do you have a common signal/DC ground running between the boards? If they are running from their own wall warts or such you don't have a common.

Jim

Reply to
James Beck

"Not Really Me" wrote in news: snipped-for-privacy@uni-berlin.de:

Scott makes very good points.

Here are some suggestions which might help if it is a hardware problem:

  1. Try running the SPI port very slow, maybe 1Mhz SCK. If it works at this speed, you may have problems suggested by Scott.

  1. Place 33 ohm series resistors at the driving end of each line. The resistors will be near the master on all lines except MISO.

  2. Try shunting a small capacitor across SCK (10-47pF).
--
Al Clark
Danville Signal Processing, Inc.
--------------------------------------------------------------------
Purveyors of Fine DSP Hardware and other Cool Stuff
Available at http://www.danvillesignal.com
Reply to
Al Clark

Wouldn't you want to connect the MOSO of master to MOSI of Slave (Master Out to Slave In??) MISI of master to MISO of Slave

Reply to
Neil Kurzman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.