Memory access between application task and driver using printk

[Inderjit Singh]

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);

    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]);
          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):

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20151116/188fc2fe/attachment-0001.html>