# SPI Flash Memory with ATMega1284

I have connected a SST26VF064B 8Mb flash memory IC to an ATMeag1284 as shown in the following diagram. My plan is to talk to it using SPI.

Note that all capacitors in the schema are 100nF.

When reading the JEDEC ID I do not get the expected values. First I set the SS line to low, then send the command 0x9F, then read 3 bytes (by sending 0xff dummy data) and finally pulling the SS line to high again. The datasheet tells me the ID should be 0xBF 0x26 0x43 for the specific device I have (see page 24). I suspect something is wrong with my SPI connection. However, the Oscilloscope reading of the SCK, MOSI and SS line look as expected. Also my code correctly decodes the pattern on the MISO line as 0x7c 0x20 0x6f. You can find the Oscilloscope readings below.

Furthermore I tried to read the status and configuration with the 0x05 respectively 0x35 commands. However, both of them return just 0x00. According to the datasheet at least the configuration register should contain a 1 in factory settings at the 3rd bit.

The following code is run on the ATMega1284:

#define F_CPU 8000000UL

#include <avr/io.h>
#include <util/delay.h>

void setSSLow() {
// Drive SS to low
PORTB &= ~(1<<PINB4);
}

void setSSHigh() {
// Set SS to high
PORTB |= (1<<PINB4);
}

void SPI_MasterInit(void)
{
// Set SS, MOSI and SCK output, all others input
DDRB = (1<<PINB4)|(1<<PINB5)|(1<<PINB7);
setSSHigh();

// Enable SPI, Master, set clock rate fck/128
// Sample on rising edge, output on falling
SPCR = (1<<SPE)|(1<<MSTR)|(1<<SPR0)|(1<<SPR1)|(0<<CPHA)|(0<<CPOL);
}

char SPI_MasterTransmit(char cData)
{
// Start transmission
SPDR = cData;
// Wait for transmission complete
while(!(SPSR & (1<<SPIF))) ;

}

char buffer[3];

int main(void)
{
SPI_MasterInit();

// Send 'Read JEDEC ID' command
setSSLow();
char status = SPI_MasterTransmit(0x9f);

// Get data
for (int i=0; i<3; i++) {
char data = SPI_MasterTransmit(0xff);
buffer[i] = data;
}
setSSHigh();

_delay_ms(1000);

while (1) {
// Do nothing
}
}


SCK and SS

SCK and MOSI

SCK and MISO

I'm now at a point where I can't think of anything else to do to try and debug this issue. I would be very helpful to any help you can provide! This is the first time I'm using SPI and it is very hard for me to debug hardware as I have a software background.

UPDATE 1

I double checked everything today and everything looks correct to me. However, I still get the same output when reading the JEDEC ID. As mentioned in the comments below, it is a repeating byte sequence:

7c 20 6f 84 0d f0 81 be 10 37 c2 06 f8 40 df 08 1b e1 03


As I had the same chip in the 16 pin housing I quickly soldered a breakout board together and replaced the chip. Surprisingly I get exactly the same behavior. I definitely think there's something wrong the way I do it, but I don't yet see how...

UPDATE 2

As I already mentioned in the comments, I managed to get the Memory chip working in with an Arduino. So I investigated further. I loaded the code I used on the ATMega1284 directly on the Arduino. And guess what: It worked out of the box. So there must be something wrong with the ATMega I'm using. Additionally I quickly wrote a software SPI implementation using other pins then the ones used by the hardware SPI. And this works as well. I'll try to get my hands on another ATMega1284 and try with that one. My guess is that I broke something in the ATMega1284...

UPDATE 3

By accident I just managed to communicate to the SSTV26 using hardware SPI on the ATMega1284. I still had cables connected to SS, MOSI and SCK that were not connecting to anything else. When I touch these cables, the communication works. When I don't touch them it does not work. I suspect there's something floating. I don't have the tools at hand at the moment.

