Author Topic: SPI Troubleshooting  (Read 1532 times)

0 Members and 1 Guest are viewing this topic.

Offline MuffinsTopic starter

  • Regular Contributor
  • *
  • Posts: 60
  • Country: gb
SPI Troubleshooting
« on: January 27, 2020, 09:37:00 am »
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.pdf

I don't think this is a code problem but here is what I am up to:
Code: [Select]
                              
// opcodes as defined in datasheet
uint8_t writeOpcode = 0b00000010;
uint8_t readOpcode = 0b00000011;
uint8_t RDSR = 0b00000101;
uint8_t WREN = 0b00000110;
uint8_t WRDI = 0b00000100;



//chip select
PORTE &= ~(1 << 2);

// shift out opcodes
shiftOut(WREN);
shiftOut(RDSR);
// shift out blank data to read response
shiftOut(0x00);

//chip select off
PORTE |= (1 << 2);
With the function doing this.
Code: [Select]
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?
« Last Edit: January 28, 2020, 08:26:06 am by Muffins »
 

Offline Renate

  • Super Contributor
  • ***
  • Posts: 1460
  • Country: us
Re: SPI Troubleshooting
« Reply #1 on: January 27, 2020, 12:41:01 pm »
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: [Select]
SPCR = 0b010100??; // ? = speed
 
The following users thanked this post: Muffins

Offline MuffinsTopic starter

  • Regular Contributor
  • *
  • Posts: 60
  • Country: gb
Re: SPI Troubleshooting
« Reply #2 on: January 27, 2020, 01:54:43 pm »
Thank you for looking through it. I'll add in the changes tomorrow :-+

How did you insert code into your response?
 

Offline Renate

  • Super Contributor
  • ***
  • Posts: 1460
  • Country: us
Re: SPI Troubleshooting
« Reply #3 on: January 27, 2020, 02:02:27 pm »
[co​de]Hello, I am code.[/co​de]
« Last Edit: January 27, 2020, 02:05:34 pm by Renate »
 
The following users thanked this post: Muffins

Offline HwAoRrDk

  • Super Contributor
  • ***
  • Posts: 1607
  • Country: gb
Re: SPI Troubleshooting
« Reply #4 on: January 27, 2020, 10:41:02 pm »
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 precede every write command with a WREN, not just once for multiple. The write latch automatically resets upon completion of a write.
 
The following users thanked this post: Muffins

Offline MuffinsTopic starter

  • Regular Contributor
  • *
  • Posts: 60
  • Country: gb
Re: SPI Troubleshooting
« Reply #5 on: January 28, 2020, 08:28:04 am »
Thanks guys, I got it  ;D

 

Offline MuffinsTopic starter

  • Regular Contributor
  • *
  • Posts: 60
  • Country: gb
Re: SPI Troubleshooting
« Reply #6 on: January 28, 2020, 11:21:30 am »
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: [Select]
				data+=1;
PORTE &= ~(1 << 2); // chip select low
shiftOut(WREN);
PORTE |= (1 << 2); // chip select high
_delay_us(2);

PORTE &= ~(1 << 2);
shiftOut(write);
shiftOut(addressHigherByte);
shiftOut(addressLowerByte);
shiftOut(data);
PORTE |= (1 << 2);
 

Offline HwAoRrDk

  • Super Contributor
  • ***
  • Posts: 1607
  • Country: gb
Re: SPI Troubleshooting
« Reply #7 on: January 28, 2020, 04:29:19 pm »
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.

Well... 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. :)
 

Offline hermitengineer

  • Regular Contributor
  • *
  • Posts: 80
  • Country: us
Re: SPI Troubleshooting
« Reply #8 on: January 29, 2020, 10:47:08 pm »
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.
 

Online mikerj

  • Super Contributor
  • ***
  • Posts: 3383
  • Country: gb
Re: SPI Troubleshooting
« Reply #9 on: January 30, 2020, 12:19:02 pm »
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.

This 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.
« Last Edit: January 30, 2020, 12:21:07 pm by mikerj »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf