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