• State
  • Locked Locked
  • Replies 7 replies
  • Subscribers 98 subscribers
  • Views 954 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.

OMAP3730 USB problems

Rob Weitz
Prodigy 40 points

Other Parts Discussed in Thread: DM3730

Our implementation has a Q7 module with an OMAP 3730 processor on it connected to a USB PHY over ULPI using the SMSC3320 PHY.  The Q7 module installs onto our carrier and connects to an SMSC2517i USB hub.  Periodically it looks like there are several re-tries between the 3730 and the USB hub and eventually we believe the 3730 issues a USB reset to our hub.  We came to the conclusion that a reset is being issued because the PLL voltage generated by the hub does down when we start seeing error message reported in Linux.  The PLL voltage going down is an indicator that a reset or disable command has been issued to the hub and the hub is going into a low power state.  Given that our reset line to the device is not toggling and power is stable we believe that this is being commanded from the host.   

We have noticed that the failure is rarely (if ever) seen when using a kernel from the Q7 manufacturer's website which has no additional driver support for the USB hub.  When we use a kernel built by Mercury which does include driver support for the USB hub we see these problems every few hours or so.  On the surface this seems like  it would be some kind of driver issue however, we noticed that when we did some testing at -40C the failures happen on the order of every 20 minutes or so as opposed to every few hours.  So it certainly seems like there is some component level issue at play here as well.

I realize we are using the PHY that is listed in the devices errata as being problematic and our revision of silicon on the OMAP 3730 is susceptible to the errata but i don't believe that we are seeing the issue the errata describes.

Has anyone on this forum seen anything like this?

  • 0
    TI__Guru 65405 points

    Hi Rob,

    Do you mean DM3730 processor and probably using industrial or extended temperature range processors (not commercial version)? Are you check working temperature range of all components on the board related to the USB? Could you give some details about the software version and do you make some modifications in the PLL related files?

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 40 points

    Yes, it is the DM3730 processor.  I believe all the components on the board are industrial rated but I cannot confirm as we did not design the board.   I have asked the vendor to confirm that the board is industrial rated and all parts are.  I think we have confirmed that the DM3730 is industrial.

    We are using kernel versions (2.6.37, 3.0, 3.1+, etc..)

    We have not made any changes to the PLL settings but are looking into errata advisory 2.1 given that we believe we are susceptible to this problem.

    Rob

  • 0 in reply to Rob Weitz
    TI__Guru 65405 points

    Hi Rob,

    It is very probably the issue to be related to Advisory 2.1. I suggest you to try the workaround and configuration from Table 35. Firstly test the behaviour in the room temperature. The failure at -40C could be due to complex reasons.

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 40 points

    Thanks.  That is on the top of our list of things to try.  Do you not feel that we might be more susceptible to the effects of the clock drifting at -40C than at room temperature?

    We don't own the design so I can't be sure but I did see a 26MHz oscillator on the board so I think it is Table 36 that will apply to us.  It sounds like this only reduces the severity of the clock drift and does not eliminate it. Do you have any thoughts on how much the values in Table 36 impacts the problem?

    We are working with the board vendor to see if we can get a Q7 module with the latest silicon revision.

  • 0 in reply to Rob Weitz
    TI__Guru 65405 points

    Rob,

    I only suggest you to test firstly behaviour of the system in room temperature with settings from Table 36 then if the system is stable in room temperature continue with testing in low temperature. I assume that it is possible to have some additional reasons (but I'm not sure until haven't information about all components) for unstable work in low temperature.

    BR

    Tsvetolin Shulev

  • 0 in reply to Cvetolin Shulev-XID
    Prodigy 40 points

    We only see problems at -40C.  We had been somewhat convinced that are susceptible to the errata since we thought revision 1.0 silicon but then we observed that u-boot and Linux display different silicon revs. Since Advisory 2.1 is specific to the revision, can you comment on which is accurate (linux or uBoot), and if there are any known software problems decoding the silicon rev?

    U-Boot 2009.11 (mar 16 2012 - 12:43:22)

     

    OMAP3630-GP ES2.1, CPU-OPP2 L3-200MHz

    OMAP3 EVM board + LPDDR/NAND

    I2C:   ready

    DRAM:  512 MB

    NAND:  512 MiB

    In:    serial

    Out:   serial

    Err:   serial

    U-Boot NAND Version

    Read back SMSC id 0x92210000

    Die ID #00b400029e3800000146a6040c00d012

    Net:   smc911x-0

    Hit any key to stop autoboot:  0

     

     

     

    [    0.000000] Linux version 2.6.32-gs2.2012.09 (grosenbe@williams) (gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203) )                      #1 Fri Sep 20 18:07:41 EDT 2013

    [    0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c53c7f

    [    0.000000] CPU: VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

    [    0.000000] Machine: OMAP3 EVM

    [    0.000000] Memory policy: ECC disabled, Data cache writeback

    [    0.000000] OMAP3630/DM3730 ES1.0 (l2cache iva sgx neon isp 192mhz_clk )

    [    0.000000] SRAM: Mapped pa 0x40200000 to va 0xfe400000 size: 0x100000

    [    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 105472

    [    0.000000] Kernel command line: mem=160M@0x80000000 mem=256M@0x90000000 console=ttyS2,115200n8 root=/dev/nfs nfsroo                     t=/home/grosenbe/grosenbe_intel_output/export/q7-ncipriano-1/,nolock,rsize=4096,wsize=4096 rootfstype=nfs ip=172.18.64.                     207:172.16.31.28:172.18.64.1:255.255.254.0 mpurate=1000

  • 0 in reply to Rob Weitz
    TI__Guru 65405 points

    Hi Rob,

    You can check the silicon revision of your DM3730 processor by reading the CONTROL_IDCODE register value and check it in TRM Table 1-7. There is an example:

    ./readmem 0x4830A204

    By the way silicon errata Advisory 2.1 USB Host Clock Drift Causes USB Spec Non-compliance in Certain Configurations refers to all DM3730 silicon revisions - 1.0, 1.1 and 1.2.

    About the problem at -40C the reason could be more complex and needs complex investigation.

    BR

    Tsvetolin Shulev