I'm working on a customised design base on zc706-ad9265. I've posted a topic Framing data using libiio buffer with ADI dmac driver.
Thanks to larsc, now our team can receive and process a 24MB/s data stream!
But our team now encounter a new problem, here is a detailed description of the problem:
- The data into the axi_dmac is in a packet form, which composed of a 0x55AA_AA55 frame head + 1024x32bit IQ data;
- The hdl and linux driver is a newest version until now, downloaded from github;
- The tx flow is:
1) call create_iio_buffer(), with a (1024+1)x32bit x 10 depth (== 10 frame length);
2) set start_tx reg ----> set the DMAC m_axis_resetn to reset the DMAC fifo ----> wait for a period, the tx stream then load into the DMAC ----> iio_buffer filled and generate a interrupt ----> copy data from buffer and do processing ----> stop tx ----> destroy_iio_buffer -----> back to the loop start.
4. When data rate is 2MB/s, with a lot of test on start-receive-stop loop, the frame head 0x55AA_AA55 was always in the right postion in the iio_buffer;
5. When data rate >= 3MB, frame head may( not always, E.G. 1 occurs in 10 loop) lose its position, with a 16bit or 32bit extra data before 0x55AA_AA55:
The right sequence: 0x55AA_AA55 0x0000_0000 0x0000_0001 0x0000_0002 0x0000_0003 0x0000_0004 .... 0x0000_0010;
The wrong sequence: 0x0000_0010 0x55AA_AA55 0x0000_0000 0x0000_0001 ...
6. Once the frame head position error occurs, the error will not recover to a correct state, even if destroy_iio_buffer is called in the tx flow; Rerun the program also has no effect! But when I reboot the Linux OS, the error can recover!
7. fifo_wr_sync and m_axis_resetn have been used to assure DMAC fifo will be cleared and next new packet head will be placed at the head of the buffer in each tx flow!
larsc, how can this error happen? Or is there a mechanism to fix the iio_buffer data postion error without a OS reboot?