SPI Troubleshooting - Page 1
Forum section: electronics / beginners

author: Muffins
author_rank: Regular Contributor
timestamp: January 27, 2020, 09:37:00 am
content: Hi guys,I'm trying to get an Atmega328pb to interact with an FRAM chip. My problem is that I can't get a response from the FRAM.The SPI has been checked and seems to be working properly. I've added an ocsilloscope screenshot with the MISO shown in green (flatline).I am using this fram module:https://www.mikroe.com/fram-click,here is the datasheet for it:https://www.fujitsu.com/downloads/MICRO/fsa/pdf/products/memory/fram/MB85RS256A-DS501-00007-0v01-E.pdfI don't think this is a code problem but here is what I am up to:Code:// opcodes as defined in datasheetuint8_t writeOpcode = 0b00000010;uint8_t readOpcode = 0b00000011;uint8_t RDSR = 0b00000101;uint8_t WREN = 0b00000110;uint8_t WRDI = 0b00000100;//chip selectPORTE &= ~(1 << 2);// shift out opcodesshiftOut(WREN);shiftOut(RDSR);// shift out blank data to read responseshiftOut(0x00);//chip select offPORTE |= (1 << 2);With the function doing this.Code:void shiftOut(uint8_t shiftData){SPDR1 = shiftData;while(!(SPSR1 & (1 << SPIF1)));}So far as I understand, I need to send the fram and opcode and data depending on the instruction. The data doesn't matter when reading, it's just to shift into the avr register.I notice in the oscilloscope screenshot that there is a delay in between each 8 clock pulses since I am sending data 8 bits at a time. Could this be problem?

author: Renate
author_rank: Super Contributor
timestamp: January 27, 2020, 12:41:01 pm
content: You're using SPI mode 1, it should be mode 0.Your data is changing on the rising edge of clock.It should be changing on the falling edge of clock and sampling on the rising edge.Code:SPCR = 0b010100??; // ? = speed

author: Muffins
author_rank: Regular Contributor
timestamp: January 27, 2020, 01:54:43 pm
content: Thank you for looking through it. I'll add in the changes tomorrowHow did you insert code into your response?

author: Renate
author_rank: Super Contributor
timestamp: January 27, 2020, 02:02:27 pm
content: [co​de]Hello, I am code.[/co​de]

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 27, 2020, 10:41:02 pm
content: In your code you also don't need that WREN command.WREN & WRDI are only necessary when writing data - and note that you need to precedeeverywrite command with a WREN, not just once for multiple. The write latch automatically resets upon completion of a write.

author: Muffins
author_rank: Regular Contributor
timestamp: January 28, 2020, 08:28:04 am
content: Thanks guys, I got it

author: Muffins
author_rank: Regular Contributor
timestamp: January 28, 2020, 11:21:30 am
content: Just one last note if anyone lands on this page through a search. To get the FRAM working you need to turn chip select on and off for each command. This is not apparent from the datasheet and had me stuck for an hour or two.Example:Code:data+=1;PORTE &= ~(1 << 2); // chip select lowshiftOut(WREN);PORTE |= (1 << 2); // chip select high_delay_us(2);PORTE &= ~(1 << 2);shiftOut(write);shiftOut(addressHigherByte);shiftOut(addressLowerByte);shiftOut(data);PORTE |= (1 << 2);

author: HwAoRrDk
author_rank: Super Contributor
timestamp: January 28, 2020, 04:29:19 pm
content: Quote from: Muffins on January 28, 2020, 11:21:30 amWell... to be fair, not really. Chip select (CS) is mentioned in that Fujitsu datasheet in many places, and illustrated in all the timing diagrams. The pin description table even specifically says"CS has to be “L” before inputting op-code".It always pays to read the datasheet for a part thoroughly before using it. Half an hour studying the datasheet beforehand can save several hours of confusion later.

author: hermitengineer
author_rank: Regular Contributor
timestamp: January 29, 2020, 10:47:08 pm
content: To be more precise, CS must go low before inputting a command, and must be raised to end a command. Operations such as READ and WRITE can be optimized by holding CS low for multiple bytes read or written to contiguous memory.

author: mikerj
author_rank: Super Contributor
timestamp: January 30, 2020, 12:19:02 pm
content: Quote from: Muffins on January 28, 2020, 11:21:30 amThis isn't something specific to your FRAM device, pretty much all SPI peripherals work like this. Every timing diagram in the FRAM datasheet shows the required behaviour of the CS line.