• State Resolved
  • Locked Locked
  • Replies 13 replies
  • Subscribers 33 subscribers
  • Views 1222 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/TM4C1294NCPDT: Android Open Accessory IN Pipe problem

Richard Robinson
Intellectual 740 points
Part Number: TM4C1294NCPDT


Tool/software: Code Composer Studio

Hi,

I have written a host driver to connect an Android device to a custom board using the Android Open Accessory protocol. I can connect the Android device. Get the device to reconnect in Accessory mode and once connected in accessory mode I can send data and receive the data on the android device. The problem comes when I try to send data from the Android device to the TM4C1294. I write the data to the stream on the device without any errors, but I receive nothing on the TM4C1294. The Rx count on the endpoint remains at zero. The device returns one interface with two endpoints. In Endpont address 81 and an Out endpoint address 01. The driver is basically  a custom host driver sitting on top of the Tiva USBLIB. If anyone has ideas I would be grateful.

Thanks,

Richard.  

  • 0
    TI__Guru**** 191906 points

    Hi RK,

     I have no experience with the AOA protocol. I just did some reading about it on my end. My understanding is that in accessory mode, the MCU is the USB host and the Android-powered device is the USB device. If I understand you correctly, the MCU acting as the host is able to send data and receive data on the android device. Is this correct understanding? You stated that the problem arises when sending data from the Android device to the TM4C1294. This is where I'm not clear. This seems to contradict with the earlier statement that you can send and receive data on the Android device. The TM4C1294 is the USB host. The USB host should be requesting the data from the device before the device can send the data. I'm not clear as to if the TM4C first sends the request to the Android device and not receive the data. If you have a USB analyzer then it will become easier to debug. You will be able to find out if the host is send the proper request and if the Android device is sending the data back. 

  • 0
    Guru 117855 points

    Greetings,

    Sometimes - if fortune smiles - pertinent information may be (indirectly) sourced.   Several of our small firm's staff have achieved "similar to your expressed need" - via "key findings" derived from the USB-centric firm "FTDI" & while employing (another's) ARM Cortex M4 MCU.    (this was several years back - we may (or may not) be able to further assist...)

    The extent of "FTDI's" accommodation of Android is well noted w/in this screen cap:

  • 0 in reply to Charles Tsai
    Intellectual 740 points

    Hi,

    Yes you are correct the Host must request data from the device. I'm using USBHCDPipeRead which sets the request packet flag on the endpoint. Below are the Receive Control register values for the endpoint directly after the Request Packet flag has been set. You will notice that the data error flag has been set. The data sheet say's this indicates that the data ready flag has been set and a data packet CRC has occurred, but Data Ready has not been set.  

    USB_RXCSRL1_CLRDT 0x0 Clear Data Toggle
    USB_RXCSRL1_STALLED 0x0 Endpoint Stalled
    USB_RXCSRL1_STALL 0x1 Send STALL
    USB_RXCSRL1_REQPKT 0x1 Request Packet
    USB_RXCSRL1_FLUSH 0x0 Flush FIFO
    USB_RXCSRL1_DATAERR 0x1 Data Error
    USB_RXCSRL1_NAKTO 0x1 NAK Timeout
    USB_RXCSRL1_OVER 0x0 Overrun
    USB_RXCSRL1_ERROR 0x0 Error
    USB_RXCSRL1_FULL 0x0 FIFO Full
    USB_RXCSRL1_RXRDY 0x0 Receive Packet Ready

    Richard.

  • 0 in reply to Richard Robinson
    TI__Guru*** 135355 points

    Hello Richard,

    I looked through some of the Android pages but couldn't find information that is needed at an MCU level to guide further.

    What USB interface is AOA expecting the host to use for data transfer? CDC w/ Bulk transfers? HID? Some other class of device?

    That piece is not clear and needs to be uncovered here.

  • 0 in reply to Ralph Jacobi
    Intellectual 740 points

    Ralph,

    Communication is through bulk transfers. I have included the endpoint descriptors returned by the device below. 

    Found Android Accessory device

    pEndpointDescriptor details:
    bLength =0x07 (should be 0x07)
    bDescriptorType =0x05
    bEndpointAddress =0x81
    bmAttributes =0x02 (0x00=CTRL, 0x01=ISOC, 0x02=BULK, 0x03=INT
    wMaxPacketSize =0x0040
    bInterval =0x0000
    Endpoint Bulk In alloc USB Pipe
    pEndpointDescriptor details:
    bLength =0x07 (should be 0x07)
    bDescriptorType =0x05
    bEndpointAddress =0x02
    bmAttributes =0x02 (0x00=CTRL, 0x01=ISOC, 0x02=BULK, 0x03=INT
    wMaxPacketSize =0x0040
    bInterval =0x0000
    Endpoint Bulk OUT alloc USB Pipe

    Richard.

  • 0 in reply to Richard Robinson
    TI__Guru*** 135355 points

    Hello Richard,

    I saw the Bulk Endpoint piece but many interfaces use those. CDC, MSC, etc. What I am trying to understand is what the interface is here.

    If AOA is equivalent to CDC / MSC / HID, then you would need to architecture a custom part of the stack to handle that.

    But if it attaches onto one of those interfaces, then maybe TivaWare can support it natively.

    My worry here is it may require a CDC interface, which we do not have host support for currently.

  • 0 in reply to Ralph Jacobi
    Intellectual 740 points

    Ralph,

    I'm not sure it falls into any particular class of device. See https://source.android.com/devices/accessories/aoa. Here is a full explanation https://tool.oschina.net/uploads/apidocs/android/tools/adk/aoa.html 

    Richard.

  • 0 in reply to Richard Robinson
    TI__Guru**** 191906 points

    Hi Richard,

      The link you shared talks about the Android-powered device needs to be in the accessory mode for which the vendor ID should match Google's ID (0x18D1) and the product ID should be 0x2D00 or 0x2D01. Do you know if the android is in accessory mode?

      The link does not say about which interface or USB class to use. If the AOA requires an unique USB interface then you will need to create your own. You may want to refer to the MSC layer which has Bulk Transfers. 

      Looking at the status register you sent, the NAK timeout and Error bits are sets. It seems like the Android device is not responding. You might want to investigate the android device side too. As I mentioned, if you have the USB analyzer, it will help your debug.

    USB_RXCSRL1_STALL 0x1 Send STALL
    USB_RXCSRL1_REQPKT 0x1 Request Packet
    USB_RXCSRL1_DATAERR 0x1 Data Error
    USB_RXCSRL1_NAKTO 0x1 NAK Timeout

      I'm not familiar with the AOA enough to make more comments/suggestions than what is given above. 

  • 0 in reply to Charles Tsai
    Intellectual 740 points

    Charles,

    I have created my own custom host sitting on top of the USBLIB host drivers.  Everything works as per the standard. When I have switched the device into accessory mode I assign and configure the pipes for the endpoints. I can send data through the out pipe to the android device and receive it in the android app. The only thing that does not work is receiving data on the in pipe. It's so close! Unfortunately I don't have a USB analyzer, wish I did! 

    Richard.

  • 0 in reply to Richard Robinson
    TI__Guru**** 191906 points

    Hi Richard,

      Have you tried with different Android-powered devices? It makes me feel with the status you are getting the problem may be on the device side. You need to debug why the the host is getting the NAK from the device when reading from the IN pipe. The device is not ready to send or has nothing to send and reply with the NAK. 

  • 0 in reply to Charles Tsai
    Intellectual 740 points

    All,

    I would like to thank everyone for their help. I have resolved the problem now. This was not one issue, but two. Firstly the Tiva USB drivers do not handle NAK Timeouts. So if you issue a PipeRead to the device and the device has no data to send. A NAK timeout will occur on the endpoint. This results in the calling thread to loop endlessly in the PipeRead function.

    To fix this I had to use Pipeschedule  and in the receive callback look to see if there was a NAK timeout on the Endpoint and if so issue a PipeSchedule otherwise read the data from the receive buffer.

    The second problem was on the device side. Even though I close the stream on a detach and reopen on re-connect. No data can be transferred unless the application is closed and re-opened. I'm sure this is something I'm doing incorrectly. 

    Thanks,

    Richard.

  • 0 in reply to Richard Robinson
    TI__Guru*** 135355 points

    Hi Richard,

    I've been working on what we can do to make some improvements for Host USB and I remembered this exchange we had. I was wondering if you'd be able to share the modifications you did to the USB drivers to resolve this? I can review them as well to see if they would make sense to roll in directly into the drivers in the future or at least mention via documentation.

  • 0 in reply to Ralph Jacobi
    Intellectual 740 points

    Ralph,

    I'm quite willing to share my code. But I will have to seek permission to do so. Regardless I will at least be able to explain what was involved in getting the driver working and some relevant code snippets. 

    Regards,

    Richard.