IMXRT1060 USB Bulk Transfer Problems

[markdodd]

Developing on a MIMXRT1060 EVK (Rev 0N00X MCU) before moving to custom hardware.
EVK is running as a USB device hosted by a Windows 10 PC.
It's a vendor specific class device.
Started with evkmimxrt1060_dev_hid_generic_bm example as there was no vendor specific class example available.
Device enumerates correctly with an existing proven driver.
With the HID example modified to loop Bulk Out to Bulk In on EventRecvResponse, it will run forever at ~39Mbps with 256 byte packets. With 928 byte frames (512 byte + 416 byte packets) it achieves ~122Mbps.
Problems begin when this simple receive one, send one example is modified to run in a more realistic way with transmissions issued independently from the receiver completion events. I sometimes see problems when receiving >maxPacketSize. For example, if I receive length 6024 byte frames transferred as 11 x 512 byte + 384 byte packets, the first 512 bytes is sometimes lost or overwritten. EventRecvResponse is received normally, but message->Length is 512 bytes short. Send and Recv are always returning kStatus_USB_Success. USB analyzer confirms Bulk Out data on the bus is OK. Throughput is ~75-85Mbps. Problem occurs after typ 3 - 60s. Works fine when receiving <maxPacketSize transfers. Any ideas?
Read the community discussions on whether ATDTW bit is bit 12 or 14 of USBCMD. The current manual for the i.MXRT1060 (Rev. 2, 12/2019) indicates it is bit 14. The SDK examples and MCUXpresso Peripheral Register display indicate bit 12. Bit 14 may be set to 1 or 0 when writing to USBCMD, bit 12 is stuck at 0. So for now I have modified the source to use bit 14.
Another problem is that the device hangs after the primeTimesCount exceeds 10000000 in USB_DeviceEhciTransfer(). This can occur for a Bulk Out transfer and less frequently for a Bulk In transfer, but happens much less than the lost 512 byte packet problem. Any ideas on this one?
Using SDK 2.8.2, had a look at 2.9.1 and there do not appear to be any significant changes in the USB code.

[mjbcswitzerland]

Hi

In case of complications with USB don't forget that the uTasker project contains industrially proven USB on Coldfire, Kinetis and i.MX RT parts (compatible, mature code on all FS and HS USB from 2008 to 2021) with chip (and USB) simulation to better analyse the operation and identify issues.

Regards

Mark
[uTasker project developer for Kinetis and i.MX RT]
Contact me by personal message or on the uTasker web site to discuss professional training, solutions to problems or rapid product development requirements

For professionals searching for faster, problem-free Kinetis and i.MX RT 10xx developments the uTasker project holds the key: https://www.utasker.com/iMX/RT1060.html

[neilporven]

Hi Mark,

I am starting to look into using the IMXRT eval boards, but which will you recommend 1050 or 1060?

I am also looking into transferring info via the USB from the IMXRT to a Windows PC, I see that you selected a particular example, can you share with me why you choose that one?

Thanks,

Neil

[markdodd]

Hi Neil,

The reason we selected the 1060 over the 1050 was because of the 1MB of onchip RAM, which covers all our requirements.

Regarding the particular code example we started with. As there was no vendor specific example available, we just chose the one that came somewhere close to our requirements. We probably could have started with the vcom or other examples too.

We have previously used the LPC1837 and there was a vendor specific example for that so we are quite familiar with what to do.

We already had a working driver, so that helped to bring up the EVK reasonably quickly.

The issues we are having with bulk transfer are not entirely unexpected with a new MCU, I suspect it must be an interrupt or timing issue but I thought I'd check with the community to see if anyone had encountered anything similar.

Mark

[neilporven]

Thank you Mark.

Was the driver provided by MCUXpresso easy to use?  Any issues with configuration, etc.?  Is there documentation available to follow?

Sorry... too many questions, but sometimes is better than jumping in blind into an evaluation kit.

Neil

[markdodd]

Hi Neil,

SDKs are built dynamically at NXP. I started with all options selected to start with, but lately just select the ones of interest.

Documentation is generated at the same time as the SDK.

I think I started out with a cdc vcom example and that uses the standard Windows usb serial port driver which I used with Teraterm.

There are many other usb samples, but I've only tried a few of them. Anything non-standard will require your own driver, whether NXP provide any host driver source, I don't know.

BTW I just checked my 2.8.2 usb code vs latest 2.9.2 version and there are some differences. 2.8.2 has usb stack version 2.6, 2.92 has usb stack version 2.7. May be I'll try it and see if it resolves any of my problems.

Mark

[neilporven]

Thank you mark.

[markdodd]

Merged USB Stack Version 2.7 changes into my code.
Implemented the fix suggested by "Possible race condition on usb_device_dci.c".
Implemented the fix suggested by "K22 USB device CDC and HID problem".
Problem not yet resolved.