Lpc2000

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

I think the basic problem is that the LPC213x SPI can only handle 8- 
to 16-bit transfers, and the Atmel device requires longer ones.

A simple way around this is to "bit-bang" the interface (i.e. use 
all pins as GPIO and drive them all in software). This is easy 
enough to do for SPI interfaces. Performance might take a bit of a 
hit, and you have to watch how interrupts may interfere with timing.

Brendan

--- In lpc2000@yahoogroups.com, "gogotimmo" <tah2k@...> wrote:
>
> 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
>

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]

brendan
 >I think the basic problem is that the LPC213x SPI can only handle 8-
 >to 16-bit transfers, and the Atmel device requires longer ones.

I don't know of any SPI which makes longer frames than 16bit.
If you need more you have to send more frames.

Only if the CS is really deasserted between frames you need to tweak
the CS.
(BTW: The SAMs have the problem the otherway round, for DMA transfers
they do not deassert CS which some chips need.)

> A simple way around this is to "bit-bang" the interface (i.e. use 
> all pins as GPIO and drive them all in software). This is easy 
> enough to do for SPI interfaces. Performance might take a bit of a 
> hit, and you have to watch how interrupts may interfere with timing.

A bit overkill. Using IO for CS would be enough.
Esp. if it you go for highvolume like with a dataflash.

-- 
42Bastian

--- In lpc2000@yahoogroups.com, 42Bastian Schick <bastian42@...> wrote:
>
> brendan
>  >I think the basic problem is that the LPC213x SPI can only handle 
8-
>  >to 16-bit transfers, and the Atmel device requires longer ones.
> 
> I don't know of any SPI which makes longer frames than 16bit.
> If you need more you have to send more frames.
> 
> Only if the CS is really deasserted between frames you need to tweak
> the CS.

I guess it depends on what you call a "frame" or "transfer": I'd use 
the term to describe the transfer of a set of bits framed by some 
signal (in this case CS). I don't know the Atmel device specifically, 
but it sounds like it's transferring more than 16-bits at a time.

I'd agree it's best to try and use the SPI peripheral if you can: you 
clearly need to be careful though with polarity and timing of a GPIO 
CS. By the way, does anyone know if you can use SSEL as GPIO whilst 
using the other SPI pins as peripheral pins? if you can't you'd need 
an extra pin, which aparently is not an option in this case.

Brendan

you should check the CPHA of the atmel chip in read and write mode. 
Sometimes you have to change the CPHA of your LPC chip btw read and writes 
dynamically.
----- Original Message ----- 

From: "gogotimmo" <tah2k@...>
To: <lpc2000@yahoogroups.com>
Sent: Thursday, May 18, 2006 7: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
>
>
>
>
>

At 08:40 18.05.2006 +0000, you wrote:
>--- In lpc2000@yahoogroups.com, 42Bastian Schick <bastian42@...> wrote:
> >
> > brendan
> >  >I think the basic problem is that the LPC213x SPI can only handle
>8-
> >  >to 16-bit transfers, and the Atmel device requires longer ones.
> >
> > I don't know of any SPI which makes longer frames than 16bit.
> > If you need more you have to send more frames.
> >
> > Only if the CS is really deasserted between frames you need to tweak
> > the CS.
>
>I guess it depends on what you call a "frame" or "transfer": I'd use
>the term to describe the transfer of a set of bits framed by some
>signal (in this case CS). I don't know the Atmel device specifically,
>but it sounds like it's transferring more than 16-bits at a time.
>
>I'd agree it's best to try and use the SPI peripheral if you can: you
>clearly need to be careful though with polarity and timing of a GPIO
>CS. By the way, does anyone know if you can use SSEL as GPIO whilst
>using the other SPI pins as peripheral pins? if you can't you'd need
>an extra pin, which aparently is not an option in this case.

As far as I know (but I'm not the expert) the newer LPCs can use SSEL as 
GPIO when using the SPI as an master only, older chips like the LPC2106 
need this pin tied to high via a resistor.

Regards
Herbert


>Brendan
>
>
>
>
>
>
>
>SPONSORED LINKS
><http://groups.yahoo.com/gads?t=ms&k=Microcontrollers&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=c-HXthtbZy4TZbI3ib0PMg>Microcontrollers 
><http://groups.yahoo.com/gads?t=ms&k=Microprocessor&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=ijt0SspWtjogcHCuFD0lUQ>Microprocessor 
><http://groups.yahoo.com/gads?t=ms&k=Intel+microprocessors&w1=Microcontrollers&w2=Microprocessor&w3=Intel+microprocessors&c=3&s=69&.sig=WOZdpklkgHbXR5quAgrl5w>Intel 
>microprocessors
>
>
>----------
>YAHOO! GROUPS LINKS
>
>    *  Visit your group "<http://groups.yahoo.com/group/lpc2000>lpc2000" 
> on the web.
>    *
>    *  To unsubscribe from this group, send an email to:
>    * 
> <mailto:lpc2000-unsubscribe@yahoogroups.com?subject=Unsubscribe>lpc2000-unsubscribe@yahoogroups.com 
>
>    *
>    *  Your use of Yahoo! Groups is subject to the 
> <http://docs.yahoo.com/info/terms/>Yahoo! Terms of Service.
>
>
>----------


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

brendan

>> Only if the CS is really deasserted between frames you need to tweak
>> the CS.
> 
> I guess it depends on what you call a "frame" or "transfer": I'd use 
> the term to describe the transfer of a set of bits framed by some 
> signal (in this case CS). 

Correct. I think this should be the definition.

>I don't know the Atmel device specifically, 
> but it sounds like it's transferring more than 16-bits at a time.

You can up to the full size of the chip without deasserting CS.
But a single transfer is 8bits.

-- 
42Bastian