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.

AM37x USB boot issue (SMSC USB3343)

Other Parts Discussed in Thread: AM3715, TUSB1210, TPS65910

I am in the process of bringing up a custom AM3715 board and USB peripheral boot is not working. It's set to only boot from USB and UART. The SMSC USB3343 PHY is connected to the HSUSB0 ULPI interface and I can see the 60MHz clock going into the CPU along with the other ULPI signals toggling. UART booting works using the Flash v1.6 tool. When USB is connected Windows doesn't detect anything, even after a hard board reset. About 45ms after nRESPWRON goes low the nRESWARM starts to toggle at ~120Hz and I can see activity on the NAND flash lines (I assume its because its failed to boot off USB/UART and is trying to boot off the NAND). Its like the ROM code isn't initializing the PHY. I have tried 4 boards and they all do the same thing, The system clock is 38.4MHz. Does anyone have any ideas how to get it to boot over USB?

Thanks,

Greg

Greg Hallingstad | Electronics Design Engineer
www.redfusionstudios.com
Chicago | Milwaukee | Madison

  • As some background questions, I have the following which will help me understand your system configuration.

    1) What sys_boot[] setting are you using in the configuration that UART boot works?
    2) What sys_boot[] setting are you targeting for the USB boot?
    3) Is there any indication on the PC side that enumeration is occurring?  Or does the PC not detect any USB device presence?
    4) If enumeration begins, what packets are you seeing on the USB bus, via an USB protocol analyzer?
    5) Is the 38.4MHz provided via a crystal and using the on-chip oscillator, or from an external oscillator providing a single-ended clock input?

  • Hi Brandon,

    1) Any sys_boot that lists UART works.

    2) I have tried pretty much all of them, right now sys_boot[6..0] = 0b1111011.

    3) There is no indication of enumeration. I do not see any activity on the USB data lines, as in they are always low. VBUS is at the correct level. I have tried many PCs as well.

    4) I wish I had a USB protocol analyzer.

    5) The clock is a TCXO with a clipped sine wave output that goes though an inverter to square it up. I changed it to a 26MHz xtal and am able to successfully send data to the NAND/SDRAM over UART using the flash tool. It was faster to change the crystal than changing the initialization file the flash tool uses.

    I am going to try to wire in a TUSB1210.

  • Have you had any measurable success in understanding what is going on?

  • Brandon,

    Nope. I haven't been successful in modding in the TUSB1210. I did get a USB3317 modded in and it does the same thing as the USB3343, which is not work.

    Greg

  • Greg,

    Have you gone through the caution notice in the AM3715 TRM?

     HS USB boot: If the internal USB transceiver of a supported power-management IC is used, the IC's configuration interface must be connected to the device through I2C1. No other I2C interface is supported for this purpose. If other USB transceiver is used, the ROM code assumes it is powered, clocked, and out of reset.

  • Renjith,

    The USB PHY is not in the PMIC, we are using the TPS65910. I have tried connecting the reset from the USB3343 to nRESPWRON, nRESWARM and VCC without luck.

    Also when its set to boot off MMC1, I don't see any I2C1 data going to the PMIC for VMMC to turn on. The wiki made it sound like the ROM code turned on VMMC if a TPS PMIC was used. 

    I am trying to get my company to buy a JTAG adapter so I can read out the tracing registers.

    Greg

  • Greg,

    Could you please share the portion of the schematics where USB Phy is interfaced with the host? Could you please mail it to renjith.thomas@pathpartnertech.com if possible? I just want to understand how the inputs are provided to the PHY.

  • Hi - I am helping the customer with this too.  We have been trying to trace what is happening.  He was able to connect a JTAG debugger and read the following memory locations:

    0x4020FFB0 0000001B

    0x4020FFB4 00060004

    0x4020FFB8 00000012

    0x4020FFBC 0007307F

    0x4020FFC0 001E0044

    These contain trace info according to the reference manual (26.4.9).  It was not entirely clear to me how to use these (I am not sure whether the MSW or LSW was in the lower address location nor am I not certain which data is the first set of data - and which is the second).  Here's how i THINK the data is decoded and interpreted.  Can you please verify this and correct any misunderstandings:

                    Looking at the trace data I assume address 0x4020FFB0 is the lower half of the reset vector and  0x4020FFB4 is the upper half.  If so, I decode it as the following bits:

    0x1B = bits 4, 3, 1 and 0 are set.  Which I think means:
    0 = reset

    1 = ROM code C main

    3 = Boot started

    4 = Memory boot

    0x60004 = bits 34, 49 and 50 (this is the upper half of the 64bit vector, thus the offset by 32)

    34 =  memory boot NAND

    49 = NAND boot attempted from block 0

    50 = NAND boot attempted from block 1

     

    I don’t see any mention of peripheral boot from USB (would be bit 18)

                    I am far from convinced that I decoded this correctly, but what I think this means is that the part saw a reset, jumped to ROM code and started a boot.  It tried to boot from NAND – and I think was successful when it found data in block 1. 

     

    The next message is 0x0007307F_00000012 which should be

    Bit 1 = ROM code C main

    Bit 4 = Memory Boot started

    Bit 32 = Null device

    Bit 33 = XIP boot

    Bit 34 =NAND boot

    Bit 35 = OneNAND boot

    Bit 36 = DOC boot

    Bit 37 = MMC/SD2 boot

    Bit 38 = MMC/SD1 boot

    Bit 44 = reserved

    Bit 45 = reserved

    Bit 49 = NAND boot attempted from block 0

    Bit 50 = NAND boot attempted from block 1

     

                    I am not actually sure what the second message means.  I don’t know if it’s garbage or maybe it refers to the previous boot attempt.  If so – it seems like the part didn’t find any valid boot device spec’d and so just went down the list of bootable peripherals.  

       Also, do you know if any customers have successfully used the SMSC USB3343 as the PHY for booting from USB with the AM3715?  

       Thank you for your help.

    Best regards,

    Paul Ferrari

     

  • Hello Peter,

    This is my logic.

    From Table 26-9:
    0x4020FFBC Cold reset run tracing vector, word 1
    0x4020FFC0 Cold reset run tracing vector, word 2

    So the string to decode is:
    0x4020FFBC - 0007307F bits 0-31
    0x4020FFC0 - 001E0044 bits 32-52

    From table 26-48 and without typing out the list of stuff the highlights are:
    Bit Meaning
    6 Peripheral booting started – (USB or UART)
    14 Peripheral boot Booting message NOT received
    15 Peripheral boot Image NOT received
    16 Peripheral boot UART
    18 Peripheral boot USB

    This tells me that it’s trying to boot off USB and fails for some reason. It then goes on to try the MMC and NAND devices. Changing the sys_boot pins does change the values in Table 13-109 CONTROL_STATUS[5:0] (0x480022F0). The ROM code only tries to boot off the peripheral once and reset is needed in order for it to try again. This is why the current tracing vectors (0x4020FFB0, 0x4020FFB4) do not have USB/UART flagged.

    Also I am not seeing any I2C traffic to the PMIC to turn on VMMC when it tries the SD card boot. I was under the impression that the ROM code turned on this voltage rail from the wiki page that I cannot seem to find again.

    I am still waiting to see if the firmware team can use the USB port in U-Boot.

    Greg