M52233DEMO QSPI no data read back from AT25F512A

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

M52233DEMO QSPI no data read back from AT25F512A

2,518 Views
WOLF
Contributor I
I'm trying to read back the status regster from the SPI Serial Flash AT25F512A, but always get back 0's my code is below. can anyone see any problems with it?
Code:
 int i;    MCF_GPIO_PQSPAR = 0x1555;    MCF_GPIO_DDRQS = 0; MCF_QSPI_QMR   = 0xA308; MCF_QSPI_QDLYR = 0x0000; MCF_QSPI_QIR   = 0xD00F;  MCF_QSPI_QAR   = 0x0020; MCF_QSPI_QDR   = 0x7E00; MCF_QSPI_QAR   = 0x0000; MCF_QSPI_QDR   = 0x0005;  MCF_QSPI_QWR   = 0x0100;  MCF_QSPI_QDLYR = MCF_QSPI_QDLYR_SPE;  while( !(MCF_QSPI_QIR & MCF_QSPI_QIR_SPIF )) {  // Spin here waiting for completion      }; printf("Transfer Complete");   MCF_QSPI_QAR   = 0x0010;  printf("\nData[%d]: %d\n", 1, MCF_QSPI_QDR);

 

 
Labels (1)
0 Kudos
7 Replies

466 Views
RichTestardi
Senior Contributor II
Hi,
 
I successfully clone the flash from a M52221DEMO board to target ColdFire cores using QSPI-to-EzPort, which I believe is similar to what you're trying to do.
 
My pin connections and code (you just care about main.c) is posted here:
 
 
Other than the WRITE_CONFIGURATION_REGISTER (which I believe is ColdFire-specific), it should be very similar to what you need.  (I also control the target core's RSTI* and RCON* line, which you also probably don't need...)
 
I *do* use the QSPI_CS0* output successfully, though to do large page transfers, you have to go thru some effort to keep it asserted...
 
I computed my BAUD and DIV values assuming I was running on the internal 8MHz oscillator, PLL'd up to 48MHz.
 
Yeah, a scope is really useful here to see what is going on.
 
Hope this helps!
 
-- Rich
 
0 Kudos

466 Views
WOLF
Contributor I
Turned out to be a Mode ISSUE. reading data on falling when should of be on rising.
 
 
0 Kudos

466 Views
WOLF
Contributor I
Thanks for your suggestions.
 
If i read correctly. you are suggesting i add pull up to the RX line of the Coldfire.   should there be any other pull-ups or downs on other spi ines?
 
 
0 Kudos

466 Views
mjbcswitzerland
Specialist V
Hi

I think that a pull up is tyically used - the others are outputs so need nothing. However this is a detail, it probably doesn't disturb.

I belive your main problem is that you are only reading one byte deep in the RX queue whereas the status byte that interests you is probably at the seccond byte in the FIFO, therefore the need to do one dummy read to pop the byte to the top.

Regards

Mark

0 Kudos

466 Views
WOLF
Contributor I
Here is my latest Code...  and what it returns.
 
Code:
 int i, z;    MCF_GPIO_PQSPAR = 0x5555;     MCF_GPIO_DDRQS = 0;  MCF_QSPI_QMR   = 0x8002; MCF_QSPI_QDLYR = 0x0000; MCF_QSPI_QIR   = 0xD00F;  MCF_QSPI_QAR   = 0x0020; MCF_QSPI_QDR   = 0x7000; MCF_QSPI_QAR   = 0x0000; MCF_QSPI_QDR   = 0x05; MCF_QSPI_QDR   = 0xFF;   MCF_QSPI_QWR   = 0x0100;  MCF_QSPI_QDLYR = MCF_QSPI_QDLYR_SPE;  while( !(MCF_QSPI_QIR & MCF_QSPI_QIR_SPIF )) {  // Spin here waiting for completion      };   MCF_QSPI_QAR   = 0x0010; printf("\nData[%d]: %d\n", 1, MCF_QSPI_QDR); printf("\nData[%d]: %d\n", 2, MCF_QSPI_QDR); printf("\nData[%d]: %d\n", 3, MCF_QSPI_QDR); printf("\nData[%d]: %d\n", 4, MCF_QSPI_QDR); printf("\nData[%d]: %d\n", 5, MCF_QSPI_QDR); printf("\nData[%d]: %d\n", 6, MCF_QSPI_QDR);

 my resaults were
Data[1]: 255
Data[2]: 255
Data[3]: 0
Data[4]: 0
Data[5]: 0
Data[6]: 0
0 Kudos

466 Views
mjbcswitzerland
Specialist V
Hi

Assuming that you now have a pull up on the RX line this suggests that 2 bytes are being received (the first 2 read out of the FIFO) but the RX line is always '1'.

Is the SPI FLASH chip reacting? Check that the CS line is being controlled correctly and that the clock phase suits the device - compare the waveform you see with figure 6 (RDSR Timing)) in the data sheet:
http://www.atmel.com/dyn/resources/prod_documents/doc3345D.pdf

Regards

Mark





Message Edited by mjbcswitzerland on 2008-02-29 03:02 PM
0 Kudos

466 Views
mjbcswitzerland
Specialist V
Hi Wolf

I have used the Atmel AT45dbxxx devices and the ST STM25Pxxx devices with the QSPI. Here are some comments.

I use PQSPAR = 0x0015 - just the SPI lines, CS lines controlled via GPIO (I don't see any advantage of letting the QSPI control the CS lines automatically in this specific case - the code overhead is higher) - you are configuring all CS lines.

I use QMR = 0xa002 for highest speed (check the clock and phase settings - the SPI FLASH chip possibly adapts itself though).

QWR = 0x0100 configures to send 2 bytes - the first 0x05 (I presume the command to read the status).

When the SPIF flag is set it means that the transmission (and reception) has completed.

QAR = 0x0010 is setting the address pointer to the first byte in the RX queue.

I think that you basic problem is that you are reading the first byte in the queue - this will be returned while the status command byte is being transfered. Probably you don't have a pull up on the RX line and so the value is 0x00.
What you need to do is read the second byte in the RX queue, which will have been set when the second byte was transfered (the second TX byte is not being defined by your code - I tend to ensure that always 0xff is sent to keep the TX line stable when reading).

Therefore if you do
 MCF_QSPI_QAR   = 0x0010;
 dummy = MCF_QSPI_QDR;
 printf("\nData[%d]: %d\n", 1, MCF_QSPI_QDR);

You might find that the value is then as expected.
Also checking the CS and data on the SPI bus with an oscilloscope or logic analyser will ensure that the chips is
basically responding.

BTW. Keep all lines as short as possible. It may even be advisabe to terminate the clock line.
It may not be as sensitive with the SPI FLASH that you are using but the ones above don't tolerate any ringing.
Even connecting a scope to the clock line can be enough to stop it working correctly!!

Regards

Mark

www.uTasker.com

0 Kudos