[QUERY] Behavior of spi slave memories w.r.t chip select signal.

[QUERY] Behavior of spi slave memories w.r.t chip select signal.

[viresh kumar]

Hello,

Following is what i understood after reading m25p80 driver and spi master
drivers in drivers/spi folder.

"chip_select signal controls start and end of transfer. For ex: if we have to read
status reg of spi memory, then we use write_and_then_read() routine. which writes
0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
And these two transfers are part of single spi_message.

Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
is activated at start of message and deactivated at end of message, instead at end
of every transfer.

Which means, even if there is a delay between command and dummy bytes received at
spi memory, current transfer will not be terminated by memory as cs is low."

Is this correct??

Actually i am seeing a different behavior by some of the spi memories, like m25p10.
If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
returned in response. If there is no delay then transfer always passes.

-- 
viresh

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[Jamie Iles]

On Wed, May 11, 2011 at 09:37:19AM +0530, viresh kumar wrote:
> Following is what i understood after reading m25p80 driver and spi 
> master drivers in drivers/spi folder.
> 
> "chip_select signal controls start and end of transfer. For ex: if we have to read
> status reg of spi memory, then we use write_and_then_read() routine. which writes
> 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
> And these two transfers are part of single spi_message.
> 
> Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
> is activated at start of message and deactivated at end of message, instead at end
> of every transfer.
> 
> Which means, even if there is a delay between command and dummy bytes received at
> spi memory, current transfer will not be terminated by memory as cs is low."
> 
> Is this correct??
> 
> Actually i am seeing a different behavior by some of the spi memories, like m25p10.
> If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
> returned in response. If there is no delay then transfer always passes.

What SPI controller are you using?  I've seen a similar issue with the 
Synopsys DesignWare SPI controller where the controller manages the chip 
select itself, and once the FIFO is emptied the CS goes away, but the 
flash chip requires it to stay high for the whole transaction.  In this 
case the workaround is to use a GPIO as a chip select and there are 
other controllers that do the same thing for the same reason (I think 
that pxa2xx_spi is one of them).

Jamie

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[viresh kumar]

On 05/11/2011 12:47 PM, Jamie Iles wrote:
> What SPI controller are you using?  I've seen a similar issue with the 
> Synopsys DesignWare SPI controller where the controller manages the chip 
> select itself, and once the FIFO is emptied the CS goes away, but the 
> flash chip requires it to stay high for the whole transaction.  In this 
> case the workaround is to use a GPIO as a chip select and there are 
> other controllers that do the same thing for the same reason (I think 
> that pxa2xx_spi is one of them).

I am using amba pl022 controller and using external gpio's to control
chip select signal. cs is kept low for entire message, but still i am facing
this issue.

-- 
viresh

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[viresh kumar]

On 05/11/2011 09:37 AM, viresh kumar wrote:
> 
> Hello,
> 
> Following is what i understood after reading m25p80 driver and spi master
> drivers in drivers/spi folder.
> 
> "chip_select signal controls start and end of transfer. For ex: if we have to read
> status reg of spi memory, then we use write_and_then_read() routine. which writes
> 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
> And these two transfers are part of single spi_message.
> 
> Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
> is activated at start of message and deactivated at end of message, instead at end
> of every transfer.
> 
> Which means, even if there is a delay between command and dummy bytes received at
> spi memory, current transfer will not be terminated by memory as cs is low."
> 
> Is this correct??
> 
> Actually i am seeing a different behavior by some of the spi memories, like m25p10.
> If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
> returned in response. If there is no delay then transfer always passes.
> 

Linus, Jamie,

Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.

-- 
viresh

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[Linus Walleij]

2011/5/13 viresh kumar <viresh.kumar-qxv4g6HH51o@public.gmane.org>:
> On 05/11/2011 09:37 AM, viresh kumar wrote:
>>
>> Hello,
>>
>> Following is what i understood after reading m25p80 driver and spi master
>> drivers in drivers/spi folder.
>>
>> "chip_select signal controls start and end of transfer. For ex: if we have to read
>> status reg of spi memory, then we use write_and_then_read() routine. which writes
>> 0x9F in one spi transfer and writes dummy bytes and reads rx reg in other transfer.
>> And these two transfers are part of single spi_message.
>>
>> Now, it is controllable to handle cs, and if we send cs_change == 0, then chip select
>> is activated at start of message and deactivated at end of message, instead at end
>> of every transfer.
>>
>> Which means, even if there is a delay between command and dummy bytes received at
>> spi memory, current transfer will not be terminated by memory as cs is low."
>>
>> Is this correct??
>>
>> Actually i am seeing a different behavior by some of the spi memories, like m25p10.
>> If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
>> returned in response. If there is no delay then transfer always passes.
>>
>
> Linus, Jamie,
>
> Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
> I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.

Not really. I'll throw in a few people on CC and see if they have some hints.

Linus Walleij

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[viresh kumar]

On 05/13/2011 12:24 PM, Linus Walleij wrote:
> 2011/5/13 viresh kumar <viresh.kumar-qxv4g6HH51o@public.gmane.org>:
>> Linus, Jamie,
>>
>> Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
>> I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.
> 
> Not really. I'll throw in a few people on CC and see if they have some hints.
> 

Thanks guys.

Issue is solved now, data must be latched on Rising Edge and i have passed phase as falling edge.

--
viresh

------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay

Re: [QUERY] Behavior of spi slave memories w.r.t chip select signal.

[Jamie Iles]

On Fri, May 13, 2011 at 09:22:57AM +0530, viresh kumar wrote:
> On 05/11/2011 09:37 AM, viresh kumar wrote:
> > Actually i am seeing a different behavior by some of the spi 
> > memories, like m25p10.
> > If there is a delay between read_sts_reg command and dummy bytes, then 0xFFFFFF is
> > returned in response. If there is no delay then transfer always passes.
> > 
> 
> Linus, Jamie,
> 
> Have you ever seen this kind of issue? Which spi slave memories did you used for testing?
> I am using standard pl0022 and m25p80 driver. Tried in all modes: polling, interrupt, dma.

No, not that exact issue.  I've seen with the Synopsys DesignWare 
controller that the fifo emptying causing cs to drop can result in all 
0's being read back from a m25p80, but not all 1's.

Jamie