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]

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]

Hello!
I have bought a different camera. It sends in general bigger packets. It is in alternate mode for 3x1024 bytes. Still has problem with missed bytes at small packets - packets with size 128, 140, 94, 74, 77, 115. 4 bytes are lost at the end. 

[Alice_Yang]

Hello @ivaylo 

Sorry for the late reply. This case was not initially assigned to me, so I didn’t receive the notification. Since some time has passed, I’d like to check — has your issue been resolved? If not, I’ll be happy to continue working with you.

Thank you.

BR

Alice

[ivaylo]

Hello, 

Still not solved. 

But I have tried something that improves the situation - I replaced the USB cable with a different one and added a good USB hub. In this situation I removed the added time delay, because now it was giving a worse result. Maybe there is some jitter issue, but the camera with its original cable works fine with different PCs and the NXP kit should be with good USB trace rooting. 

[Alice_Yang]

Hello @ivaylo 

Thanks for sharing.

PC compatibility is indeed stronger than MCU, you are right. When using an MCU, external devices need to be from reputable brands with good quality. We’ve encountered issues before, such as needing a good SD card, a good USB cable, and a good USB drive. It simply doesn’t work well with lower-quality ones.

Thank you.

BR

Alice

[ivaylo]

So.... this was an improvement, not a solution. I don't see any useful registers for optimizing the work of the transceiver, so what could we do next? And as I said before that happens and with a camera from a different producers.
Otherwise the cam chip is Sonix, which is used and by DELL, so we shouldn't consider it as a low quality.

[Alice_Yang]

Hello @ivaylo 

Thank you for your reply.

The detail issue needs to be reproduced , and then we can analyze the specific problem and possible solutions. I know my colleague in your local FAE is working on  your this issue. They have  already escalated our internal SE team for support. They  will send to  you with any updates.

Thank you.

BR

Alice

[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.