Yahoo Groups archive

Lpc2000

Index last updated: 2026-04-28 23:31 UTC

Message

Re: [lpc2000] Annoying Problem With SPI interface to Atmel Dataflash

2006-05-18 by Sagaert Johan

hi

I have working code for the AT45DB021, so i think its similar as for the one you use.

You have to do the chip select yourself, and to read , you need to perform a dummy write

this is the code i use to read the status of the 45DB021 connected to LPC2103, 


/************************************************
* Read chip status                              *
*************************************************/
byte readstatus(void)
{
  byte status;
 
 //begin CS=0
 FIO0MASK0=0x7f;
 FIO0PIN0=0;

   //send command
 S0SPDR=READSTATUS;
 //wait until sent
 while((S0SPSR & 0x80)==0);

 // send dummy byte
 S0SPDR=0;

 //wait until sent
 while((S0SPSR & 0x80)==0);
  
 //read data
 status=S0SPDR;
 
 //end CS=1
 FIO0MASK0=0x7f;
 FIO0PIN0=0x80;
 return status ;
}


Be sure to init the SPI correctly (clock rate & polarity )

 // init SPI mem interface
 S0SPCR=0x0824;
 S0SPCCR=0x1e; // clock 15mhz/30


Regards, Johan
 
  ----- Original Message ----- 
  From: gogotimmo 
  To: lpc2000@yahoogroups.com 
  Sent: Thursday, May 18, 2006 6:24 AM
  Subject: [lpc2000] Annoying Problem With SPI interface to Atmel Dataflash


  Hi-

  I am having probles with the LP32138 SSP (SPI) interface to an Atmel 
  dataflash (AT45DB161). I believe it has to do with the chip select 
  implementation. To read the status register of the Atmel dataflash, 
  for example, the device requires an opcode 'write' followed by 
  a 'read'. The write works fine, but the 'read' fails. I believe it is 
  failing because the chip select gets deasserted between the read and 
  write, thereby resetting the internal state machine of the data flash. 
  The datasheet of the atmel memory has timing diagrams that show the CS 
  asserted throughout the entire transfer with no transitions between 
  frames.  Actually, it looks like the LPC2138 spi chip select gets 
  deasserted between each frame in a continuous transfer. If true, this 
  bites. The only workaround I can think of is to use a GPIO pin to 
  drive the CS manually. Since I'm already out of pins, this isn't a 
  great option for me. I thought of tricking the SPI peripheral by 
  sending an 8-bit opcode justified in a 16-bit frame, which would 
  probably work, but will fail when reading an array of memory 
  addresses. These Atmel dataflash devices are extremely popular, so 
  someone must have had similar issues.

  Also, I don't mean to sound rude, but I have already looked at the SPI 
  code examples. 

  Any help is appreciated-
  Thanks-
  Tim





------------------------------------------------------------------------------
  YAHOO! GROUPS LINKS 

    a..  Visit your group "lpc2000" on the web.
      
    b..  To unsubscribe from this group, send an email to:
     lpc2000-unsubscribe@yahoogroups.com
      
    c..  Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. 


------------------------------------------------------------------------------



[Non-text portions of this message have been removed]

Attachments

Move to quarantaine

This moves the raw source file on disk only. The archive index is not changed automatically, so you still need to run a manual refresh afterward.