[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Raw FRAM device (via SPI) - libi2c issue?



  Okay, more detail here.  I added some debug output
  in my fram driver code, and found where the five
  bytes are lost.  Here is the snippet from the fram
  write routine:

      /*
       * send "page program" command and address
       */
    #ifdef DEBUG_FRAM
      printk("    Write %d bytes to %u\n", cnt, off);
    #endif
      if (rc == RTEMS_SUCCESSFUL) {
        cmdbuf[0] = FRAM_CMD_WRITE;
        cmdbuf[1] = (off >> 8) & 0xff;
        cmdbuf[2] = (off >>  0) & 0xff;
        ret_cnt =
    rtems_libi2c_write_bytes(minor,cmdbuf,3);
        if (ret_cnt < 0) {
          rc = -ret_cnt;
        }
      }

      /*
       * send write data
       */
      if (rc == RTEMS_SUCCESSFUL) {
    #ifdef DEBUG_FRAM
        printk("      Calling
    rtems_libi2c_write_bytes(%d,0x%p,%d)\n", minor,
    buf, cnt);
    #endif
        ret_cnt =
    rtems_libi2c_write_bytes(minor,buf,cnt);
    #ifdef DEBUG_FRAM
        printk("        Returned %d\n", ret_cnt);
    #endif
        if (ret_cnt < 0) {
          rc = -ret_cnt;
        } else {
          bytes_sent = cnt;
        }
      }

  For those who are unfamiliar with fram, the first
  call to rtems_libi2c_write_bytes sends a write
  opcode and a two-byte offset, while the second sends
  the data to be written.  Anyway, here is the output:

    Okay, let's try to write...
      fram write
        Write 32 bytes to 0
          Calling
    rtems_libi2c_write_bytes(83968,0x57F6B4,32)
            Returned 27
    write returned 32
      fram write
        Write 12 bytes to 32
          Calling
    rtems_libi2c_write_bytes(83968,0x57F6B4,12)
            Returned 12
    write returned 12
    And now, read...
      fram read
        Read 64 bytes from 0 - rc: 0
    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
    |................|

  So why does rtems_libi2c_write_bytes return only 27
  when I send it 32, and why does it trash the five
  bytes after the first 16?  Seems to be a libi2c
  issue?

  Thanks,
  -Bob

  ---- Original message ----

    Date: Fri, 13 Mar 2009 18:29:22 -0400 (EDT)
    From: "Robert S. Grimes" <rsg at alum.mit.edu>
    Subject: Raw FRAM device (via SPI)
    To: RTEMS <rtems-users at rtems.org>

    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

    >________________
    >_______________________________________________
    >rtems-users mailing list >rtems-users at rtems.com
    >http://rtems.rtems.org/mailman/listinfo/rtems-users

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://rtems.rtems.org/pipermail/rtems-users/attachments/20090313/68f453d0/attachment.html