Memory access between application task and driver using printk

[Gedare Bloom]

There appears to be problems in the code you copy-pasted, so it is
hard to say for sure what is going on in your actual code. See below
for a few notes.

On Mon, Nov 16, 2015 at 11:28 AM, Inderjit Singh
<inderjit.singh at aacmicrotec.com> wrote:
> Hi,
>
> I have a strange behaviour regarding memory access between my user
> application and the driver i have developed I'd like to get some
> clarification on.
>
> The development is all used on or1k arch.
>
> On the application side, I have a buffer declared as:
> #define PACKET_SIZE 256
> volatile uint8_t __attribute__ ((aligned (32))) buf_rx[256];
>
> Then I use the posix api function read to access the data I want to get from
> my driver as following:
>
> rtems_task test_task_rx(rtems_task_argument arg)
> {
>   info_rx_t *info_rx;
>   info_rx = (info_rx_t*)arg;
>
>   while(true){
>     memset((uint8_t*)buf_rx, 0xaa, SPWN_TS_PACKET_SIZE);
>     printk("Waiting for packet... at 0x%08X\r\n", buf_rx);
>     size = read(info_rx->fd, (uint8_t*)&buf_rx[0], PACKET_SIZE);
>
Check size. If it is 1, then the behavior you get may be expected, since...

>     if(size > 0) {
>       printk("Packet received with size <%d>", buf_rx[0], size);
>       /* Print info */
>       if(spwn_info_rx->show_header == true) {
>         for(i = 0;i < info_rx->packet_len;i++) {
>           printk("%02X ", buf_rx[1]);
array index should be i, not 1.

>           if((i%16) == 0) {
>             printk("\r\n");
>           }
>          }
>          printk("\b>\r\n");
>        }
>      }
>    }
>  }
>
> From my driver side I'm just iterating the buffer values by one to see the
> update, i.e: First time it starts with [01 02 03..." and next time it starts
> with [02 03 04...]. The strange thing is the first time I get a 'packet' it
> looks great. But the second time, It shows a bunch of 0xaa values (from
> memset before reading):
>
You should also validate behavior within the driver 'read' function. I
don't know what you mean by "iterating the buffer values" and if your
driver is accessing the buf_rx array that is probably not a great
design choice. I don't quite understand what your driver does to help
you debug this issue.

> Packet received with size <256> header @ 0004D960: AA
> AA AA AA ...
> 11 12 13 ...
> AA AA AA ...
> ...
>
> But looking at the memory area in gdb I see the correct values:
> 01 02 03 ...
> 11 12 13 ...
> 21 22 23 ...
> ...
>
> Removing memset call only shows that the buffer is the same after first call
> to read. I can't figure out why. Does anyone have a explanation. Any help
> would be appreciated.
>
> Thanks,
> Inderjit
>
>
>
>
>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel