Raw FRAM device (via SPI) - libi2c issue?
Thomas Doerfler
Thomas.Doerfler at imd-systems.de
Sat Mar 14 08:45:08 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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.4.3 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJu26SwHyg4bDtfjQRAn+MAJ9qSwi800LomWU/x6QAsx+X2C1siQCfR6mD
q07DDQfVJM/xLDwlNF/ib34=
=kv+A
-----END PGP SIGNATURE-----
More information about the users
mailing list