FX3 GPIF II DMA buffer filling issue

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
lock attach
Attachments are accessible only for community members.
frankchen
Level 3
Level 3
25 sign-ins 25 replies posted 10 replies posted

Hi,

I got an issue related to FX3 GPIF II DMA buffer filling and/or transfer.

The data flow of my application are as follows:

Image sensor -> FGPA -> FX3 GPIF II -> FX3 DMA buffer.

I allocated 3 DMA buffer, each is 32768 (32KB) size. The max video resolution is 1936x1096.  The FPGA sends 32 bytes frame header to GPIF II before sending real frame data for every frames. In most cases it worked fine unless I changed image width to 1452 and each pixel is configured to 8 bits.

The problem can be described as follows:

1、Image is abnormal starting from line 678.

2、The received frame data size is 4 byte bigger than expected.

Attached please find the captured image.

After checking the image, I noticed that there are 4 bytes inserted between end of line 677 and beginning of line 678. The 4 bytes are not expected to be received.

I did some calculation:

32  + 1452 x 677 = 983036 = 30 x 32768 - 4

Where:

1) 32 is the size of frame header.

2) 1452 is the line width

3) 677 is the count of lines

4) 32768 is the size of DMA buffer

It seems that:

At the end of line 677, the DMA buffer is filled with (32KB - 4) bytes. As I understand at this moment the DMA buffer will not be committed, instead it should wait next line to fill the last 4 bytes and then to commit. But based on the test result it seems the DMA buffer is commited immediately after line 677 is filled and 4 byte redundant data is incorrectly appended into the frame data.

Could anyone please help explain if this behaviour of FX3 is normal or not. And what fix or workaround should I add to get correct frame data for above configrations. Thanks.

Regards,

Frank

0 Likes
1 Solution

Hi Rashi,

Yes, the pixel alignment is done in FPGA side, but the key point is not 8-bit pixel alignment. Instead, each line width is aligned to 8-pixels. For eg., line width 1452 is aligned to 1456. Each pixel can be either in 8bpp or 16bpp depth. For me the issue can be resolved in this way.

Thanks!

Regards,

Frank

View solution in original post

0 Likes
20 Replies
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

I understand that you trying to stream 1452*1096* 1 (bpp) video resolution. And you are seeing 4 bytes increase in the frame which starts from line 647.

4 bytes increase could be due to 1 cycle sampling of GPIF bus. Can you please take a trace of the GPIF interface to understand the status of the clock, fv, lv when lines 677 and 678 are streamed?

I understand at this moment the DMA buffer will not be committed, instead, it should wait for the next line to fill the last 4 bytes and then to commit. But based on the test result it seems the DMA buffer is committed immediately after line 677 is filled and 4-byte redundant data is incorrectly appended into the frame data.

>> Please let me know how did you test this

Regards,
Rashi
0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi,

Thanks for your reply.

In our application the GPIF II interface is configured to 32-bit mode.

To identify the issue, in FPGA we did test in the following way:

1) Use a counter to record how many 32-bit words have been sent to FX3. Each clock the counter increases 1. So the value of the counter are 0, 1, 2, ... for each frame during data transfer.

2) Asign the value of the counter to FX3 data bus. So the captured image data should be 0x00000001, 0x00000002 ... etc

3) Asign a special value 0xEEEEEEEE to the first 32-bit word of each line. So we can check easyly if every line in captured frame are in correct postion.

The waveform are as follows. Please note line_cnt=676(the number is zero-based) means it is line 677 (the number is 1-based).

frankchen_0-1646382112121.png

 

frankchen_1-1646382419438.png

 

frankchen_2-1646382577954.png

Part of the captured frame are as follows:

frankchen_4-1646383237111.png

 

The whole image file is attached.

We checked the waveform and it looks all signals are correct for every lines and entire frame. But we got unexpected bytes in PC host.

Regards,

Frank

 

 

0 Likes

Hello Frank,

The 245758 data will not be sampled, Is that correct?

If yes, please let me know if you can share the GPIF state machine used in your firmware. 

