QE8 SPI slave does not transmit data to master

[Lokutas]

Dear community,

I've been developing a SPI slave application using the QE8, so far I haven't been able to make the QE8 slave transmit data to the master, the master does trasmit the first "command" byte and then a blank byte just to clock the bus and get the byte out of the slave but it doesn't work. I know my master code is not bad because I'm using the same one to read other SPI devices.

I've read a couple fo threads in this forums regarding SPI_slave bugs but those are for the HSC12, the same fix didn't work for my case.

My application code is the following (using interrupts):

void interrupt SPI_RX_isr (void)
{
 byte temp;
 temp = SPIS;  /* Read the SPI Status and Control Register (required to acknowledge interrupt) */
 temp = SPID; /* Read of SPDR to complete the interrupt acknowledgement.

    if (temp & READ_FLAG) {
      switch (temp) {
        case GXP_HITS_ACUM_L:
          SPID = (byte) g_hits;
          while(!SPIS_SPRF);     
          temp = SPID;
          break;
        case GXP_HITS_ACUM_H:
          SPID = (byte) (g_hits >> 8);
          while(!SPIS_SPRF);     
          temp = SPID;
          break;
        default:
          SPID = 0;
          break;
      }
    } // if (temp & READ_FLAG)
  }
}

What I read all the time is the same byte the master srote to the slave, so it seems like the slave cannot modify the SPID register... When I step-by-step my code, the SPID = X assignment doesn't do a thing with the SPID memory location (address 0x2D).

An observation I made is that the SPIS_SPTEF flag never gets set, could this be related to my bug? (if it is it will be a HW bug)

Has somebody made the SPI slave work on a HCS08?

Kindest Regards,

Carlos

Message Edited by Lokutas on 2008-07-22 09:24 AM

Message Edited by Lokutas on 2008-07-22 09:27 AM

[bigmac]

Hello Carlos,

Following the master sending the command byte, you will need to wait a sufficient time for the slave ISR to complete, before sending the next dummy byte to interrogate the returned data from the slave.  The return byte value needs to already have been written to SPID before SS input again becomes active low for the return byte transfer.

If this is the problem, the inclusion of a small delay within the master code should help.

Incidently, I have found that switch statements generally require more processing cycles than the equivalent  if...else if...else  construct.

There also seems to be a misunderstanding about the values read from and written to the SPID register.  You cannot read back the value previously written.  The following thread covers similar ground in this respect.

http://forums.freescale.com/freescale/board/message?board.id=8BITCOMM&thread.id=11435

Regards,

Mac

[Lokutas]

Hi Mac,

Thanks a lot for your help, I added a delay to my master, a dummy delay just to debug and the problem is still there.

void dummy_delay(byte i) {
  byte a,b,c;
 
  for (a = 0; a < i; a++)
  for (b = 0; b < i; b++)
  for (c = 0; c < i; c++);
}

It seems like the slave is not effectively loading the SPID value I write during the ISR to the SPI TX shift register.

I guess that's why the master allways reads the same command byte it outputs to the slave, even after the master's SPID has been filled with a dummy byte different than the first command byte.

Any one else has a better idea?

I've seen app notes and example code where the SPI slave only receives data doesn't send anything back, could this be all the functionality FSC provides for a SPI slave?

Thanks,

Carlos

[Lokutas]

I have continued my testing, a key piece of the puzzle should be that the SPIS_SPTEF flag only gets set when the SPI module is enabled in my init sequence and doesn't get set ever again.

Has somebody managed to make an SPI_slave output a byte?

Thanks,

Carlos

[Lokutas]

It was a bad solder joint on my connector that spoiled the related Chip Select and also, the fact that a slave with CPHA=0 required the master to again pull high and low the CS for every byte.

A lesson to me to start with the basics of a thourough read of the datasheet and a complete debug of the HW.

Thanks a lot,

Carlos