SPDR not receiving data

Hi,

IÂ'm trying to use SPI in AT89S8252. Problem is that I canÂ't write to SPDR. SPDR doesnÂ't receive data but still software sets SPIF flag. Also I can write the 00h value of the SPDR to ie. R2.

code:

MOSI    EQU             P1.5
MISO    EQU             P1.6
SCK     EQU             P1.7
SS      EQU             P1.4

MOV P1,#0

MOV 0D5h,#00111000b  /* Sets DORD, MSTR, CPOL bits */
MOV 0D5h,#01111000b  /* Sets SPE bit */

MOV R1,#255

MOV 086h,R1       /* send an example data to SPDR*/

        NOP
        NOP             /*SPIF bit sets*/
        NOP
        NOP
        NOP
        NOP
        NOP

Is this a software bug or me, as a beginner, being incompetent!?

Please help me out!

Regards
Aki

Parents
  • 1) Label your SFR and use these labels instead of writing their address. That makes the code easier to read.

    2) When can you not read SPDR? The chip uses the same shift register for both transmitting and receiving, so you must wait until a full 8-bit transfer have completed before you may read the received value.

    3) How do you know that the other side shifts out any data so that your side has any data to receive?

    4) Your chip does not have any idea if it has received any data. If it is the master, it only knows that it has shifted out 8 bits, and then have to assume that the other side supplied the 8 bits to shift in. If your side is the slave, then your chip only knows that it has received 8 clock pulses, and assumes that the other side also sent 8 bits of data.

    5) You must make sure that the clock signal has the correct polarity and idle state in relation to the other side of the SPI communication.

    6) The master must make sure that it enables the slave-select signal so the slave knows to synchronize the clock ticks and actually ticks out any response data.

    Now: Exactly what have you done to verify the correctnes of the communication? In regards to the software on this side of the communication? In regards to the software on the other side (if a processor and not a SPI chip)? In regards to electrically connecting the master and slave correctly? Of matching voltage levels? Correct clock configuration? Not too high clock frequency? Enough time between slave select and clocking of data?

Reply
  • 1) Label your SFR and use these labels instead of writing their address. That makes the code easier to read.

    2) When can you not read SPDR? The chip uses the same shift register for both transmitting and receiving, so you must wait until a full 8-bit transfer have completed before you may read the received value.

    3) How do you know that the other side shifts out any data so that your side has any data to receive?

    4) Your chip does not have any idea if it has received any data. If it is the master, it only knows that it has shifted out 8 bits, and then have to assume that the other side supplied the 8 bits to shift in. If your side is the slave, then your chip only knows that it has received 8 clock pulses, and assumes that the other side also sent 8 bits of data.

    5) You must make sure that the clock signal has the correct polarity and idle state in relation to the other side of the SPI communication.

    6) The master must make sure that it enables the slave-select signal so the slave knows to synchronize the clock ticks and actually ticks out any response data.

    Now: Exactly what have you done to verify the correctnes of the communication? In regards to the software on this side of the communication? In regards to the software on the other side (if a processor and not a SPI chip)? In regards to electrically connecting the master and slave correctly? Of matching voltage levels? Correct clock configuration? Not too high clock frequency? Enough time between slave select and clocking of data?

Children
More questions in this forum