Also, if possible please check if the issue is multiple times at the same instance (line 678) on multiple FX3 boards.

To check if the data is being consumed by the USB host without any DMA overflow (without any commit buffer failures), please share the UART debug prints when the streaming is on

Regards,
Rashi
0 Likes

Hi Rashi,

>>The 245758 data will not be sampled, Is that correct?

Correct, data 24578 will not be sampled.

>>If yes, please let me know if you can share the GPIF state machine used in your firmware. 

Could you please provide your email address and then I will send my state machine file to you privately.

>>Also, if possible please check if the issue is multiple times at the same instance (line 678) on multiple FX3 boards.

This issue happens on every frames as long as line width is 1452 8-bpp pixels. It always happens at the same place, between line 677 and 678. However we can see from the image file more lines after line 677 are abnormal, but this may related to the line 677/678 issue.

Also this issue happens on every boards.

>>To check if the data is being consumed by the USB host without any DMA overflow (without any commit buffer failures), please share the UART debug prints when the streaming is on

I checked the UART debug messages, but didn't see any error messages when this issue occurs - no commit error was printed.

Regards,

Frank

0 Likes

Hello Frank,

Apologies for the late response.

After going through the GPIF state machine, I understand that the difference between the state machine and the AN75779 state machine is that instead of the FW trigger Logic 1 is used as a transition equation.

To debug the problem, please register for GPIF error using CyU3PPibRegisterCallback. Please do not use CyU3PDebugPrint API in the callbacks. Instead, you can use global variables and print eh variables in for loop of thread entry function.

I also noticed that CyU3PDebugPrint is called in GpifToUsbDmaCallback. Please track the failure of commit buffer API using global variables or by setting an event.

Please share the UART prints with these tests (with the shared .c files)

You can also try using FW_triggger (as done in AN75779) instead of logic 1 and check if there are any changes. In addition, please let me know how is DMA Ready flag is used 

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks a lot for helping investigate this issue!

I'll do the tests and post the result once I finish the tests.

Regards,

Frank

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi,

Below are the test results.

I applied the .c file which has debugging message "full = %d,partial = %d ..." into my project. But there was no any such messages printed out when I run the test. After checking the code I noticed that I was using auto dma (CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE) so some conditions are not met in GpifToUsbDmaCallback().

Then I changed DMA to manual mode (CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE) and run the tests again.

Test 1: Set the video resolution to 1936x1096, 16bpp. The debug messages are as follows:

prod = 129, full = 0,partial = 0, commit_buff = 0
prod = 258, full = 0,partial = 0, commit_buff = 0
prod = 387, full = 0,partial = 0, commit_buff = 0
prod = 516, full = 0,partial = 0, commit_buff = 0
prod = 645, full = 0,partial = 0, commit_buff = 0
prod = 774, full = 0,partial = 0, commit_buff = 0
prod = 903, full = 0,partial = 0, commit_buff = 0
prod = 1032, full = 0,partial = 0, commit_buff = 0
prod = 1161, full = 0,partial = 0, commit_buff = 0
prod = 1290, full = 0,partial = 0, commit_buff = 0
prod = 1419, full = 1419,partial = 16672, commit_buff = 0
prod = 1548, full = 0,partial = 0, commit_buff = 0
prod = 1677, full = 0,partial = 0, commit_buff = 0
prod = 1806, full = 0,partial = 0, commit_buff = 0
prod = 1935, full = 0,partial = 0, commit_buff = 0
prod = 2064, full = 2064,partial = 16672, commit_buff = 0
prod = 2193, full = 0,partial = 0, commit_buff = 0
prod = 2322, full = 0,partial = 0, commit_buff = 0

....

The whole messages are attached as file 1936x1096_manual_dma.txt.

Calculation: 1936 x 1096 * 2 + 32 = 4243744 = 32768 * 129 + 16672.

So in this case the result is correct.

Test 2: Set the video resolution to 1452x1096, 8bpp. The video freezes after several frames, but we can still get some messages:

