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

Raw FRAM device (via SPI) - libi2c issue?



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert,

just a guess: maybe you intermix the number of raw bytes sent to the
device and the number of DATA bytes transferred. I assume you need to
send special instructions to tell the FRAM to write from a certain
location. Is this sequence exactly 5 byte long? And do you somewhere
build a buffer of 16 bytes?

Thomas.

rsgrimes at rcn.com schrieb:
> Doh!  I missed that, and of course, your analysis is correct. So, why does libi2c dump 5 bytes after every 16?
> 
> Is it me, or are we missing something?
> 
> 
> Sent from my Verizon Wireless BlackBerry
> 
> -----Original Message-----
> From: Thomas Doerfler <Thomas.Doerfler at imd-systems.de>
> 
> Date: Sat, 14 Mar 2009 09:45:08 
> To: <rsg at alum.mit.edu>
> Cc: RTEMS<rtems-users at rtems.org>
> Subject: Re: Raw FRAM device (via SPI) - libi2c issue?
> 
> 
> Robert,
> 
> just an additional question:
> 
> Why does "read" only return "49"? By the way, this is 64 - (3*5) ???
> 
> Seems, that your problem is not only related to the write function?
> 
> good hunting,
> 
> Thomas.
> 
> Robert S. Grimes wrote:
>> 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
> 
> 
> 
>> ------------------------------------------------------------------------
> 
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
> 

- --
- --------------------------------------------
IMD Ingenieurbuero fuer Microcomputertechnik
Thomas Doerfler           Herbststrasse 8
D-82178 Puchheim          Germany
email:    Thomas.Doerfler at imd-systems.de
PGP public key available at:
     http://www.imd-systems.de/pgpkey_en.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJvMeQwHyg4bDtfjQRArQOAJsEl8kBRIHrO/w6dr2Row/Y/Nf1TwCeI2p5
pYmD8hb8EzNpOgBxZ/mCn2o=
=eFcB
-----END PGP SIGNATURE-----