Isochronous data transfer - sometimes 4 bytes are lost

[ivaylo]

Hello!
I use MCXN947, Free-RTOS, USB-host, h264 camera connected, isochronous mode, NXP USB stack.
At the screenshot from the USB analyzer are surrounded in blue the packets that are missing in the receiving callback the last 4-bytes. There can be noted some pattern which packets are broken, but I am not able to find out what could be the reason for that. I know that in isochronous transfer some packets can be damaged, but here there are so many that the video stream is broken. The broken ones are always with 4 missing bytes at the end. The camera never sends 40 bytes packets or 72 (according the usb analyzer) but often I receive packets with such size (visible at the picture).

Buffer is aligned
#define cam_buf_max_ 1000
USB_DMA_NONINIT_DATA_ALIGN(USB_DATA_ALIGN_SIZE) static uint8_t s_CAM_BufferA1[cam_buf_max]; //CAM

static void stream_callback (void *param, uint8_t *data, volatile uint32_t dataLength, usb_status_t status)
If I  clear the buffer fully after the last reception, in the broken received packet there are only zeros beyond dataLength, i,.e. dataLength is correct for the buffer, but somewhere the 4 bytes at the end are lost.

status = USB_HosVideoStreamRecv(handle, s_CAM_BufferA, cam_buf_max, stream_callback, handle);
USB_HosVideoStreamRecv is part of NXP video class
interval 1
maxPacketSize 1000
numberPerUframe 1

[Alice_Yang]

Hello @ivaylo 

I apologize for the late reply. Here are some suggestions:

1. Please switch your device to the Device Virtual Camera (SDK USB device demo) for testing.
2. Try changing the type/model of your camera.
3. Consider lowering the FPS .
4. As a workaround, you can add a delay in the USB_HostEhciTransactionDone() function.

Thank you!

BR

Alice

[ivaylo]

Dear Yang,

One more comment...

I have an idea - to be changed dynamically the bInterval. If the received packet in iso mode is less than 80bytes, bInterval to be increased to 2 or 3, otherwise to stay the default - 1. Like that more data will be accumulated in the buffer of the camera and no more smaller packets will  be send. This is violating a bit the USB standard, but I have no other ideas. Can you offer a proper way for dynamically change the bInterval for the ISO EP? 

[ivaylo]

Hello Yang,

Thank you for your answer!
1. The demo with the virtual camera is a usb device. Here the problem is in a host mode.
2. It is not so easy to be found h.264 camera. I bought a second one from a different producer but it has different problems and is not an option (tested on a computer).
3. FPS is already have been lowered. The camera give less small packets when I set an alternate setting for a smaller endpoint - 256 bytes. In this situation I have much less broken frames. And the program stops less often at the brakepoints  for packets with size 40 bytes and 72 bytes. With 128bytes already there is no enough bandwidth to be send the video (800x600). Really the problem is only with tiny packets.
4. I already have added information that I had tested with a such timedelay. Experimented with different values. Now is with the "optimal" one - there is a bit improvement from it, but definitely not sufficient.
Why the problem is only with very small packets?

[ivaylo]

Adding some time delays (due to printf by accident) in 

void USB_HostEhciTransactionDone(usb_host_ehci_instance_t *ehciInstance)

if (index == 8U) /* transfer is done */

improves the situation, i.e. more rarely broken packets are received,

[ivaylo]

So...
void USB_HostEhciTransactionDone(usb_host_ehci_instance_t *ehciInstance)
case USB_ENDPOINT_ISOCHRONOUS:
if (index == 8U)
From here the bytes are missing. Adding 4 in the datalength gives just zero bytes, so I think it is a hardware issue of the USB module.