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.

RM48L952 USB does not respond to connection to host

Other Parts Discussed in Thread: TUSB1106, HALCOGEN, OMAP5912, RM48L952, TUSB1105

Our design has a RM48L952PWR connected to a TUSB1106 per the technical reference manual on the device port, W2FC.

I am running the RM48, CDC example project and when I plug the cable into a laptop, I can see the transactions on PIN 5 & 6 that are the correct polarity.

I can set breakpoints in USBDeviceIntHandlerInternal, and this function is entered 6 times when I plug in the cable.

This function also calls USBDIntHandlerProcessStateChange 3 out of 6 of the times it is called.

But, Pins 9 (TXDO), 15 (SE0O), and 33 (GZO) show no signs of life and the laptop identifies the device as unknown.

I have verified these pins are enabled in the pin mux.

I am out of ideas as to why the SW will not respond to the new host, I have not modified the example code.

Any insight would be appreciated.

Chris

  • Chris,

    You mean the RM46L952PGE correct?

    If you don't see GZO then this means the USB device isn't responding to any messages.

    State change could be due to reset on the bus and the plug & unplug but it's still possible that something could be wrong on the board and you'd have a situation where the USB device doesn't think it should respond.

    Hard to say with just this information.  

    Have you tried the same example on an HDK.   I did it a while back and it worked at least as far as this.

    The only trouble I've had w. the example has been with the .ini file and getting windows to recognize the PID, VID but that's much later on in the process than where you report being stuck...

    -Anthony

    PS hope you meant:   Pins 9 (TXDO), 15 (SE0O), and 33 (GZO)

  • Thank you for the pin correction, and I have corrected it in my post above. That was a typo.
    The exact part number is RM48L952PGE.

    I am looking closer at the clock setup, as this might be the difference between the example code and our system, but we are using an 8MHz oscillator on the board.
    I do not have a Dev Kit available with the RM48 on it.

    Another thing to note is within HalCoGen, on the "general" tab, USB block is grey and not blue like the others.
    It is also grey on the "Clock Tree" tab.

    I have followed this page to the letter: processors.wiki.ti.com/.../HALCoGen_USB_Device_-_driver_&_CDC_Class

    Is there another example that does not use CDC?
  • The wrong clock frequency would do the trick, USB is asynchronous like a UART so you have to have the clock set to match the bit timing.

    If the clock is off it would explain why it's not receiving anything correctly. And without receiving a request from the host, the software wouldn't respond.

    This is the only USB example we've got ported to Hercules. The USB device was on silicon called OMAP5912 before though so you could look to see if there are any examples there although you might have to do some significant porting.
  • I have reviewed the clock settings over and over.  My team found this page:

    https://e2e.ti.com/support/microcontrollers/hercules/w/design_notes/3281.differences-in-clocking-for-usb-between-rm48x-and-rm46x-hercules-mcus

    Still getting the same results.

    I would like to post some screen shots of our HalCoGen settings if possible.

  • Ok do you know how to do that?

    Just use the 'Use Rich Formatting' link below and to the right of where you edit your reply.
    It will make a toolbar appear and there is a button there to attach an image file.

    On the other hand you could zip your HalCoGen project folder and attach that. Either way.
  • I figured it out right after I posted, so I edited and add the two photos I felt were most appropriate.
    I can likely zip the HAL folder also if that is helpful.
    Chris
  • your clock configuration looks fine.
    you checked your pinmux correct?

    The USB device shares the same pins as one of the two root hub ports on the USB host so it'd be pretty easy to get the column wrong when selecting USB on the pinmux tab...
  • The PINMUX tab is correct with the exception of pin 24. We are not using the PUENON pin.
    The PUENO pin although is used, and I can see this pin toggle as I plug the cable in and out.

    For our example code, we have a very basic PINMUX config with only USB Device 1 enabled and each of the W2FC pins connected. No other pins are connected.

    Chris
  • Yeah that would make some sense, when the VBUS is detected it would turn on the pullup as part of the 'soft connect'..

    So it's definitely not 'dead'.

    Have you checked your schematic against the HDK schematic? This is the board that we've used w. the demo.

    also would be good to check that bus transceiver again .. I think there is an 1105 and an 1106 and only one of the two is compatible with the way we did our pinout...
  • The HDK does use the 1105. I will review this pinout in detail again, but my understanding of the 1105 vs 1106 was the mode select pin, which is grounded on the HDK. We are using the 1106, so if this is a deal breaker, I would prefer to know more.
  • Chris,

    I think that we need the version w. VO/FSE0 and not VMO, VPO.. which is why it's got to be the 1105.

    See below...

  • Reviewing these drawings and the datasheets again, I find that the TUSB1105 with a mode pin pulled low configures the part in a single ended input mode. The TUSB1106 does not have this mode. Is there anyway to put the RM48L952 in a differential data mode?
  • Unless the RM48 has a differential mode, then we will be looking for a leaded alternative to the TUSB1105.

    Does TI recommend any other transceivers that are single ended and come in a leaded package?

  • Chris,

    No we only support the option of single ended output + Tx SE0. Done this way for timing reasons, better to let the phy create the differential signal internally rather than split into VP/VM way back inside the MCU.
  • Chris,

    For this question I'm going to suggest posting to:
    e2e.ti.com/.../

    That forum supports the TUSB devices and they're best positioned to help w. options.
    (Different division of TI...)