I'm trying to get my Uno communicating with an SRAM chip (Microchip 23LC512) via SPI.As a simple verification, I write several bytes of data then go back and read them, and print it on the serial monitor. But, when I run my code I get this:

Memory addresses are 16 bit, shown in hex; values are in binary. In this case I wrote B10101010 to each memory address.I can't find any consistent pattern--sometimes several bytes in a row are correct, others none. Here it looks like it's wrapping values from the back to the front?Any help is very much appreciated!

180 views.. who has the answers?I have checked all the SPI modes, and the chip is rated for 20MHz.The 23LC512 is functionally equivalent to the more popular 23LC256.. can anyone replicate the problem?Thanks all

How do you have the unused pin configured? Mine is tied to ground, though I get different results with it tied to Vcc. The datasheet doesn't specify which is best, though it advises not to leave it floating.

I'll try rewiring mine with shorter jumpers.. maybe it's noise or there's too much capacitance on the line? I'm going to try observing the SCK signal on my o-scope later, some devices are sensitive to long rise-times. On a preliminary search, I couldn't find any free samples for Schmitt triggers..

As for tracking data, I'm vaguely thinking of using it as a type of data buffer between MCUs, so that one isn't stuck waiting for the other to free up. Effectively it'd be structured as a stack, with a header byte saying how many bytes and of what type it should be expecting.

How do you have the unused pin configured? Mine is tied to ground, though I get different results with it tied to Vcc. The datasheet doesn't specify which is best, though it advises not to leave it floating.

I'll try rewiring mine with shorter jumpers.. maybe it's noise or there's too much capacitance on the line? I'm going to try observing the SCK signal on my o-scope later, some devices are sensitive to long rise-times. On a preliminary search, I couldn't find any free samples for Schmitt triggers..

I also got better results when I slowed down my serial port - I went from 115200 down to 38600 and didn't seem to find a fail

As for tracking data, I'm vaguely thinking of using it as a type of data buffer between MCUs, so that one isn't stuck waiting for the other to free up. Effectively it'd be structured as a stack, with a header byte saying how many bytes and of what type it should be expecting.

Actually, I think it might be better to write 64K of 0xAA and then go back an read all 64K to find a fail - can't trust the serial output

You're using the hardware CS on the Uno? Won't that go high in the middle of a command, since we call spiTransfer multiple times in what the SRAM considers one command?

Honestly, I'm a newbie, I got my first UNO this Feb (2013) and all I did was to copy and paste your code and figured since you were having a problem I'd see what the internet had to say. Well, this is what I came up with. Something is still wrong because I don't understand this comment (what did you do to correct it?):

Have you tried tying the HOLD pin to VCC? A similar issue was raised in a thread for the Microchip 23k256 sram chips. I also noticed some errors due to my IC socket not being 100% seated on my breadboard (it can get loose). I used the wiring diagram from the referenced thread on a Due with a clock divider of 0 and received the right output.

every thing works fine with even shorter wires (don't use jumper wires with SRAM, with EEPROM OK, at least for me)64K bytes written in 1.2 sec (in BYTE mode)64K writes and 64K reads 100 times with different data each time and no fails64K reads and writes in SEQUENTIAL mode:write time= 128 mSec read time= 128 mSecno fails - I claim done