receiving buffer size bigger than more than 1 frame size

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

cross mob
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

Hi, I am interfacing a qvga sensor to my FX3 board. configured it according to AN75779 reference doc. I traced the data on wireshark and as per the calculation, it shows me the buffer data more than the 1 frame size. What could be the reason?
where I should look into it?

please suggest~

Regards.

0 Likes
1 Solution
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

I went through the wireshark traces.

The way you calculated the frame size from the wireshark traces is incorrect.

= (16407-12-27)*9 = 147,312
= 159217-12-27 = 15,888

Total buffer = 147312 + 15888 = 163200 which is equal to 'S'.

If you have any other queries, please let me know.

Best Regards,
AliAsgar

View solution in original post

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

Hello,

Please let us know the changes that you have done in the AN75779 reference firmware or if you can share your firmware (sensor settings not needed).

Please check if the frame size from the GPIF interface is as expected. For this,  please check full DMA buffers and partial DMA buffer produced for one frame  

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

@Rashi_Vatsa Hi, Thanks.

I checked it like this as per KBA226722.

sensor resolution: 340x240; 30fps
S=1 frame size: 340*240*2 = 163,200 bytes
F=163200/(16384-16)=9

Wireshark  traces shows:

F = (16407*9 -12-27)= 147,624
P=15927-12-27 = 15,888

total buffer = 147624+15888 = 163512 which is not equal to 'S'

163512 - S = 312 bytes extra

please check the attached wireshark traces. please let me know if I calculated wrong or anything else.

Regards.

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

Hello,

Understood

Please let me know the modifications done to AN75779 for supporting the new sensor.

- What video format is sent by the sensor? 

- Is the GPIF bus width 8 bits?

As mentioned in the KBA, please track the full buffers and partial DMA buffers generated by GPIF interface  in the firmware (in CyFxUvcApplnDmaCallback). Please refer to point 6 and 7 of the KBA

Regards,
Rashi
0 Likes

@Rashi_Vatsa Hello.

Sensor out format is raw16. After applying the format (YUV2) in FX3, there is only one color is streaming out, no image is displayed, I had created a post earlier to know how to check the data stream in raw format, in case if this is due to format issue or due to receiving bytes are more than the frame size.

0x59,0x55,0x59,0x32,     //YUV2
0x00,0x00,0x10,0x00,
0x80,0x00,0x00,0xAA,
0x00,0x38,0x9B,0x71,     //end of GUID

yes, GPIF bus width is 8 bits.

Please suggest~

Regards.

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

Hello,

I understand that the frame size is more than expected but this could not be due to the GUID set as YUY2. To confirm the cause of incorrect frame size, we need to check if the frame size received from sensor (through GPIF interface) is as expected. To check that, as asked in my previous response, please track the full buffers and partial buffer produced by GPIF. Also, please let me know if any changes were done to GPIF state machine of AN75779.

If possible, please share the custom firmware for us to check

As RAW16 will be streamed as YUY2, the video is expected to be seen pinkish. To see the actual video you need to use host application that supports RAW format.

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

@Rashi_Vatsa Hi.
Yes, I tried to calculate it (in CyFxUvcApplnDmaCallback). here is the log...

*wireshark log is also attached

AKS_0-1642662614935.png

Regards.

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

Hello,