prod = 48, full = 48,partial = 18564, commit_buff = 0
prod = 96, full = 96,partial = 8796, commit_buff = 0
prod = 188, full = 188,partial = 18564, commit_buff = 0
prod = 236, full = 236,partial = 9352, commit_buff = 0

The whole messages are attached as file 1452x1096_manual_dma.txt.

Calculation: 1452 x 1096  + 32 = 1591424 = 32768 * 48 + 18564 - 4.

Those numbers matchs the test results in the original post.

Test 3: Change to auto dma, set resolution to 1936 x 1096, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26

......

The whole messages are attached as file 1936x1096_auto_dma_piberror.txt.

Test 4: Change to auto dma, set resolution to 1452 x 1096, 8bpp, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 18
PIB error = 6
PIB error = 6

......

The whole messages are attached as file 1452x1096_auto_dma_piberror.txt.

There are error number 5, 6 which are not found in case 1936x1096.  It seems they are write overrun errors. Not sure what they mean for this issue.

I changed Logic One to FW_Trig in state machine and test it, and there is still the same issue.

Regarding "DMA Ready flag", do you mean the flag0/flag1 signal in FX3/FPGA interface?

Regards,
Frank

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi,

I have finished some of the tests.

I applied the .c file which has debugging message "full = %d,partial = %d ..." into my project. But there was no any such messages printed out when I run the test. After checking the code I noticed that I was using auto dma (CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE) so some conditions are not met in GpifToUsbDmaCallback().

Then I changed DMA to manual mode (CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE) and run the tests again.

Test 1: Set the video resolution to 1936x1096, 16bpp. The debug messages are as follows:

prod = 129, full = 0,partial = 0, commit_buff = 0
prod = 258, full = 0,partial = 0, commit_buff = 0
prod = 387, full = 0,partial = 0, commit_buff = 0
prod = 516, full = 0,partial = 0, commit_buff = 0
prod = 645, full = 0,partial = 0, commit_buff = 0
prod = 774, full = 0,partial = 0, commit_buff = 0
prod = 903, full = 0,partial = 0, commit_buff = 0
prod = 1032, full = 0,partial = 0, commit_buff = 0
prod = 1161, full = 0,partial = 0, commit_buff = 0
prod = 1290, full = 0,partial = 0, commit_buff = 0
prod = 1419, full = 1419,partial = 16672, commit_buff = 0
prod = 1548, full = 0,partial = 0, commit_buff = 0
prod = 1677, full = 0,partial = 0, commit_buff = 0
prod = 1806, full = 0,partial = 0, commit_buff = 0
prod = 1935, full = 0,partial = 0, commit_buff = 0
prod = 2064, full = 2064,partial = 16672, commit_buff = 0
prod = 2193, full = 0,partial = 0, commit_buff = 0
prod = 2322, full = 0,partial = 0, commit_buff = 0

....

The whole messages are attached as file 1936x1096_manual_dma.txt.

Calculation: 1936 x 1096 * 2 + 32 = 4243744 = 32768 * 129 + 16672.

So in this case the result is correct.

Test 2: Set the video resolution to 1452x1096, 8bpp. The video freezes after several frames, but we can still get some messages:

prod = 48, full = 48,partial = 18564, commit_buff = 0
prod = 96, full = 96,partial = 8796, commit_buff = 0
prod = 188, full = 188,partial = 18564, commit_buff = 0
prod = 236, full = 236,partial = 9352, commit_buff = 0

The whole messages are attached as file 1452x1096_manual_dma.txt.

Calculation: 1452 x 1096  + 32 = 1591424 = 32768 * 48 + 18564 - 4.

Those numbers matchs the test results in the original post.

Test 3: Change to auto dma, set resolution to 1936 x 1096, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26

......

The whole messages are attached as file 1936x1096_auto_dma_piberror.txt.

Test 4: Change to auto dma, set resolution to 1452 x 1096, 8bpp, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 18
PIB error = 6
PIB error = 6

......

The whole messages are attached as file 1452x1096_auto_dma_piberror.txt.

