So I have implemented my own USB device class using Azure RTOS's USBX, actually based on the example DPUMP class, and very similar to it.
I am using gcc-arm-none-eabi-10 compiler, and in debug configuration (no optimizations -Og flag) my project compiles and runs correctly: I have a thread which handles my USB class, and I can communicate with a PC (running as a USB Host), transmitting and receiving data buffers, very similarly to what the DPUMP example does.
My problem comes when I increment the optimization level of GCC: even if I compile my project with -O1 flag, the processor gets stuck in the USB stack and never exits. I have traced the source of the issue, and the problem seems to be inside the "usb_device_controllers" folder, specific to the i.MXRT chip (I am using the most recent MCUXpresso SDK, 2.9.1): my code gets stuck in the while() loop of the ux_dcd_mcimx6_endpoint_flush.c file, but the cause of the problem is in the file ux_dcd_mcimx6_transfer_callback.c, around the line 277: I can see that the processor gets inside this loop even if "qtd" is 0. I don't know how this is possible, but I suspect this is a bug because there is a comment in line 276 saying that this has not been tested.
If I compile the file ux_dcd_mcimx6_transfer_callback.c with no optimization (-O0) and the rest of the files of the project with -O3, it works fine.
I have also found that the problem happens when my USBX memory area (the one I pass as the first argument to the function ux_system_initialize()) is defined in the OCRAM of the chip (I configure the MPU to make this region a shared, non-cacheable region). If I define the USBX memory area inside the DTCM, the problem disappears.
What can the issue be?
