Other Parts Discussed in Thread: MSP-EXP432E401Y
Hello Support team,
I am developing portable optical drive (CD-ROM) controller and identified MSP432E401Y microcintroller as suitable for needed tasks.
Currently I am using MSP-EXP432E401Y LaunchPad as development platform plus recent MSP432 SDK (simplelink_msp432e4_sdk_3_40_01_02).
My development is based on provided no-rtos USBHMSC demo (C:\ti\simplelink_msp432e4_sdk_3_40_01_02\examples\nortos\MSP_EXP432E401Y\usblib\usbhostmsc).
The demo itself works fine with USB Flashdrive attached to to the LaunchPad.
Unfortunately this demo uses very limited set of SCSI commands and buffer sizes for managing the USB Flashdrive, so I've added needed additional SCSI commands for CD-ROM support and hit another problem - the DMA is not handling properly receiving ednpoint (so far TX endpoint does not encountering problems).
In USB Flashdrive demo, read buffersizes are usually multiple of 64 bytes (endpoint chunk size) and all DMA transfers copying full 64-bytes packets. In CD-ROM use case there are plenty of buffers that are bigger than 64 bytes, but not multiple of 64 bytes. When try to read such buffer size, the DMA transfer never ends... :(
I did some deeper dive into DMA setting/handling code in SDK and I am seeing that implementation is not done according slau723 documentation (processor TRM). In such cases the DMA is set correctly in MODE1 and number of chunks are properly rounded to cover the last partial chunk. The problem is that the TRM says that this last partial chunk must be handled in special way, but the USB stack code in SDK do not have such handling implemented... or at least I am still unable to find it during my debugging. In result, all chunks except the last partial one are properly copied into destination buffer and USB state machine is hanging in endless check for DMA end event that never happen.
If I round-up read request sizes to become multiple of 64 bytes, I am able to read needed data, but this is just ugly hack that may not workaround all such cases.
On top of this, there are cases when I am trying to read more than needed data chunk (to workaround DMA issue) and the first byte in receive buffer is overwritten with "0". The receive buffer is filled sequentially at portions of 64 bytes and the first byte seems to get overwritten (corrupted) at the end of the transfer. This again indicates to incorrect DMA state machine handling in SDK USB driver.
I've spent already few days debugging this problem and trying to fix the driver code, but there are few different state machines that handling USB stack and DMA transfers and I am still do not have the full picture of interactions (interrupts, states, flags, events...) and can not identify the right place to insert dedicated handling of the last incomplete DMA chunk handling.
Searching Internet for similar problems does not gave me any results, so may be I am the first one that trying to use SDK USB library to read data chunks non-multiple of 64 bytes... and this is pretty standard case for CD-ROM.
Can you confirm my observations? If so, is there plan to fix SDK USB drivers for proper DMA handling according slau723?
... or may be to point me another example(s) or USB library or workaround that can be used as reference in my project?
Best Regards,
Dobromir Denchev
