MOD5213 SPI with 23LCV512 Chip

[treddick]

Hi folks,

Working with the above, no problem reading/writing the Mode Register, but cannot seem to read/write data. Using the Netburner QSPIInit() to access the chip as in the QSPI2Serial app.

I can view data to the chip with a storage scope; see addresses, etc., but no data returned from the chip during clocking.

If anyone has worked through this, would love to know how !

23LCV512 Datasheet: http://ww1.microchip.com/downloads/en/D ... 25157A.pdf

Clock phase and polarity seem correct.

Going to try attaching the file with what I have thus far.


Tom

[Chris Ruff]

I usually have to connect up the logic analyzer, slow the SPI way down, and - remember- that you have to drive the SPI with zeros for the chip to place bits for you to read back on your end.

You don't only send live bits, you send dead bits to get back data

Chris

[treddick]

The chip is a 23LCV512 and not 12.......

Yes, I tried pushing the data by clocking zeros into the serial in pin, and other bytes too.

I am running the clock slower. Using a clock rate of 20000 is fine with the dual channel storage scope - I can roll the display back and forth and count the cycles and see the data v.s. clock transitions.

Because I can read and write the Mode register in the chip but not store and read with a memory location, it leads me to think my logic is the problem - but I have run out of breakthroughs.

I think I will pull the chip from the socket and place the jumpers on the dev40 carrier to simply loop my data back and re-do some thinking.

At least the little marvel is consistent!

(The file I uploaded to the forum has one or two anomalies but that is because of my endless tinkering.)

Tom

[tod]

This may be off base but

Code: Select all

iprintf("RXBuffer[%d]:%x\r\n", i, RXBuffer[i]);

strikes me as suspect. (No this is not my rant on using iostreams) In my experience, I get more reliable results when trying to print a BYTE if I first

Code: Select all

static_cast<int>(RXBuffer[i])

[Chris Ruff]

You probably will eventually get this working using the dual channel scope, but..how can you see what is happening without the 3 lines: clock, out, and in all displayed?
I have a scope with 16 bits of digital input so it is easier for me to get these serial bugs working..

I am sure you already have done this, but you have to drive the clock for the quantity of transitions it takes to specify the address, operation, and move the byte- either out-where you set the bits based on your byte (the SPI driver does it) or you clock (e.g.)high bits for the chip to pull low or leave high and then get the byte value from the driver code.

If I were in your position and I could afford it- I would buy one of those USB-logic analyzers out there. I have been reading that some of them are really good and not too expensive.

Chris

[seulater]

If I were in your position and I could afford it- I would buy one of those USB-logic analyzers out there. I have been reading that some of them are really good and not too expensive.

Chris, I bought one of these @ $149 :

http://www.saleae.com/logic

It is a very good device. One of the best things i love about it is that when doing SPI, Or I2C it will not only show you the timing, but it will also show the values, so you dont have to sit there and count the data bits compared with the clock.

[Ridgeglider]

I've used devices from bitscope and LinkInstruments. Look for one with SPI and I2C protocol analyzers. There is a learning curve, but usually worthwhile.

[seulater]

treddick, just to make sure. Do you have a pullup resistor tied on the MISO line ?

[treddick]

$149 for an analyzer - can't beat that !

After fiddling with the QSPIInit( baud_rate-in_bps, xfer_size_in_bits ....) function call, I see that there is a half cycle clk delay (stretch during low time) after the 8th clk when using 8 for xfer_size_in_bits, and the same after the 16th clk when using 16 for xfer_size_in_bits.

I also put a 10K pull-up R on the /CS pin, and I can see a 650 ns glitch coinciding with the clk stretch mentioned above. Hmmmmm. That's enough for the chip to see /CS go high - ending the session probably - Spec sheet says /CS disable time Min: 25 ns

No pull-up on the MISO. Microchip AN1484 mentions pull-ups but not on the SO pin.

Tom

[dciliske]

Personally, I'd recommend either the LogicPort from Intronix (http://www.pctestinstruments.com/) or the OpenBench LogicSniffer (http://dangerousprototypes.com/open-logic-sniffer/) by Dangerous Prototypes. The LogicPort we have at work and I've used quite extensively. The OpenBench LogicSniffer I have at home for personal work.

The LogicPort is a 500MHz probe with 32 data channels each with 2k of buffer space (but always 2k, even if you use only 3 channels...). It also does sample compression, so on average it has enough space for ~128 bytes of sampling. It's got a pretty decent software component, though it does have a bit of a learning curve. It's $389, and is frankly the best scope you're going to find under $1,000 and maybe even $2,000.

The OpenLogicSniffer is 200MHz probe with 16 data channels (expandable to 32) with a variable buffer depth (16k@8ch, 8k@16ch, 4k@32ch). It's an opensource project based off of the Papillio One with the Xilinx Spartan3 250E. The software portion of the analyzer is a bit... clunky, but steadily improving. The board is $50 if you buy from SeedStudio (and can wait a month or so to ship from Shenzen) or $70 from Sparkfun.

One final comment with regards to the Salae Logic. It's a streamed analyzer with no buffering. The 24MHz sampling limit is due to USB 2.0 bandwidth. That also means that if there's bus latency or contention (other devices on the USB bus) you won't be able to sample at that rate. They do have the Logic16 which does have some buffering, but that's $300 and at that point spend the extra to get the LogicPort. That said, if you're willing to deal with a steep learning curve and put up with a couple quirks get the OpenBench LogicSniffer. If not, but you don't want to shell out for the LogicPort and 20MHz is enough the Salae Logic should be fine.

-Dan