<HTML><BODY>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:<br>
<br>
<blockquote> /*<br>
* send "page program" command and address<br>
*/<br>
#ifdef DEBUG_FRAM<br>
printk(" Write %d bytes to %u\n", cnt, off);<br>
#endif<br>
if (rc == RTEMS_SUCCESSFUL) {<br>
cmdbuf[0] = FRAM_CMD_WRITE;<br>
cmdbuf[1] = (off >> 8) & 0xff;<br>
cmdbuf[2] = (off >> 0) & 0xff;<br>
ret_cnt = rtems_libi2c_write_bytes(minor,cmdbuf,3);<br>
if (ret_cnt < 0) {<br>
rc = -ret_cnt;<br>
}<br>
}<br>
<br>
/*<br>
* send write data<br>
*/<br>
if (rc == RTEMS_SUCCESSFUL) {<br>
#ifdef DEBUG_FRAM<br>
printk(" Calling rtems_libi2c_write_bytes(%d,0x%p,%d)\n", minor, buf, cnt);<br>
#endif<br>
ret_cnt = rtems_libi2c_write_bytes(minor,buf,cnt);<br>
#ifdef DEBUG_FRAM<br>
printk(" Returned %d\n", ret_cnt);<br>
#endif<br>
if (ret_cnt < 0) {<br>
rc = -ret_cnt;<br>
} else {<br>
bytes_sent = cnt;<br>
}<br>
}<br>
</blockquote><br>
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:<br>
<br>
<blockquote>Okay, let's try to write...<br>
fram write<br>
Write 32 bytes to 0<br>
Calling rtems_libi2c_write_bytes(83968,0x57F6B4,32)<br>
Returned 27<br>
write returned 32<br>
fram write<br>
Write 12 bytes to 32<br>
Calling rtems_libi2c_write_bytes(83968,0x57F6B4,12)<br>
Returned 12<br>
write returned 12<br>
And now, read...<br>
fram read<br>
Read 64 bytes from 0 - rc: 0<br>
read returned 49<br>
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 |0123456789abcdef|<br>
41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f |A9876543210Hello|<br>
64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
</blockquote><br>
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?<br>
<br>
Thanks,<br>
-Bob<br>
<br>
<br>
---- Original message ----<br>
<blockquote style="border-left: 2px solid rgb(0, 0, 255); padding-left: 5px; margin-left: 5px;"><br>
<b>Date:</b> Fri, 13 Mar 2009 18:29:22 -0400 (EDT)<br>
<b>From:</b> "Robert S. Grimes" <rsg@alum.mit.edu><br>
<b>Subject:</b> Raw FRAM device (via SPI)<br>
<b>To:</b> RTEMS <rtems-users@rtems.org><br>
<br>
<xhtm><xbod>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...<br>
<br>
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:<br>
<br>
fd = open("/dev/spi2.fram", O_RDWR);<br>
printf("open returned %d\n", fd);<br>
if (fd >= 0) {<br>
<br>
printf("\n*** Simple FRAM Test *** \n\n");<br>
printf("First, let's try to read pre-existing contents\n");<br>
char buffer[64];<br>
int num0 = read(fd, buffer, 64);<br>
printf("read returned %d\n", num0);<br>
rtems_print_buffer((unsigned char*)buffer, 64);<br>
<br>
printf("\nOkay, let's try to write...\n");<br>
memset(buffer, 0, 64);<br>
strcpy(buffer, "0123456789abcdefFEDCBA9876543210");<br>
lseek(fd, 0, SEEK_SET);<br>
int num1 = write(fd, buffer, strlen(buffer));<br>
printf("write returned %d\n", num1);<br>
strcpy(buffer, "Hello world.");<br>
int num2 = write(fd, buffer, strlen(buffer));<br>
printf("write returned %d\n", num2);<br>
<br>
char rbuffer[64];<br>
lseek(fd, 0, SEEK_SET);<br>
memset(rbuffer, 0, 64);<br>
printf("And now, read...\n");<br>
int num3 = read(fd, rbuffer, 64);<br>
printf("read returned %d\n", num3);<br>
rtems_print_buffer((unsigned char*)rbuffer, 64);<br>
close(fd);<br>
}<br>
<br>
This is the results the first time it is run:<br>
<br>
<blockquote>Trying to open fram...<br>
open returned 4<br>
<br>
<br>
*** Simple FRAM Test *** <br>
<br>
First, let's try to read pre-existing contents<br>
read returned 49<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
00 aa 55 55 aa aa 55 55 aa aa 55 55 aa aa 55 55 |..UU..UU..UU..UU|<br>
<br>
Okay, let's try to write...<br>
write returned 32<br>
write returned 12<br>
And now, read...<br>
read returned 49<br>
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 |0123456789abcdef|<br>
41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f |A9876543210Hello|<br>
64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
</blockquote><br>
Here is the second run, after powering off:<br>
<br>
<blockquote>Trying to open fram...<br>
open returned 4<br>
<br>
*** Simple FRAM Test *** <br>
<br>
First, let's try to read pre-existing contents<br>
read returned 49<br>
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 |0123456789abcdef|<br>
41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f |A9876543210Hello|<br>
64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|<br>
00 aa 55 55 aa aa 55 55 aa aa 55 55 aa aa 55 55 |..UU..UU..UU..UU|<br>
<br>
Okay, let's try to write...<br>
write returned 32<br>
write returned 12<br>
And now, read...<br>
read returned 49<br>
30 31 32 33 34 35 36 37 38 39 61 62 63 64 65 66 |0123456789abcdef|<br>
41 39 38 37 36 35 34 33 32 31 30 48 65 6c 6c 6f |A9876543210Hello|<br>
64 2e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |d...............|<br>
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|<br>
</blockquote>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?<br>
<br>
Thanks, <br>
-Bob<br>
<br>
<br>
<br>
<br>
<div class="mirapoint-signature" target="_blank"><br>
<pre><br>
Robert S. Grimes<br>
<br>
RSG Associates<br>
Embedded Systems and Software Development<br>
for Military, Aerospace, Industry - and beyond!<br>
617.697.8579<br>
www.rsgassoc.com<br>
<br>
</pre><br>
</div></xbod></xhtm><br>
>________________
>_______________________________________________
>rtems-users mailing list
>rtems-users@rtems.com
>http://rtems.rtems.org/mailman/listinfo/rtems-users
</blockquote>
<DIV class=mirapoint-signature>
<PRE>
Robert S. Grimes
RSG Associates
Embedded Systems and Software Development
for Military, Aerospace, Industry - and beyond!
617.697.8579
www.rsgassoc.com
</PRE>
</DIV>
</BODY></HTML>