MC9S12NE64 SPI not transmitting in Slave mode

[barneymc]

I am not able to transmit data from this chip in slave mode. The master receives only an echo of the data it has sent to the slave, rather than the data I am trying to send from the slave. The master is a Microchip PIC which I have run succsssfully in other products.

I have tried both CPHA=0 and CPHA=1 modes. In both cases I can get the data correctly from the Master to the Slave, but never get anything but an echo back.

I have tried looping on SPISR until SPTEF goes low, writing my data into SPIDR repeatedly. Even when I write Assy language that forces two sequential instructions to read SPISR (after I see SPTEF=1) and write my data into SPIDR, the data I write does not get transmitted.

I have searched the forum and found another message with a similar problem, but there was no real solution there. Just what looks like an error, as they claim to set the MSTR bit to a 1 in the slave, which can not be correct in this chip.

Any suggestions?

[barneymc]

Thanks again for the help. I have tried toggling the SSEL line as you suggest. It does not seem to help.

I have tried everything I can think of to get data into the transmit buffer, but the NE64 refuses to send what I want.

I gave up on using the NE64 in slave mode and rewired my board, and rewrote my code to use the NE64 in master mode. This seems to work much better. I can send data in both directions now.

As a last thought on the NE64 in slave mode, I remember a note from another thread that said the NE64 seems to send a few garbage chars in the first few transfers over the SPI in slave mode. This is unacceptable to me, as I use a formatted message to be sure I am in synch, and do not want to spend any more time playing with the NE64 to find when I might actually get something I want out of it.

Another potential problem could be that I was not waiting enough time between one byte transfer and the next. That seems unlikely, but I spent most of my time trying to get the first byte out of it corectly. If the first byte was known garbage, I could have not been waiting long enough to see if the byte I was trying to send ever made it.

When I first tried the rewired master-mode NE64, I did have not enough time between bytes, and saw the same echo problem coming out of the PIC in slave mode. By adding a delay between bytes on the master side, I am able to get data into the slave transmitter in time for it to work.

I am not interested enough to redo my board again, as I need to move on, and what I have now seems to do what I need.

[mjbcswitzerland]

Hi

I have built an SPI/Ethernet TCP/IP co-processor using the NE64 in SPI slave mode and found it worked fine. Therefore I don't think that there is a bug in the chip.

There have been some posings concerning problems but as far as I know these could always be solved by correct coding.

Here's a very brief initialisation and slave (reception/)transmission sequence (probably well out of context) but you may see something. If you have no luck, send me your code and perhaps I can see wheat is going wrong.

Cheers

Mark

www.mjbc.ch

unsigned char ucTestByte = 0x55;                   // test byte
SPICR1 = (SPIE | SPE);                                   // enable in slave mode - enable interrupt of rx char
SPIDR = ucTestByte ;                                      // prime first test byte.

.. when master reads(sends), it will read the test byte and interrupt will occur

void SPI_Interrupt(void)                                     // interrupt routine when byte read
{
volatile unsigned short usDummy = SPISR;    // dummy read of status register on entry (we know it is rx)
volatile unsigned char ucRx = SPIDR;             // read the received byte
while (!(SPISR & SPTEF)) {}                           // wait until Tx complete before setting next byte
SPIDR = ++ucTestByte ;                                 // send next value
}

[barneymc]

Thank you very much for your response. It sounds like your project is very similar to mine.

I am still not able to get the NE64 to send data in slave mode. I have seen data come out of it in master mode. I am about to give up and rewire my circuit to allow the NE64 to be the master, and see if that gets the job done.

I also sent a request directly to Freescale, and got a response from them. Below are their questions and my responses.

FS - Are you sure that your CPOL needs to be cleared?

ME - I can configure the PIC either way. I have it configured with the
idle state of SCK low to make the power control in my design
easier.
Should the CPOL setting affect the non-transmission of data in slave
mode?

FS- Double check with your PIC part and the timing diagrams of the SPI.

ME - Since the NE64 receives data correctly from the PIC, I am pretty
sure the clock settings and hardware hookup are correct. As
described below, I have tried several different configurations.
Always the same result PIC->NE64 fine, NE64->PIC not.