There are error number 5, 6 which are not found in case 1936x1096.  It seems they are write overrun errors. Not sure what they mean for this issue.

I'll try to do FW_Trigger test but may need some time to understand it before do the test.

For your reference, I'll send you the .c file into which I made some minor changes for log the messages.

Thanks!

Regards,

Frank

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi,

I have finished some of the tests.

I applied the .c file which has debugging message "full = %d,partial = %d ..." into my project. But there was no any such messages printed out when I run the test. After checking the code I noticed that I was using auto dma (CY_U3P_DMA_TYPE_AUTO_MANY_TO_ONE) so some conditions are not met in GpifToUsbDmaCallback().

Then I changed DMA to manual mode (CY_U3P_DMA_TYPE_MANUAL_MANY_TO_ONE) and run the tests again.

Test 1: Set the video resolution to 1936x1096, 16bpp. The debug messages are as follows:

prod = 129, full = 0,partial = 0, commit_buff = 0
prod = 258, full = 0,partial = 0, commit_buff = 0
prod = 387, full = 0,partial = 0, commit_buff = 0
prod = 516, full = 0,partial = 0, commit_buff = 0
prod = 645, full = 0,partial = 0, commit_buff = 0
prod = 774, full = 0,partial = 0, commit_buff = 0
prod = 903, full = 0,partial = 0, commit_buff = 0
prod = 1032, full = 0,partial = 0, commit_buff = 0
prod = 1161, full = 0,partial = 0, commit_buff = 0
prod = 1290, full = 0,partial = 0, commit_buff = 0
prod = 1419, full = 1419,partial = 16672, commit_buff = 0
prod = 1548, full = 0,partial = 0, commit_buff = 0
prod = 1677, full = 0,partial = 0, commit_buff = 0
prod = 1806, full = 0,partial = 0, commit_buff = 0
prod = 1935, full = 0,partial = 0, commit_buff = 0
prod = 2064, full = 2064,partial = 16672, commit_buff = 0
prod = 2193, full = 0,partial = 0, commit_buff = 0
prod = 2322, full = 0,partial = 0, commit_buff = 0

....

The whole messages are attached as file 1936x1096_manual_dma.txt.

Calculation: 1936 x 1096 * 2 + 32 = 4243744 = 32768 * 129 + 16672.

So in this case the result is correct.

Test 2: Set the video resolution to 1452x1096, 8bpp. The video freezes after several frames, but we can still get some messages:

prod = 48, full = 48,partial = 18564, commit_buff = 0
prod = 96, full = 96,partial = 8796, commit_buff = 0
prod = 188, full = 188,partial = 18564, commit_buff = 0
prod = 236, full = 236,partial = 9352, commit_buff = 0

The whole messages are attached as file 1452x1096_manual_dma.txt.

Calculation: 1452 x 1096  + 32 = 1591424 = 32768 * 48 + 18564 - 4.

Those numbers matchs the test results in the original post.

Test 3: Change to auto dma, set resolution to 1936 x 1096, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26
PIB error = 26

......

The whole messages are attached as file 1936x1096_auto_dma_piberror.txt.

Test 4: Change to auto dma, set resolution to 1452 x 1096, 8bpp, capture PIB errors. The messages are as follows:

PIB error = 26
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 6
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 5
PIB error = 18
PIB error = 6
PIB error = 6

......

The whole messages are attached as file 1452x1096_auto_dma_piberror.txt.

There are error number 5, 6 which are not found in case 1936x1096.  It seems they are write overrun errors. Not sure what they mean for this issue.

I also changed Logic one to FW_Trig in state machine and rebuilt firmware and tested it, but didn't see difference in the result.

Regarding "DMA Ready flag", do you mean the flag0/flag1 signal of the FX3/FPGA interface?

Regards,

Frank

0 Likes
lock attach
Attachments are accessible only for community members.

Hi Rashi,

My reply was treated as spam and was always deleted automatically by the web server. I tried many times but can't resolve it. So I attach my reply as reply.txt in the attachment. Sorry for the inconvenience.

