• State TI Thinks Resolved
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 2866 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.

Linux/PROCESSOR-SDK-DRA7X: Carplay: Continuous USB resets on role switch to device mode

sajan Karumanchi
Prodigy 30 points
Part Number: PROCESSOR-SDK-DRA7X

Tool/software: Linux

In one of our projects we are using TIs DRA7x (Jacinto6) SOC. The software version we are using is PSDK3.01. This software has USB role switch support, which is required for CarPlay.

We are able to launch carplay with iPhone connected over USB Port 1(48890000.usb). But, it is taking longer than expected, usually more than 12 seconds. So, we used a USB protocol analyzer(Beagle Box) and found that there are continuous USB resets after triggering a Role switch to "device" mode with iPhone connected. This is delaying the entire process of configuring the UDC and communication with iPhone over NCM interface.

I'm attaching the USB analyzer logs, which might help you in debugging the issue and help us to resolve the issue faster.

Please download TotalPhase protocol analyzer tool from " https://www.totalphase.com/products/data-center/  " to analyze the attached log. iphone6_carplay_usb_reset.zip

 

  • 0
    TI__Mastermind 42515 points
    Hi,

    I have forwarded your question to an USB expert.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    TI__Mastermind 19030 points
    Hi,
    I'm not the USB expert Yordan mentioned. I remember that J6 USB has limited support for OTG. See excerpt from TRM:
    "NOTE: The current implementation of the SuperSpeed USB DRD subsystem does not support OTG
    2.0 protocols SRP and ADP. OTG 2.0 Host Negotiation Protocol (HNP) is supported."
    "NOTE: When controller is set to OTG mode, SuperSpeed (USB3.0) is not supported."

    Just thought that could help answering your question.
    Regards,
    Stan
  • 0 in reply to Stanislav Stilyanov
    TI__Expert 7885 points
    Hi Sajan

    Based on the bus traces captured during the carplay enumeration sequence,
    1) I have observed the iPhone gets enumerated as high speed device by J6.
    2) After there are multiple resets occcuring for about 10sec (1.38 to 1.49), i assume here, the iPhone is switched to "host mode" and J6 switched to "device" mode, but for some reason the high speed negotiation is NOT happened between J6-device and iPhone-host.
    3) iPhone trying to negotiate to HS speed for about 10 sec and continue to operate in full speed.

    Reason for being multiple resets, is due to iPhone resetting the j6-device, as high speed negotiation has got failed.

    4) Is this custom EVM ? Are you able to observe such issue on TI-EVM ?

    Regards
    Ravi
  • 0 in reply to Ravi B
    Prodigy 30 points

    Hi Ravi,

                We are using a custom EVM which doesn't have a extcon framework. I tried to bring-up the TI-EVM board with help of documents from TI website, but somehow the board is not booting up. Looks like the board has gone bad. We have requested for new TI-EVM board and it will take sometime to get that board. Meanwhile, I will share the DWC3 source changes done by our kernel team on top of "TI-PSDK 3_01"  to support role-switch. Could you please take a look at the changes and let us know if our approach for role-switch is as expected.

    Note: The changes will be shared over email.

    By the way do you have a carplay solution tested on your EVM boards. If yes, then what is the response time for carplay service to launch?

    Regards,

    Sajan K.

  • 0 in reply to sajan Karumanchi
    TI__Mastermind 48263 points
    Hello Sajan,

    Apologize for the delay in repsponding. There has been some re-alignment and I will be taking over this thread.

    Previously, Ravi had analyzed the log provided and suggested that the delay is due to prolonged and incomplete high-speed negotation. To this, it was asked to try this our on TI-EVM. From your response, we undertsanding that you waiting on a new TI_EVM board to test this. Do let us know if there is any update.

    Also, can you once again share the DWC3 code updates done by your team . (Will send you an email regarding this)
    We will analyize & review the updates and will provide our feeback.

    Regards,
    Praveen
  • 0 in reply to Praveen Rao
    Prodigy 30 points
    Hi Praveen,
    Do you have any update ?

    Regards,
    Sajan K.
  • 0 in reply to sajan Karumanchi
    TI__Mastermind 42515 points
    Hi Sajan,

    I have feedback from the team that they are still working on reviewing the patches and will try to update in a couple of days.

    Regards,
    Yordan
  • 0 in reply to Yordan Kamenov
    TI__Mastermind 48263 points
    Hi Sajan,

    After initial review of the patch, I don’t see anything particular that could affect the HS negotiation to fail.
    I have forwarded the patch to other usb dev internally to get their feedback on the same. Will let you know as soon as I hear from them.

    Thank you for you patience.

    regards,
    Praveen
  • 0 in reply to Praveen Rao
    TI__Mastermind 48263 points
    We have further review of the provided DWC patch and the response is as below.
    --
    Software-based role switch underwent system test as part of v4.9 kernel and such an issue was not reported. we would assume that a 10-12 second delay in enumeration would be pretty apparent.

    Coming to the patch itself, couple of things stand out.

    a) Even when doing software based role switch, we have dr_mode=otg set in DT file. Other modes may work too, so suggest sticking to that.
    b) in dwc3_core_init_mode(), both host and gadget are initialized by customer. we don't think we ever do that - we only initialize host mode or gadget mode at a time.
    c) We don't have to do dwc3_core_soft_reset() during mode switch (at least on v4.9 kernel). Not sure why that was needed.

    It seems like in the patch provided, they had to add software-triggered role-switch support manually. This supported is in v4.9 kernel out-of-the-box and can be backported to v4.4 kernel.
    --

    Also, via email we a have provided a updated patches with fixes to the issue on 4.4 kernel. Suggest you to try testing this and let us know..

    One note, after a switch from device -> host -> device, the UDC core doesn't automatically initialize the loaded gadget driver. So we’ll need to unload and reload the gadget driver.
    e.g.
    > modprobe -r g_zero
    > modprobe g_zero

    This shouldn't be a big issue as we're dealing with software controlled role switch and there is script that can easily unload/reload the gadget driver. This issue has been resolved in newer kernels at the UDC core driver.

    regards,
    Praveen