SPI bus Slave Select on HCS08QE

[rlstraney]

Hi,

When I execute my code Slave select isn't going low at the correct time.

When I run the code below I see the proper values transmitted out MOSI (And the clock is correct) but SS_n is NOT encapsulating the data, it is shifted forward in time to about the 2nd clock and then falling.    In other words SS_n drops after the first 2 bits are transmitted.

Yet the datasheet shows that if the SPI i/f is set up as master that SS_n should drop 1/2 tSPSCLK before the first clock edge.

Does anyone know what the datasheet is referring to when it says DDS7=1?  I am referring to the figure on page 23 of the "MC9S08QE8 Series Data Sheet, Rev. 7". 

I searched both the reference manual and the datasheet for DDS and found nothing close other than PTDDS which is Port D's drive strength register. 

If you notice I have a couple places where I have commented out code:

    //PTBD_PTBD5 = 0;

    //PTBD_PTBD5 = 1;

If I change SPIC2 from 0x12 to 0x02 (In SPI_Init) and uncomment these two lines in the "SPI_Send_byte" function then SS_n works.   -BUT- I shouldn't have to do this since there is dedicated hardware in the chip to handle it for us.   (And I believe it would run slower than the dedicated hardware  - once I find what I am doing incorrectly.)  All this is doing is making SS_n GPIO and I am bit banging it.

I am assuming that SS_n is driven high and low (i.e. I don't need a pulldown on that line)?

#include <hidef.h> /* for EnableInterrupts macro */
#include "derivative.h" /* include peripheral declarations */

#ifdef __cplusplus
extern "C"
#endif

/****************************************
**
**        Subroutines Definition
**
****************************************/

void SPI_Init(void);
void SPI_Send_byte(unsigned char data);
#define SPI_SS    PTBD_PTBD5      // Slave Select
#define _SPI_SS   PTBDD_PTBDD5    

void main(void) {
    
    SPI_Init();

    for( ; ; )
    {
        SPI_Send_byte(0xF1);
     SPI_Send_byte(0x72);
    } // end for
    
}



void SPI_Init(void)
{
   
   SPI_SS = 1;
  _SPI_SS= 1;
 
        SPIC1 = 0x00;
        SPIC2 = 0x12;
        SPIBR = 0x00;
        (void)(SPIS==0U);
        SPIC1 = 0x52;
}
 

 void SPI_Send_byte(unsigned char u8Data)
{
    int dummy;
    while(!SPIS_SPTEF);
    dummy = SPIS;
    //PTBD_PTBD5 = 0;
    SPID=u8Data;
    while(!SPIS_SPRF);
    dummy = SPID;
    //PTBD_PTBD5 = 1;
}

Renee

[bigmac · Accepted solution]

Hello Renee,

You do not say what slave device to which the master is connected?  Maybe you should check that there is not a pin conflict with the slave connection to SS.  Perhaps you have the high drive strength setting when you bit bang, which would not apply to the automatic SS case, so you might then not notice any conflict.

There are some situations where you require to bit bang the SS output, most often when the slave requirement is for SS to remain active low for multiple SPI bytes, e.g serial EEPROM. 

There will be only a marginal effect on overall timing, likely amounting to five cycles per SS transition.  Keep in mind that the overhead associated with the execution of your SPI_send_byte() function will mean at least 50-60 cycles for the fastest SPI clock rate, maybe more.  So the effect of the additional bit banging instructions would be minor.

Since you are completing transfer of a single byte at a time, the SPTEF flag will always be set when you enter the function, so the test of the SPTEF flag could be eliminated (with the potential saving of five cycles).  However, it is then essential to read SPIS during initialisation (as you are currently doing).

Depending on the requirements of your slave device, another possibility could be to utilise CPHA = 1.  Then it is not necessary to raise and lower SS between bytes - all SPI timing is referenced to the first SPI clock edge for each byte transfer.

Regards,

Mac

[rlstraney]

Mac,

Thank you for your reply.  The hardware I am using is the DEMO9S08QE8 board.  

When responding to your message I found the problem.

I thought that they had wired the four SPI port pins only over to the 56 pin MCU connector.   They did for MOSI MISO and SPSCLK but SS_n also was wired to a Piezo Buzzer.  Apparently the buzzer has enough capacitance to keep the SS_n trace from discharging fast enough.  (So on my logic analyzer SS_n seemed to take way to long to go to logic 0. )

The Buzzer can be disconnected by removing a jumper (J19) and now SS_n drops where it should.  Somehow I didn't see that it was connected to the buzzer.  

Thanks again,

Renee