Regards,

Frank

0 Likes

Hello Frank,

From the test result for 1492*1096, we can see PIB errors  5& 6 which are related to CYU3P_PIB_ERR_THR0_WR_OVERRUN & CYU3P_PIB_ERR_THR1_WR_OVERRUN respectively.

This shows that data is written to the DMA buffer even after it is full. As you are using 8pp for 1492*1026, please confirm that you change the bus width to 8 bits in the GPIF II Designer tool.  Please change the data counter and addr counter values in the GPIF state machine based on the GPIF bus width.

The GPIF state machine shared by you uses 32 bits bus width. 

Regards,
Rashi
0 Likes

Hi Rashi,

Thanks for your reply.

I need to use 32-bit bus width because for our application we need to support both 8bpp and 16bpp.  And 32-bit bus width helps to improve data throughput than 8-bit bus width does.

In our application video lines are 4-pixel aligned so that the data is always 32-bit aligned before it is sent to GPIF. That is suitable to use 32-bit GPIF interface.

I am wondering why there are overrun errors especially when the waveform seems correct and it works fine in case line width is not 1452. I checked the state machine but can't find anything wrong.

Regards,

Frank

0 Likes

Hello Frank,

Apologies for the delayed response

Is it possible for you to check the DMA flags for starting(DMA Ready) & stopping (DMA watermark) the data transfers?

With this the FPGA/sensor will be notified if the DMA buffer is completely filled

Regards,
Rashi
0 Likes

Hi Rashi,

As we can see in the state machine file (with GPIF II designer), we use two signals (FLAG0 and FLGA1) to monitor FX3 DMA flags. The settings of the flags are as following pictures:

frankchen_0-1648025736349.png

frankchen_1-1648025789028.png

We expected that FLAG0 and FLAG1 should be low unless the host application is too slow to receive data over USB. If host application is slow and DMA buffers of thread0 and thread1 are full, then one of flag0 and flag1 comes to high. Once flag0 or flag1 comes to high, FPGA will pause to send data. Could you please help confirm if we made mistake on this?

We use this mechanism to implement flow control on FX3 and basically it worked fine based on our testings.  I'll try to capture the waveform for the 1452 line width issue to make sure it works as expected.

Regards,

Frank

0 Likes

Hi Frank,

Once flag0 or flag1 comes to high, FPGA will pause to send data. Could you please help confirm if we made mistake on this?

>> We recommend using DMA_READY for starting the DMA transfers and the DMA watermark flag for stopping the data transfers. Can try configuring a DMA watermark flag ( refer to AN65974) and monitor the DMA watermark flag to stop/pause the transfer in case of overflow

Regards,
Rashi
0 Likes

Hi Rash,

I set the flags to monitor DMA water mark. The flags keep low at the end of line 676 and beginning of line 677. It seems there is no overflow between line 676 and 677?

I'll check AN65974 to learn the details of the flags.

Regards,

Frank

 

0 Likes

Hi Frank,

Please let me know if there are any updates after checking the AN65974

Regards,
Rashi
0 Likes

Hi Rashi,

It is difficult for me to completely understand the DMA flags. In our application the DMA flags are configured to monitor DMA_Ready signals to implement flow control, and they worked fine. So I won't want to change the use of DMA flags.

For the line-1452 issue, I plan to force each line to be 8-pixel aligned so that each line will never be ended with 4-byte-free DMA block. In this way we can get stable video streams.

Regards,

Frank

0 Likes

Hi Frank,

I understand that you aligned the pixels to 8 bit from the FPGA side and that resolved the issue. Is that correct?

 

Regards,
Rashi
0 Likes

Hi Rashi,

Yes, the pixel alignment is done in FPGA side, but the key point is not 8-bit pixel alignment. Instead, each line width is aligned to 8-pixels. For eg., line width 1452 is aligned to 1456. Each pixel can be either in 8bpp or 16bpp depth. For me the issue can be resolved in this way.

Thanks!

Regards,

Frank

0 Likes