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.si...@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...@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@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
