You are here

CY14B256Q2A access methodology problem | Cypress

CY14B256Q2A access methodology problem

Summary: 1 Reply, Latest post by brucle on 26 Jan 2012 12:34 AM PST
Verified Answers: 0
Last post
Log in to post new comments.
brucle's picture
User
2 posts

Hi,

I'm running linux on an MPC8308, trying to access a CY14B256Q2A SPI nvSRM and I'm having dificulties.  To avoid having to write my own driver, I'm utilizing an existing Freescale driver for the SPI controller in the 8308 (spi_fsl_spi), and an existing interface driver that sits on top of that (spidev specifically if it matters) and I'm unable to even read the status register of the nvSRAM.  I'm pretty sure the problem is in the way these two drivers work but I want to confirm it with you since the datasheet for the nvSRAM isn't explicit either way.

To read the status register the device needs to have CS asserted, SPICLK started, and 0x5 clocked onto MOSI.  On the first clock following the read status reg command the MSB of the status register gets clocked out on MISO.  My question is, what happens if the clock stops for a period of time between the LSB of the commnd and the MSB of the result?  I've scoped the signals and what I see is eight clock pulses with the read status reg command, then clock goes silent for about 20msec and then starts back up (CS is held low the entire time), but it appears no data is clocked out of the nvSRAM when the clock starts back up.  Does the part require that clock be continuous for the entire transaction?

The fact that burst reads are possible as long as CS is held low implies that the clock can start and stop without impacting the part, but it's not totally clear.

Thanks.

Bruce

brucle's picture
User
2 posts

Well this is embarassing.  I've answered my own question.  Yes the part is fully static and can tolerate the clock stopping between ending a command and reading the results.  I had it in my head that there was a non-zero value in the status register at powerup.  Wrong.  I was indead reading the status register and it's value was zero.  As soon as I wrote a WREN command (write enable) and read the status register I got back a value of two.

After that everything works fine.  Thanks for the time and sorry about the noise.

Bruce

Log in to post new comments.