SPI EEPROM using SSP ( LPC1768, lpcxpresso)

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

SPI EEPROM using SSP ( LPC1768, lpcxpresso)

708 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by richas on Fri Nov 15 13:44:01 MST 2013
Hi All,
    I am having some issue with an AT25040 SPI EEPROM using the SSP interface.

I am writing 0xAA to location 0.  I read it using this code: 

volatile uint8_t testVal = 0;

LPC_GPIO1->FIOCLR |= (1 << 22);//assert CE
LPC_SSP0->DR = (((0x08) & adr) | 0x03);
while ((LPC_SSP0->SR & 0x10) == 0x10);
LPC_SSP0->DR = adr;
while ((LPC_SSP0->SR & 0x10) == 0x10);
LPC_SSP0->DR = 0x00;
while ((LPC_SSP0->SR & 0x10) == 0x10);   //LPCxpresso register watch show 0XAA in the DR here  (Mouse over of the DR shows zero!)
testVal = LPC_SSP0->DR;
while ((LPC_SSP0->SR & 0x10) == 0x10);
LPC_GPIO1->FIOSET |= (1 << 22);//deassert CE

return(testVal);


As I step through it, watching the SSP registers in LPCxpresso, I see the DR get loaded with 0xAA as descibed in the comment in the code.  Mouse over shows zero.  TestVAl gets loaded with 0.

Ideas?

Rich
0 Kudos
6 Replies

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by richas on Tue Nov 19 11:27:55 MST 2013
I stared over.  I rewrote the routine.  First it waits for the busy flag to be cleared, then it clears the FIFO.  I wait for the busy flag to be cleared after each transaction.  It now works perfectly.  I am not sure this is different that what I have done before, I suppose it must be as it works.  :P

Thanks for the help

Rich
0 Kudos

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Mon Nov 18 22:30:03 MST 2013
Get a logic analyzer (with SPI decoding). It will save you a lot of time...
0 Kudos

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by richas on Mon Nov 18 16:35:49 MST 2013
Martin,
     I am doing multiple reads before the read procedure to clear the fifo, although the RNE bit is cleared.  I added code to read the DR after each DR write.  I see the 0xAA in the DR after the dummy write, the RNE bit also gets set at this point.  As soon as I read the DR the DR contains zero, but my read also returns zero.

Speaking of dummies, this has got to be something dumb I am doing (or not doing).  It is always something dumb....

Rich

0 Kudos

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Mon Nov 18 12:35:56 MST 2013
Hi Rich,

could it be that you have bytes left from previous SPI accesses (write action)?
Try to read the FIFO (BTW: 8 bytes for RX and 8 bytes for TX with 8 bit frame length) till it is empty before your read request.
I usually write 1 byte, check if it sent (bit 0 in SR), check if answer was received (bit 2 in SR) and read 1 byte.

Best regards,

Martin
0 Kudos

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by richas on Mon Nov 18 12:25:25 MST 2013
Thanks Martin,
     I have verfied with a scope that I am receiving on MISO the 0xAA.

I am watching the RNE (RX Buf Not empty) bit in the status register.  It is not set until the last (dummy) write to the DR.  It is then set.  The debugger  SSP0 peripheral view show the DR containing 0xAA.  When I read the DR the RNE bit is cleared, the DR shows  0x00, but the variable into which I read the DR is also 0x00;

How deep is the FIFO, do I need to do repeated read to get the last entry, it reads out the least recent?  Is the FIFO empty if the RNE bit is cleared?  The manual is lacking detail....

Rich
0 Kudos

544 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by capiman on Fri Nov 15 22:39:59 MST 2013
Hello Rich,

sorry, i don't know AT25040, but some general points:

- When you write one byte on SPI, you get automatically one byte on SPI. This is written to FIFO and remains there when you don't read it.
  You are writing 3 bytes (i assume you have configured 8 byte transfers), then reading 1 byte.
  The byte you are reading is the answer on the first byte written. Is this what you want?
  Or do you perhaps need a dummy read after each write action?

- Are you sure the write operation (where you set 0xAA to location 0) was successful? Perhaps there is a 0x00 at this place and read is working?

- Have you checked the SPI lines signals with some probe (logic analyzer, scope, TTL pen)?

- This is perhaps dangerous (in term of you change something and forget to change both places):
   while ((LPC_SSP0->SR & 0x10) == 0x10);
   Perhaps use the following instead (is perhaps even faster to execute)
   while ((LPC_SSP0->SR & 0x10) != 0x00);

Best regards,

Martin
0 Kudos