SPI interface in MC9S12GC32

[STD]

Hi,

I'm using an SPI interface in processor MC9S12GC32  to interface a serial EEPROM. I have configured the SPI inetrface as per the guidelines provided by interface documents. In my application, I'm sending a command to read data byte from a specific address of the memory chip. All the necessary signals viz, chip select, clock, MOSI etc are generated properly (as per the signal levels/frequency provided by chip manufacturer) but there is no data placed on MISO by the memory chip. If we access the chip using general purpose I/O, data read / write is perfectly working.

It is observed that after sending 3 bytes (command byte and 2 bytes of address) on MOSI, SPI controller of the processor deselects the chip and clock is also stopped. What could be the reason for this behaviour of SPI controller?? After sending 3 bytes, it is expected that memory chip shall send the data byte on MISO. Can anybody help?

[STD]

Thanks Mac!

After sending dummy byte following USB of address, now I can see the data byte on MISO pin of the processor. I also separated the chip select line from SPI interface.

Now whatever I write to memory, I can see(waveforms) it on MISO pin when I send READ command. But still processor is not able to read it in the provided data register . For this processor (HCS12), there is single data register SPIDR for reading as well as writing. SPI interface in processor has been configured as Master and there is no BIDIROE enabled. After sending dummy byte, data (sent by memory chip) appears on MISO line but if SPIDR is read, it returns 0 only.

There is a flag to indicate the arrival of data in data register named SPIF flag. This flag is being set but still data read is 0. What could be the problem?

Regards,

STD

[peg]

Hi STD,

Note that simply sending the dummy byte is sufficient to cause SPIF to be set when it completes, whether or not the slave device actually drove the line into MISO or not. After all a return byte of $00 is just the same as MISO held low while the dummy byte is sent out on MOSI.
I think you need tolook more closely at the signal on MISO and perhaps its relationship to SCLK to understand what is happening here.

[bigmac]

Hello, and welcome to the forum.

After you send the read command byte, followed by the bytes corresponding to the first address to be read, it is necessary to then send a "dummy" byte value for each data byte to be returned by the EEPROM.  From your description, It is possible that you may not be doing this.  This is the means of generating the clock pulses for the return of each byte.

Also, I assume that you would set SS signal low prior to sending the command byte, and that it should remain low until the last byte is returned from the EEPROM.  For EEPROM communications this signal should be allocated from GPIO, rather than the use of "automatic" SS operation available within some SPI modules.

Regards,

Mac