FS - It does notsound like you are using the SPTEF flag correctly. This flag will normally be set until you read from the status register and follow itwith a write to the data register.

ME - I see a problem with SPTEF. I poll for it to be high, then write data to the SPIDR. After a few NOPs, I can read the SPISR and SPTEF
is still a one. Here is a code snippet:

while (!( SPISR & SPTEF )) {
; // wait until tx buffer empty
}
SPIDR = SPI_STX; // prepare to send the first byte
NOP();
NOP();
temp = SPISR;
NOP();

If I set a breakpoint on the last NOP, I can see the temp is equal
to 0x20, meaning that SPTEF is still set.

I have even added code to loop on SPTEF not going false, and
continually loaded the SPIDR until it does go false. I think this
takes only two writes to the SPIDR to make SPTEF go false.
Even then, the data I put into the SPIDR does not come out on
the MISO pin. The data I see coming out of the MISO pin is an
echo of the data sent into the chip on the MOSI pin, from the PIC.

I thought the problem could be the CPHA mode, so I configured
the hardware with CPHA = 0, and wired up a pin from the PIC to
drive SPI_SS/ as required (low during transfer, high between bytes.)
The NE64 can receive data correctly, but still only sends an echo
of the data it received.

I then reset the hardware back to CPHA=1 mode, and still use the
SPI_SS/ pin as a gate during the byte transfer. Still nothing but an
echo out of the NE64.

To test the SPI hardware in the particular NE64 chip on the eval board
I am using, I put it into Master mode. With my PIC halted and the
signals from it to the NE64 tri-stated so the NE64 could change
direction and drive SCK and MOSI. I can see the data I am trying
to transmit come out on the pins as I would expect. This leads me
to believe the chip is functional.

FS - Another easy question, are you sure you are checking the MISO signal? This is the one that has the slave out data.

ME - Yes, I think this is wired correctly, as on an o-scope, I can see the data it is sending come out on the MISO pin. I see the data coming
from the PIC on the MOSI pin in one byte get echoed back out of the
NE64 on the MISO pin in the next byte.

FS - The baud generator does not make any difference in slave
mode, but setting it will have no adverse effect.

ME - I have tried not setting the SPIBR and setting it, with no effect.

FS - All I can recommendis to see if any data is actually coming from the MISO signal. Let me know more if you still need help. I just am not sure what else it could be.

ME - As described above, I have seen data on the NE64 pins as I would
expect. Just not the correct data, in slave mode.

[mjbcswitzerland]

Hi

It is a shame that things are not working out just yet. I have had a quick think and just two things spring to mind.

1. You say that you receive an echo from the NE64. This sounds in fact to be quite normal for a slave device which doesn't have any data ready to be sent - that means I have also experienced this (not sure whether the NE64 or another) but it seems to be the way the SPI shift registers work. If there is data ready to be sent it will be sent and if not there is probably an echo. This means that you should carefully check the parts of code which are writing the data to be transmitted when the master reads because it may be that this is somehow not really writing the register correctly.
2. The SSEL line. The slave requires it be activated by the SSEL line, which is probably the case since it must be driving the MISO line to send the echos. I looked at the code at the master side of my design (a Philips LPC2106) and saw that I set the SSEL line to '0' when sending and back to '1' between each byte being send. Not sure why but it may be that the NE64 needs this.
The operation of the SSEL line seems to be ill defined between devices since the SSEL line in master mode is activated automatically to drive just during each byte transmission for some devices (I think it's like this for the NE64) and this will not work with some peripheral devices. I have a file system for a web browser which is in external SPI EEPROM and it was, for example, not possible to use the SSEL line of the NE64 SPI in automatic operation mode - the SPI EEPROM just didn't want to know. Therefore I had to program the output as a normal port and activate it continuously during block read and writes - this worked fine.

Check out these points before giving up, maybe there is something there. Ifyou are setting SSEL continuously low from the PIC try just activating during each byte tranmission...

Cheers

Mark Butcher
www.mjbc.ch