• In a nutshell: your problem is that the flash chip is returning unexpected data? Oct 10 '18 at 16:07
• Correct. In a repeatable way. I.e. the returned data is the same always. Oct 10 '18 at 16:14
• Nothing jumps out at me as wrong. Your pinout checks out, and the o-scope shots look good. The expected data and actual data don't seem to have any relationship (like, shifted by one bit, or LSB instead of MSB). Check that you have the flash chip you think you have, if you haven't already. Oct 10 '18 at 19:48
• Thanks for having a look at it. I appreciate it very much! That's very strange. I double checked that I actually have the part I think I have. Everything matches the datasheet. Further investigation showed that the sequence that is returned by the chip is a 18 byte sequence starting with the bytes 0x7c 0x20 0x6f (as mentioned above). If I just continue reading, it repeats these 18 bytes. I'll double check everything once more tomorrow. If I still have the same problem I'll reach out to microchip. Oct 10 '18 at 21:16
• I would love to hear an update if you figure it out. Oct 10 '18 at 22:54

The underlying problem had nothing to do with software or the chips not working properly. I was using 20cm ribbon cables to connect the ATMega1284 to the external board containing the memory chip. Separating the cables and spreading them a little bit solved the issues. I probably had crosstalk between the signals. The o-scope measurements from the initial post were taken very close to the ATMega1284, where the effect was most probably not visible. To make sure this doesn't happen again in my development setup I shortened the cables to about 4cm. I have not had any further problems so far.

Thank you all for the time you took to have a look at it! I really appreciate it!

Too long for a comment, have you tried sending a Reset command?

5.2 Reset-Enable (RSTEN) and Reset (RST) The Reset operation is used as a system (software) reset that puts the device in normal operating Ready mode. This operation consists of two commands: Reset-Enable (RSTEN) followed by Reset (RST). To reset the SST26VF064B/064BA, the host drives CE# low, sends the Reset-Enable command (66H), and drives CE# high. Next, the host drives CE# low again, sends the Reset command (99H), and drives CE# high, see Figure 5-1.

The Reset operation requires the Reset-Enable command followed by the Reset command. Any command other than the Reset command after the Reset-Enable command will disable the Reset-Enable.

Once the Reset-Enable and Reset commands are successfully executed, the device returns to normal operation Read mode and then does the following: resets the protocol to SPI mode, resets the burst length to 8 Bytes, clears all the bits, except for bit 4 (WPLD) and bit 5 (SEC), in the Status register to their default states, and clears bit 1 (IOC) in the configuration register to its default state. A device reset during an active Program or Erase operation aborts the operation, which can cause the data of the targeted address range to be corrupted or lost. Depending on the prior operation, the reset timing may vary. Recovery from a Write operation requires more latency time than recovery from other operations. See Table 8-2 on page 49 for Reset timing parameters

• While trying things is not a bad idea, this should not be needed, especially to merely read the chip ID register. Oct 11 '18 at 17:51
• It would be nice to try some command that modifies the state of the device in an obvious way, to see if the device is recognizing commands at all. Unfortunately, reset won't make any obvious modification. Oct 11 '18 at 23:03
• Changing to quad SPI might work. The host wouldn't recognize the resulting traffic, but monitoring on the o-scope would show if traffic showed up on the extra IOs. Oct 11 '18 at 23:03
• I tried to write something to a random memory address and reading again. I do not get the bytes I wrote back. I'll try that and see if I can get additional data on the other data lines once switched. Oct 12 '18 at 13:53
• I figured out that the Memory IC works as expected. I connected it today to an Arduino and used the SPI library to talk to the chip. It worked within the first 20 minutes. Next I uploaded the code I use on the ATMega to the Arduino. And here is where it gets strange. This works too! I suspect now that the ATMega is somehow damaged. I'll try to get my hands on another chip and see if that works. Oct 15 '18 at 19:43