Writing to SPID register in SPI slave mode has no effect (MC9S08QG8)

[claudi]

I'm having serious problems with MC9S08QG8 device when working in SPI slave mode. Particularly I have no way to set the data to be transmitted to the master device because writing to SPID has no effect. I've isolated the problem to the minimum expression and all I can see is that, when the master starts a transfer, the contents are correctly moved to the slave's shift register, which can be successfully read by reading SPID. Further transfers show how the previous shifted word is successfully output by the slave to the master, so everything is working OK in hardware level.

However if I attempt to write to SPID (in the slave device) before any transfer starts, the shift register is never loaded and the slave outputs the last word that master sent.

I'm using Processor Expert to setup the SPI bean and, to make things simpler, I disabled interrupts and just preload SPID with a sample byte (=0xAA). However, when the very first transfer starts, the slave outputs always 0x00 (default value upon reset), thus ignoring the fact I wrote 0xAA to SPID. 

I have followed the datasheet guidelines and I can assert that SPIS is read and checked for SPIS[SPTEF] to be 1 immediately before writing SPID, but the problem is always there.

The init code generated by Processor Expert is:

    void SSI_Init(void)
    {
        SPIS;  //Read SPIS
        SPID;  //Read SPID
        setReg8(SPIC2, 0x00);
        setReg8(SPIC1, 0x00);
        SPIC1_SPE = 1; //Enable SPI
    }

The main() code (after PE initialization) is:

    //Read SPIS and check SPTEF is set. This always happens upon startup.
    if (SPIS_SPTEF) { 
        //Output sample byte
        SPID = 0xAA;
    }
    //Main loop
    for(;;){} 

I start the master transfer after the code enters the main loop, and as I told before, the slave outputs 0x00 instead of 0xAA. 

[mfugere]

dup deleted

[mfugere]

So, this only happens upon startup and reset of the microcontroller for the first byte from the slave?

I also have completed a design with an SPI Master MC9S08AC60 and Slave MC9S08AC60.  Upon system startup, it may take a few bytes of transfer between the (2) until I know that the Master is "synchronized" to the slave, e.g. that data byte I read from the slave is valid data from the preceding command that I sent to it.   My Master and Slave have different amounts of initialization code upon startup, so one may be ready before the other (plus my master can force a CPU reset on the Slave if it has to do so).  So, to ensure I have an active Slave that I know is responding to my transfers to it in timely fashion, I always start off with a loop in the master that waits for an interval of time, periodically sending a specific byte to the Slave and waiting for (3) successive responses back from it before I decide that they are both alive and in synch.   After this has completed they are generally good with data transfers.

Implementing a command - response protocol is important, I think, because like any communication link, there can be missed/dropped messages for various timing reasons in our code, ISR handling, etc.

The documentation and blocks of the peripherals in the manuals leaves something to be desired as far as detail goes - it says "double buffered", but it is unclear if this means (2) data registers between the peripheral bus and the output shift register, or if it counts the shift register as one of the "buffers".   Are you certain that your SS pin is active ahead of the first clock pulse?   It seems to me that until the Slave SPI gets at least (1) SS activation and clock pulse, it may not be fully initialized, which means it doesn't automatically transfer SPID into the shift register as it may be looking for a transition on the SPTEF bit to shift the buffer content out.  Once the "pipeline" has been primted with an SPI byte transfer, things seem to work OK for me.  But that very first one will not  be current until at least 1 byte cycle on SPI has been performed.  It behaves as if there are (2) buffer registers between the the peripherpal data bus and the output shift register.  Or, maybe the SPI control logic doesn't shift the SPID content into the shift register until it has seen an off-> transition of the transmit empty flag.     This was a brief annoyance for me at first, but I just make sure I have a command/response protocol and do an initial handshaking loop at the start to ensure the devices are in synch before relying on valid data from the slave.

Hope that this is helpful.

Mike

[claudi]

Hi Michael, 

First of all thank you for your time to answer my question in such a detailed level. Below I'm answering the different parts of your reply:

So, this only happens upon startup and reset of the microcontroller for the first byte from the slave?

It not only happens at this stage, but it's the first time I observer this problem.

My Master and Slave have different amounts of initialization code upon startup, so one may be ready before the other (plus my master can force a CPU reset on the Slave if it has to do so). 

I have a button in the Master that triggers communications, so I can assert that when I start them, the slave is 100% ready for handling transfers.

Implementing a command - response protocol is important, I think, because like any communication link, there can be missed/dropped messages for various timing reasons in our code, ISR handling, etc.

Indeed, and I actually developed a simple protocol for this purpose. However I'm still unable to test it because the Slave simply ignores any write to SPID, so it never sends data to the Master (it only outputs the last shifted in data from the Master).

Are you certain that your SS pin is active ahead of the first clock pulse?   It seems to me that until the Slave SPI gets at least (1) SS activation and clock pulse, it may not be fully initialized, which means it doesn't automatically transfer SPID into the shift register as it may be looking for a transition on the SPTEF bit to shift the buffer content out. 

I will double check that . Actually the documentation says "SPTEF is automatically set when a data byte transfers from the transmit buffer into the transmit shift register", but this never happens: it keeps at zero forever after writing SPID.

I'm gonna do more tests and publish the results as soon as I have them.

Thank you again.

[claudi]

Well, finally I found the problem.... This is one of those times in which a goblin seems having fun by fooling you. The board I am testing is a prototype, and I accidentally discovered that the wire (wrapping wire) connected to the SS pin was internally damaged (maybe because of a pinch) and the signal was inconsistent depending upon the board orientation. Crazy and embarrassing stuff :smileysad:.

I'll keep this thread open for some days in order to you read this answer and then I'll delete it (not sure if it is actually possible though).

Thank you again for your reply.

[mfugere]

Yes, it is often the basic things which can give us the most aggravation.   I make it a habit to repeat this to myself and my junior engineers anytime we find ourselves in a perplexing situation.  I am glad that you found the SS signal connection  problem on the pcb!

Best regards,

Mike