MCX MicrocontrollersのトピックRe: Isochronous data transfer - sometimes 4 bytes are lost

Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Wed, 24 Sep 2025 12:16:07 GMT

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

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Sat, 27 Sep 2025 00:24:06 GMT

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,

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Tue, 30 Sep 2025 09:08:25 GMT

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.

Re: Isochronous data transfer - sometimes 4 bytes are lost

Alice_Yang — Mon, 13 Oct 2025 09:09:49 GMT

Hello @ivaylo

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

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

Thank you!

Alice

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Mon, 13 Oct 2025 11:21:29 GMT

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?

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Mon, 20 Oct 2025 13:32:00 GMT

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.

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Mon, 20 Oct 2025 18:13:17 GMT

Re: Isochronous data transfer - sometimes 4 bytes are lost

Alice_Yang — Tue, 11 Nov 2025 10:41:03 GMT

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.

Alice

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Tue, 11 Nov 2025 13:22:08 GMT

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.

Re: Isochronous data transfer - sometimes 4 bytes are lost

Alice_Yang — Wed, 12 Nov 2025 02:51:18 GMT

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.

Alice

Re: Isochronous data transfer - sometimes 4 bytes are lost

ivaylo — Wed, 12 Nov 2025 12:39:30 GMT

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.

Re: Isochronous data transfer - sometimes 4 bytes are lost

Alice_Yang — Thu, 13 Nov 2025 01:36:37 GMT

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.

Alice