Raw FRAM device (via SPI)

[Robert S. Grimes]

  I have a 32 kilobyte FRAM device on my board that I
  would like to use.  It is interfaced to the (Virtex)
  processor via SPI.  I've been using the SPI driver
  for A/D and D/A converters, as well as for an SD
  card, pretty much with no trouble.  But now, the
  FRAM is a bit different...

  Because of the small size and my intended usage
  (simple byte-stream logging), I had intended to use
  it as a simple chunk of memory - in other words, no
  file system.  Here is my test code:

    fd = open("/dev/spi2.fram", O_RDWR);
    printf("open returned %d\n", fd);
    if (fd >= 0) {

      printf("\n*** Simple FRAM Test *** \n\n");
      printf("First, let's try to read pre-existing
  contents\n");
      char buffer[64];
      int num0 = read(fd, buffer, 64);
      printf("read returned %d\n", num0);
      rtems_print_buffer((unsigned char*)buffer, 64);

      printf("\nOkay, let's try to write...\n");
      memset(buffer, 0, 64);
      strcpy(buffer,
  "0123456789abcdefFEDCBA9876543210");
      lseek(fd, 0, SEEK_SET);
      int num1 = write(fd, buffer, strlen(buffer));
      printf("write returned %d\n", num1);
      strcpy(buffer, "Hello world.");
      int num2 = write(fd, buffer, strlen(buffer));
      printf("write returned %d\n", num2);

      char rbuffer[64];
      lseek(fd, 0, SEEK_SET);
      memset(rbuffer, 0, 64);
      printf("And now, read...\n");
      int num3 = read(fd, rbuffer, 64);
      printf("read returned %d\n", num3);
      rtems_print_buffer((unsigned char*)rbuffer, 64);
      close(fd);
    }

  This is the results the first time it is run:

    Trying to open fram...
    open returned 4

    *** Simple FRAM Test ***

    First, let's try to read pre-existing contents
    read returned 49
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|
    00 aa 55 55 aa aa 55 55 aa aa 55 55 aa aa 55 55
    |..UU..UU..UU..UU|

    Okay, let's try to write...
    write returned 32
    write returned 12
    And now, read...
    read returned 49
    30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
    |0123456789abcdef|
    41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f
    |A9876543210Hello|
    64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |d...............|
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|

  Here is the second run, after powering off:

    Trying to open fram...
    open returned 4

    *** Simple FRAM Test ***

    First, let's try to read pre-existing contents
    read returned 49
    30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
    |0123456789abcdef|
    41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f
    |A9876543210Hello|
    64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |d...............|
    00 aa 55 55 aa aa 55 55 aa aa 55 55 aa aa 55 55
    |..UU..UU..UU..UU|

    Okay, let's try to write...
    write returned 32
    write returned 12
    And now, read...
    read returned 49
    30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66
    |0123456789abcdef|
    41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f
    |A9876543210Hello|
    64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |d...............|
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    |................|

  Notice the problem(s)?  It seems as though after
  writing 16 bytes, the next five are discarded.  This
  seems to continue going forward.  Any ideas?

  Thanks,
  -Bob

Robert S. Grimes

RSG Associates
Embedded Systems and Software Development
for Military, Aerospace, Industry - and beyond!
617.697.8579
www.rsgassoc.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20090313/fc17f5ea/attachment.html>