From the logs we do not get the DMA buffers filled for 1 frame. Can you please reset the variables tracking full buffers when a frame ends (partial buffer is received). Also, please check the no bytes received in partial buffer from GPIF (refer code snippet below)

      status = CyU3PDmaMultiChannelGetBuffer (chHandle, &dmaBuffer, CYU3P_NO_WAIT);
        while (status == CY_U3P_SUCCESS)
        {
            /* Add Headers*/
            if (dmaBuffer.count == CY_FX_UVC_BUF_FULL_SIZE)
            {
                /* A full buffer indicates there is more data to go in this video frame. */
                CyFxUVCAddHeader (dmaBuffer.buffer - CY_FX_UVC_MAX_HEADER, CY_FX_UVC_HEADER_FRAME);
                full_buff++;
            }
            else
            {
                /* A partially filled buffer indicates the end of the ongoing video frame. */
                CyFxUVCAddHeader (dmaBuffer.buffer - CY_FX_UVC_MAX_HEADER, CY_FX_UVC_HEADER_EOF);
                partial_buf_size = dmaBuffer.count;
                full_buf =0;
            ......
              }

 

Please share your firmware files for us to check (sensor configurations not needed)

Also, kindly check the sensor datasheet to confirm that there are no embedded lines sent by the sensor at the start or end of frame

Regards,
Rashi
0 Likes

@Rashi_Vatsa Hello.

here is the log of test...

AKS_0-1642995799362.png

Regards.

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

Hello,

The logs doesn't seem to be proper.

Full buffers are less than the partial buffer. For one frame, partial buffer is expected to come at the frame end. Also, the cons event are more than full buffer (prod event) which is not expected.

Please share the firmware for us to check. 

Also let me know answer to following :

>>Also, kindly check the sensor datasheet to confirm that there are no embedded lines sent by the sensor at the start or end of frame

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

@Rashi_Vatsa Hello.

This is what I am getting as log once set the full buffer and partial buffer flag and reset it after 1 frame read. Please check the attached files and suggest~

>> the sensor doesn't includes any extra embedded lines except the default resolution 340x240 (30fps)

Regards.

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@Rashi_Vatsa Hello.

Could you please check the attached files (in previous post) and suggest some?

Regards.

0 Likes
lock attach
Attachments are accessible only for community members.
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

Please find the attached file with minor changes to get proper prints. Please re-share the UART debug prints with the attached file

Also, please note that the max/min bit rate will be calculated as follows

340*240*2*fps

Regards,

Rashi

 

Regards,
Rashi
0 Likes

@Rashi_Vatsa Hi,

Thanks. I tested it and below is the test log...

The max/min bit rate is calculated as 340*240*16*30 (bits/s). Isn't?
340*240*2*30 (bytes/s)

AKS_0-1643264930145.png

Regards.

0 Likes
lock attach
Attachments are accessible only for community members.
Rashi_Vatsa
Moderator
Moderator
Moderator
5 likes given 500 solutions authored 1000 replies posted

Hello,

The max/min bit rate is calculated as 340*240*16*30 (bits/s). Isn't?

>> Yes, sorry my mistake. It will be 340*240*16*30 (bits/s)

From the logs shared, the cons events are still higher than the prod events which is not expected.

Please find the attached .c file with some modifications

Regards,
Rashi
0 Likes

@Rashi_Vatsa Hello.

Thanks. included the shared file and build. Please check the logs below.

AKS_0-1643297643659.png

Regards.

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

Hello,

Please share the complete logs (from starting the video frame) in .txt format

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

@Rashi_Vatsa Hello. 

Please check the attached log file.

Regards.

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@Rashi_Vatsa Hello.

Could you please suggest something after checking the log posted in previous reply?

Regards.

0 Likes
frank9876
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Hello.

If you look at the wireshark trace for a 16407 buffer.  When you find the UVC header that starts at 0x0C and add the total remaining bytes you are 4 bytes short of a full 16384 byte data packet.  You can also see the count (4 bytes) shown as 0x3ffc starting at offset 0x17 in little endian format.

I suspect that you want a full 16384 byte data packet.  Otherwise, your calculations cannot assume a 16384 data packet as shown above.  I would try to figure out why your full data packets are not 16384 in length starting at the UVC header.

Frank

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@frank9876 Hello.

I am not sure about it since I had tested it with another VGA sensor 640*480 and as per the calculation for S, Full buffer, Partial buffer , it completely matched the requirement with the full buffer size 16407 even though I define the packet size 16384.
But in case of QVGA 340*240, it gives me more bytes then the required. 

Could you please suggest some on this to check more?

Regards.
 

0 Likes
frank9876
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Hello.

The application note is written assuming that a full packet buffer is 16384 bytes.  All the calculations are based on that buffer size.  You can have shorter "full" packets but then the calculations would be based on that "full" packet size rather than 16384.

In your Wireshark trace, the image data looks to be only 16380 bytes.  Wireshark adds internal data prior to the image data.  If your packets were 16384 bytes long,  Wireshark should be saying 16411.  If you look at the data in the 16407 bytes and find where the UVC header starts, you can see that the image data is only 16380 bytes.  If that is the design choice you made, that is okay but your calculations would need to reflect that size.

If your design choice is 16384 byte "full" packets, I suspect what is happening is that the signal that determines the end of a 16384 packet is ending the packet early.  For example, if you had a counter in the GPIF state machine, it's only counting 16380 bytes.  Or if there is an external signal causing the end of a 16384 packet in the GPIF state machine, that signal is ending the packet early.  This issue can show up differently depending on video size because the accumulating data may or may not effect the last partial packet size.  Since you are missing 4 bytes, the data width is most likely 4 bytes (32-bits) and you are missing one data transfer per packet (as opposed to a 16-bit width and missing two data transfers).

I would start by examining how your design is determining the end of a 16384 byte packet.  If your GPIF state machine is counting address's or data bytes, check that the limit is set correctly and the GPIF state is not left early.  If a "full" packet end is determined by line valid from the sensor, verify that line valid is not occurring before the last data bytes are put into the buffer.  For testing, you can change how your design determines  an end of a 16384 byte packet and change it to a smaller number and watch how many data bytes per packet show up  in Wireshark.  From that you may be able to detect a pattern and find out what it needs to be changed to for a "full" 16384 byte packet.

Frank 

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@frank9876  Hello.
Thanks for your explanation. I tried to understand it. so you mean 16384 is not the default max buffer size we use to count the buffer packet. Could you please check these definitions below?

/* Invalid state for the GPIF state machine */
#define CY_FX_UVC_INVALID_GPIF_STATE (257)

/* Timeout period for the GPIF state machine switch */
#define CY_FX_UVC_GPIF_SWITCH_TIMEOUT (2)

/* UVC Video Streaming Endpoint Packet Size */
#define CY_FX_EP_BULK_VIDEO_PKT_SIZE (0x400) /* 1024 Bytes */

/* UVC Video Streaming Endpoint Packet Count */
#define CY_FX_EP_BULK_VIDEO_PKTS_COUNT (0x10) /* 16 packets (burst of 16) per DMA buffer. */

/* DMA buffer size used for video streaming. */
#define CY_FX_UVC_STREAM_BUF_SIZE (CY_FX_EP_BULK_VIDEO_PKTS_COUNT * CY_FX_EP_BULK_VIDEO_PKT_SIZE) /* 16 KB */

/* Maximum video data that can be accommodated in one DMA buffer. */
#define CY_FX_UVC_BUF_FULL_SIZE (CY_FX_UVC_STREAM_BUF_SIZE - 16)

/* Number of DMA buffers per GPIF DMA thread. */
#define CY_FX_UVC_STREAM_BUF_COUNT (4)

/* Low Byte - UVC Video Streaming Endpoint Packet Size */
#define CY_FX_EP_BULK_VIDEO_PKT_SIZE_L (uint8_t)(CY_FX_EP_BULK_VIDEO_PKT_SIZE & 0x00FF)

/* High Byte - UVC Video Streaming Endpoint Packet Size and No. of BULK packets */
#define CY_FX_EP_BULK_VIDEO_PKT_SIZE_H (uint8_t)((CY_FX_EP_BULK_VIDEO_PKT_SIZE & 0xFF00) >>8 )

/* Maximum commit buffer failures to detect a stop streaming event in a MAC OS */
#define CY_FX_UVC_MAX_COMMIT_BUF_FAILURE_CNT (30)

 

Also, please check this calculation and let me know if anything is wrong here....
sensor resolution: 340x240; 30fps
S=1 frame size: 340*240*2 = 163,200 bytes
F=163200/(16384-16)=9

Wireshark  traces shows:

F = (16407*9 -12-27)= 147,624
P=15927-12-27 = 15,888

total buffer = 147624+15888 = 163512 which is not equal to 'S'

163512 - S = 312 bytes extra


So, Please suggest me what I need to check more to figure out this in simple way. Thanks.

Regards.

0 Likes
frank9876
Level 2
Level 2
10 replies posted 10 sign-ins 5 replies posted

Hello.

Given your Wireshark trace, the calculation is:

F =  ((16407 - 27) - 12) * 9 = 147312. 

P = 15927 - 27 - 12 = 15888.      163200 total bytes which matches.

However, my assumption is that you need 16384 bytes per transfer as stated in AN75779 section 5.6 to optimize the USB bulk burst size.  In addition, the receiving end may be assuming 16384 bytes per transfer for a "full" packet.

The other possibility outside the GPIF state machine terminating early is that the DMA is not setup correctly to account for the 16 byte DMA alignment and 12 byte UVC header.  Prior to the ...ChannelCreate call (I do not know if you use single channel or multi-channel), you setup the DMA parameters.  You set the ".size" to 16384 but you must also account for 16-bytes since the DMA needs to be aligned as stated in AN75779 section 5.6.  Therefore, you must set the ".prodHeader" = 12 and ".prodFooter" = 4 to account for the 16 bytes.  You may have forgotten to set the product footer to 4 bytes resulting in less than 16384 bytes per transfer.  You can ignore those trailing 4 bytes in the DMA callback where you modify the 12-byte UVC header.

Frank

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@frank9876 Hello.

Thanks for making me understand about it. I calculated it wrong earlier. Though the receiving bytes are same as 1 frame data, the full buffer size comes up 16407 instead of 16384. I checked '.profHeader' and '.prodFooter' which is already set to...

 

 

dmaMultiConfig.prodHeader = 12; 
dmaMultiConfig.prodFooter = 4;

 

 

Seems, its multi-channel and .size is 16KB.

Regards.

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

I went through the wireshark traces.

The way you calculated the frame size from the wireshark traces is incorrect.

= (16407-12-27)*9 = 147,312
= 159217-12-27 = 15,888

Total buffer = 147312 + 15888 = 163200 which is equal to 'S'.

If you have any other queries, please let me know.

Best Regards,
AliAsgar

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@AliAsgar @frank9876 @Rashi_Vatsa 
Thank you all for your suggestions and guidance.

@AliAsgar Just to know, Is it mandatory for 'full buffer' to be fully filled with (16384) or if it contains less than 16384 even though its max size defined as 16384 (16KB), It is fine? 

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

The amount of data in a full buffer depends on the DMA buffer size configured in the FX3 firmware. 
Does this answer your question? I am not sure whether I have understood your question. If I have not, could you explain your question a bit more clearly?

Best Regards,
AliAsgar

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@AliAsgar Hello.
What I mean is, since the buffer size defined is 16KB ('16384') and receiving data in full buffer is '16407' which is less than 16KB. Is that fine OR the receiving data in full buffer should be equal to defined buffer size (16KB) to have data/data stream without loss?

If this is so, Is it possible to modify the DMA buffer size in firmware from 16KB?

hope, this helps you to understand about my doubt.

Regards.

0 Likes
AliAsgar
Moderator
Moderator
Moderator
1000 replies posted 250 solutions authored 750 replies posted

Hi,

The buffer size is 16KB with 12 byte header 4 byte footer, so the total data from the sensor that can be filled in one buffer is 16KB-16 = 16368 bytes of data.

To this 16368 byte data 12 byte uvc header is added from the firmware, and the wireshark software adds a 27 byte pseudo header in order to view the packets in the software application.

So, 16368+12+27 = 16407. So there is no loss of data. Hope you have understood.

Let me know if you have any other queries.

Best Regards,
AliAsgar

0 Likes
AKS
Level 4
Level 4
100 sign-ins 10 questions asked 50 replies posted

@AliAsgar Hello.

yes sure. I understood it well now.

Thank you so much for making me understand about it. 🙂

Thanks.

Best Regards.

0 Likes