Raw FRAM device (via SPI) - libi2c issue?
Robert S. Grimes
rsg at alum.mit.edu
Fri Mar 13 22:49:44 UTC 2009
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://lists.rtems.org/pipermail/users/attachments/20090313/68f453d0/attachment.html>
More information about the users
mailing list