Hi,
What do you mean by "getting confused by"? There is nothing in the hardware requiring interrupt EPs (or BULK/ISO) to be any specifc number (and in fact you could have EP1 in as INT and EP1 out as BULK, as they map to different physical endpoints at index 2 and 3). About the max size, I guess the problem is related to the code in imxrt_usbdev.c lines 2960-2975, where the max size is statically setup based on the masks for _possible_ end point types. This max size setup probably has to be done in imxrt_allocep or similar based on the actual type assigned to the endpoint. Unfortunately I do not have any setup which uses anything else than bulk endpoints at the moment, so I cannot really test such a change. I could "blind" write a suggestion but not test it. Regards Marten ________________________________ From: David Sidrane <david.sidr...@nscdg.com> Sent: Wednesday, September 20, 2023 11:40:06 AM To: dev@nuttx.apache.org Subject: RE: iMXRT usbdev endpoint allocation problem Hi Marten , See https://github.com/apache/nuttx/pull/4784 Furthermore once all the caching was working, the USB driver had a bug that the bulk endpoints was getting confused with the interrupt endpoints and although sized to 512 where reporting a max size of 1024 causing more fun memory overwrites. So it was because of memory overwrites. How would you suggest it be changed? David -----Original Message----- From: Mårten Svanfeldt <marten.svanfe...@actia.se> Sent: Friday, September 15, 2023 4:23 AM To: dev@nuttx.apache.org Subject: iMXRT usbdev endpoint allocation problem Hi, I'm in the process of updating our internal NuttX from version 10.1 to 12.2.1, and ran into some issues with usb device code on iMXRT. We have a device that exposes a custom class with a fixed endpoint mapping (the toolstack in the other end expects certain endpoint mappings, using ep1 and ep2 for bulk transfers), and I can make it work again by reverting the following commit https://github.com/apache/nuttx/commit/c077361a8a9fc9182b988dee7224043022e ea841 >From a theoretical standpoint I don't understand why that commit was ever made. The USB controller in iMXRT10xx series, which is same as in other iMX chips (iMX6 for example) has no limitations of that certain endpoints needs to map to interrupt/bulk/iso, so I would suggest that the change itself is actually wrong and should be reverted upstream. Does anyone have any more background on the change, the git commit message is very terse... Regards Marten Svanfeldt
