Raw FRAM device (via SPI) - libi2c issue?
Thomas Doerfler (nt)
Thomas.Doerfler at imd-systems.de
Sun Mar 15 09:17:06 UTC 2009
-----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-----
More information about the users
mailing list