• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 616 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Using McBSP to interface to FRAM in SPI mode

Chris Shaw, Melbourne
Prodigy 210 points

Hi,

our custom board has an FRAM device (FM25L16) connected to a C5502 via McBSP #1. The FRAM demands an SPI protocol and the the pins are connected as suggested in the McBSP user guide (nCS to FSX, SO to DR, SI to DX, SCK to CLKX) and I can make the FRAM (slave) work as expected.

The problem arises with the SPI message protocol demanded by the FRAM. With the given SPI configuration I need to write an 8-bit Write Enable opcode followed by a 32-bit Write message to set each byte of data in the FRAM. The rising edge of nCS clears the write enable latch and the next write operation needs to set this flag again.

This sequence means that the write time for a kilobyte of data is much longer than ideal and does not meet our requirements.

The FRAM allows multiple bytes to be written in a single operation by holding the nCS low and continuing to drive the clock and data lines - i.e. by effectively producing a word of data longer than 32-bits.  Thus in theory a kilobyte of data could be written in 1028 (8-bit Write Enable, 8-bit Write opcode, 16-bit start address, 1024-bytes data) bytes at 18MHz. Instead we're looking at 40-bits per byte plus overhead.

This doesn't seem possible with the McBSP operating in SPI mode however. I cannot see a way of driving the nCS line longer than 32-bits (accomplished by using a XWDLEN1 of 32-bits). Is it possible to do this somehow, or am I limited in how I can use the FRAM?

One alternative consideration would be to connect the nCS line to a GPIO line instead and drive in software, but I think this would prove impossible in practice to sync the start of the frame with the data Tx event.

Any help welcomed.

Chris.

  • 0
    TI__Expert 8065 points

    Chris,

     

    You are correct. In SPI mode (=clock stop mode), CS has to be toggled at every word. You can't hold CS low for more than a word. I am not familiar with the FRAM interface but do you think "tie CS pin to GND" will work?

     

    Regards,

    Peter Chung

     

  • 0 in reply to Peter Chung
    Prodigy 210 points

    Hmmmm. Possible. Seems a drastic solution. I think the FRAM would dislike never seeing a rising edge on the nCS - this is used to signify the end of a write operation which can be as many clock cycles as you require. Without the nCS rising edge, this operation would effectively be unterminated.

    May be though that tieing it to a GPIO output line would do the trick - let the McBSP drive the clock and data pin and hold nCS low in s/w until write operations complete.

    If there are no other solutions then I think we'll try this.

    Thanks.

    Chris

  • 0 in reply to Chris Shaw, Melbourne
    TI__Expert 8065 points

    Chris,

    I have seen "Connecting CS to GND" many times in various applications for SPI interface. If the FRAM interface counts the number of clocks to determine the end of a word, the it should work. If the FRAM interface relies on the CS signal to do so, then it won't work. Then, you may want to try a GPIO pin but it is tricky. 

     

    Regards,

    Peter Chung

     

  • 0 in reply to Peter Chung
    Prodigy 210 points

    The FRAM explicitly states that the CS signal "must go inactive (high) after an operation is complete and before a new op-code can be issued. There is one valid op-code only per active chip select."

    The GPIO pin option sounds simple to me; the port is operated as per usual, but with the addition of a manual operation before and after to take CS low then high. I think the sync'ing of the CS to clock and data is not needed, since the CS just means 'start listening for clock'. Will try today and let you know how we get on.

    If I've not thought of something with doing it this way, let me know.

    Chris

  • 0 in reply to Chris Shaw, Melbourne
    TI__Expert 8065 points

    Chris,

    If the FRAM has to see "de-asserted CS" at every word, yes, "tie CS to GND" wouldn't work. 

    Fro GPIO option, only down side of using a GPIO pin would be that CPU has to be involved at every word transfer. If it is not a problem in your system, it should work. 

    Good luck!

     

    Regards,

    Peter Chung

     

  • 0 in reply to Peter Chung
    Prodigy 210 points

    To close the issue, we have done as we were going to and connected the nCS line to a GPIO line. This seems to work well; the write speed for 1k of data (512 16-bit words) has increased by a factor of 15 and write verification proves it still works as well.

    Thanks for your input.

    Chris