AM335x USB1 device funtion doesn't work

AM335X chip, USB1 Only have host mode, USB1 can not work in DEVICE mode. 

so your failure is normal and right. you don't go on developing.

Hi,

this is a very late response but I did manage to get this working after much pain, which is why the previous poster recommended against it I imagine.  Posting this here such that anyone else having to do the same thing can do so quickly and with some guidance into where the issues are and what changes need made.

We had designed a custom board which made USB0 a host and USB1 a device connection, and therefore needed to get USB1 working as a device. The significant changes involve the USBFN/cppidma.c which for the AM335X is in C:\WINCE700\platform\common\src\soc\COMMON_TI_V1\AM33X\USB\USBFN of the Adeneo WEC7 BSP. To summarise the cppidma for the USBFN needs to use the queues which are associated with the USB1 port, see section 16.3.9 and in particular Table 16-27 of the AM335X Technical Reference Manual (Revised April 2013).

I won't put the exact details of all the changes I made, but here are the main points:

- USBFN\cppidma.c: in cppiCompletionCallback, the qnums in the two 'for' loops need changed such that 93 becomes 125 and 109 becomes 141; use the USB_CPPI_TX1CMPL_QNUM and USB_CPPI_RX1CMPL_QNUM #defines in C:\WINCE700\platform\common\src\soc\COMMON_TI_V1\AM33X\INC\am33x_usbcdma.h instead of the hardcoded numbers.

- USBFN\cppidma.c: in cppiCompletionCallback, because we are dealing with different queues in the CPPI module in order ot use USB1, we need to look at different queues in the PEND registers, so use PEND 3 in place of PEND2 and use PEND4 in place of PEND3.

- USBFN\cppidma.c: whereever USB_CPPI_TX0CMPL_QNUM and USB_CPPI_RX0CMPL_QNUM are found, replace them with USB_CPPI_TX1CMPL_QNUM and USB_CPPI_RX1CMPL_QNUM respectively, to use the completion queues associated with USB1 port.

- USBFN\cppidma.c: in cppiControllerInit:
      -chanOffset needs to be set to 15 for USB1.
      -txqOffset needs to be set to the USB1 TX first queue number, which is 62.
      -rxqOffset needs to be set to the USB1 RX first queue number, which is 15.

- USBFN\cppidma.c: NOT necessary, but may save you time if you know. If you change FALSE to TRUE in the PRINTMSG statement at end of cppiRndisUpdate, in order to print out this message as part of debugging activities, an exception can be caused as it is possible for pRndisReg to be NULL depending on the logic flow through the routine.

- USBOTG\usbotgpdd.cpp : in CAM3xxOTG::CAM3xxOTG(LPCTSTR lpActivePath), I put in m_InFunctionModeFn = FALSE; to initialise the m_InFunctionModeFn member.

- usbfn.reg in your BSP folder: create equivalent entries for [HKEY_LOCAL_MACHINE\Drivers\BuiltIn\UsbOtg2\UsbFn] for any UsbOtg1\UsbFn entries that exist.  Your UsbOtg2\UsbFn would have Index set to 2 in its registry entry.

I think that should cover it.  I actually changed the code so that it sets the above values depending on whether it is USB0 or USB1 being used as this file in particular is in the common code which is used on different platforms.

Hopefully this can help others that have to do the same thing.

Regards

John

This is fantastic! Thank you for the great write up and explanation. You are a credit to the community. Getting this same information out of Adeneo would be impossible.

Thanks David.  It took me a long time to determine the issues. I use the forum to help me plenty of times, so think it was time to pay my dues haha.

Cheers

John