USB Device Implemenation for RM46

Friebel,

One of our USB experts will help you on this.

Arne,

Please refer to this post regarding configuration of the VCLKA3_S and VCLKA3_DIVR clocks for the USB device module.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/369302.aspx

Let me know if this helps.

Regards, Sunil

Arne,

Also if this is one of our kits (HDK) there is a DIP switch S2 with a few settings that need to be ON to enable USB.

-Anthony

Dear Mr. Seely,

I do not use the HDK or other kits from you. We have made our own board with a device USB regarding the 6-Wire connection transceiver TUSB1105. The connection are made regarding the manual...see above. I do not get over the default state and USB reset state...I do not reach address state...see above.

What must I do to reach address state

What registers will be cleared by USB reset state 

I do not find any comments in the manual about the signal GZO, PUENON, PUENO, SUSPENDO and so on

How will they influenced by the software setting

Best regards A. Friebel

Dear Mr. Sunil,

sorry but the link does not work. The documentation of the TI RM46 is horrible. I have checked the clock by using the ECLK output. On page 122 (2.4.4 Clock Test Module) the SEL_ECP_PIN must be set to Dhex to get the VCLKA3_DIVR signal. On page 159 Register Description for SEL_ECP_PIN with Dhex you get VCLKA3_S. Whats right ?

The VCLKCON1 Register is set to 0x00060006hex and so the Division is 1.

On page 1828 it is written that the USB device will only need a 48MHz Clock for working. The Host also need 12MHz.

I get a device state change interrupt, so I would say that all transaction on EP0 should work. The next problem is that in the TI manual there is no decription for the signals GZO, PUENO, SUSPENDO and so on. There exists no description which software setting will influence the signals. 

- What settings are necessary for USB reset

- How can I go to address state

- How can I check the external additional signals

- What will influence the signal

Best regards A. Friebel

Hi Arne,

Sorry about the link. Here's the correct one.

http://e2e.ti.com/support/microcontrollers/hercules/f/312/t/369302.aspx

Thanks for pointing out the discrepancy in the documentation. The table in the section describing the "Clock Test Mode" is correct. The CLKTEST register description will be corrected in the next update. SEL_ECP_PIN = 0xD will output VCLKA3_DIVR on the ECLK pin when in Clock Test mode.

VCLKACON1 = 0x00060006 means that you are using the output of PLL#2 for sourcing VCLKA3_S and then VCLKA3_DIVR is the same as VCLKA3_S. In this case the PLL#2 output is configured to be 48MHz. Does this match your PLL#2 configuration?

Please confirm.

Regards, Sunil

Hello Sunil,

yes, PLL2 is set to 48MHz and I check the ECLK output.

Regards, A.Friebel

Hi Arne,

So in that case I would make sure firs that MODE is set to GND for single ended operation.   The RM46 doesn't support differential mode. 

Then, I would suspect that perhaps you are missing enabling the 1.5K pullup in the figure.

This is controlled by the PUENO pin which drives the SOFTCON pin on the transceiver.

This pin is controlled by bit PULLUP_EN in the SYSCON1 register and it's mentioned in several of the flow charts. 

The host controller needs to see the D+ line pulled up in order to sense that the device is plugged in.  Just plugging in the device physically without the pullup switched in is not enough.

Those things are easy to check and/or probe.  

After that things might be more complicated and I would suggest that you might want to either get one of the HDK kits or try porting the USB example software for the HDK to your board,   OR get the help of some sort of USB analyzer.

The HOST controller actually has to send packets to the device to configure it, so we'd be wanting to confirm that these packets are indeed sent.

Dear Mr. Seely,

Like I write it before the TUSB is connect like in the drawing, so the mode pin is set to GND. Maybe I have to explain it to you, that when USB is connected (via VBUS) and the Pullup is active the attached and default state has been entered. After that the host will make a reset, which I also detect. So if you read my first email you can recognize that the Signal VBUS and PUENO will work. To be honest, the description of the RM46 is horrible with a lot of faults. So I repeat it once more

How can I get after USB Reset to addressed State ?????????

What kind of registers must be set after USB reset ?????????

Which registers will be cleared by the USB reset ??????

The VBUSI signal will (?) start the USB unit, after which condition (SW and HW) GZO und SUSPENDO is given out ????? (This is really important, because the driver can be disabled with the signals !!!)

The only signal which seems to be directly set by a software register is PULLUP_EN (SYSCON1) as you said. And the others ????

What happens if the RXDI signals gets low ???

It seems to be that the RXDPI and RXDMI Signals will only detect special state, but not Data Flow. Is it like this ?????

I need to know, if when I get to the USB reset state, which signals and connections are ok !!!

If you are not able to answer my questions, please lead me to somebody who can do this.

Best regards A.Friebel

Arne,

There is an example: http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class - have you tried starting with this example?

Really can't answer your questions above succinctly -  a lot of the answers are covered in pages of flowcharts / register descriptions in the RM46 TRM USB chapter - between this information and the example that should cover most of the issues you run into.  If there's some specific issue that you're stuck at we can definitely help to get you past this.

But right now I don't even know what software you are using which is probably more than half of the 'recipe' it takes to get USB comms working so it is very difficult to help.  

Also do you have any way to monitor the USB bus so that you can see what the host is requesting?   The host controls *all* USB activity - so if you can't see the host activity you really can't say that the device isn't working.

Dear Mr. Seely,

you are right, the USB communication is not so easy. I can not use your CDC software, because we have to validate the SW by the TÜV.

You told me, that you can not help me, and that the information is in the manual...thanks...but this is not so...please tell me, where I can see or where it is descripted how the signals (GZO,SUSPENDO..and so on) will work together with the software register setting and which setting will influence the behaviour in device mode. Also the HW Handshake of the signals are not descripted, which signals state follows the next signal..

I think that this information should be in the manual. For other interfaces it is normal to have more information like SPI, I2C. For the USB there is also no flowcharts regarding the signals

To be honest, I do not reach the address state, so I am far away from the USB specific protocol !!! This state cross should be an autodecoded state, this will be written in the manual...but who knows.

In the RM46L852 Manual SPNS185A(2012) the Signal GZO is descripted as "Pull Up Enable, allows for SW-programmable USB device connect / disconnect"...in the manual SPNU514A (2013) the picture for the USB Device Connection shows that the GZO will be connect to OE of the TUSB. Thats the quality of the manuals.

Even you should agree me, that if when I reach the USB reset state, a part of signals are working...so what I want to know is which signal will be ok...and because of that I need more information.

Please lead me to anybody who is more familiar with the USB. I need answer to my questions. I have lost 3 days since my first email.

Best regards A. Friebel

Dear Mr. Seely,

your hint to use the HDK is also not usefull, because the HDK will use the USB Host Port. I want to use the Device Port.

Best regards A. Friebel

Hi Arne,

The HDK has one type "A" and one type "B" USB connector.   The footprint is actually such that you can remove the type "B" and replace the connector with an "A" in case you want to exercise both ports of the OHCI controller.

Where are you looking exactly on the HDK?  The B connector is just to the right of the mini-AB where you plug in the XDS100v2.

Arne Friebel said:

you are right, the USB communication is not so easy. I can not use your CDC software, because we have to validate the SW by the TÜV.

Arne - my reason to suggest the CDC software example is to point you to something that works so you can have a working example to study.  With something as complex as USB this is very important IMO.   If I could give simple answers we probably wouldn't have as many pages written in the TRM about the device's operation.

Arne Friebel said:

You told me, that you can not help me.

Arne Friebel said:

In the RM46L852 Manual SPNS185A(2012) the Signal GZO is descripted as "Pull Up Enable, allows for SW-programmable USB device connect / disconnect"...in the manual SPNU514A (2013) the picture for the USB Device Connection shows that the GZO will be connect to OE of the TUSB. Thats the quality of the manuals.

Arne Friebel said:

..when I reach the USB reset state, a part of signals are working...so what I want to know is which signal will be ok...and because of that I need more information.

Not really,  it doesn't take much to reset the device. Just shorting the D+,D- low would do the trick.

And you were concerned before that you are not getting into an addressed state.   Please see page SPNU514A - page 1761- in the description of bit ADD.  "Addressed state bit: the device is attached to the USB, powered, has been reset, and a unique device address has been assigned. This bit (ADD) returns 1 after an ET_ADDRESS standard request."     That request comes from the USB host, which is why I was asking you if you can check the USB bus with an analyzer of some form to confirm that the host actually sent this request.  If it did not then the likely suspect is the pull-up enable.  The device cannot enter the addressed state before the HOST sends this request.

You definitely should take a loot at the CDC example and compare the interrupt handlers with the flowcharts shown in the TRM - sections 32.3.8 through 32.3.25 for starters.  There is a flowchart for pretty much all the events and these show you where steps need to be taken by software.

For example, at the end of 32.3.8 and in the flowchart 32-58, the instructions say that you need in software to set the PULLUP_EN bit to '1'.  (or keep it '0' if you are not ready to communicate with the USB host..)

So if you miss this step, then the host will not see a device connected.  If it doesn't see the device connected, then it won't send the message to endpoint 0 to set the address and you will not get into the addressed state.

If you are trying to write your own USB device stack from scratch - I hate to say this but 3 days isn't a lot of time to be stuck.  This is a hard problem which is why it's going to take you a while.  It's also why there are commercial offerings available for middleware like USB stacks.  My understanding is that Wittenstein has something developed which will support safety certification.  I think they already have a demo for the RM48 available that you can download.  If you want a contact for the right person there please email me directly and I will connect you.

Dear Mr. Seely,

well, I am a little bit tiered of this discussion for nothing. Please lead me to anybody who can help me...and will not every time tell me that it is complicated or that I should use any other SW. Of cause if have checked before writing to TI if the Softcon Pin and it is working. I have measured it with the scope and the pullup works. You told me, that if you shorted D+ and D- you get a reset, maybe, but the reset will be not given though to the unit if the TUSB is not in receive mode. Thats what I am asking for....which state should the signals have on the TUSB, which setting will be influenced the signals...but since 4 days you are not willing to answer me. (I am not writing the USB stack for 3 days, I am trying to get an answer of you for 3 days..now 4 days...I have already written a USB stack which is working on ARM, now I want to modify it for the TI processor)

I have now checked all signals leading in and out the TUSB. I see that the TUSB will get in receive mode, I have checked the host signals, level and timing is ok...all signals I have measured directly to the pins. So I can say the hardware is working, and that the unit will not answer to the host request.

Now I am back at my email from the 19th.

After default state, the USB works in correct speed, so regarding the USB spec the command "set address" is send out from the host, and the device will get in address state. This is made regarding the manual with a autodecoced sequence. I can see that a sequence is sending out from the host, and that it is getting through the TUSB.

Here I am back on the questions: (19th !!!)

What settings do I need for leaving reset state to address state ?

What is the interaction of the Hardware Signals ?

What happen to the HW-signals, which condition of signals will change after what ?

What settings will be cleared by the USB reset ?

Best Regards A. Friebel

PS: Are you the only person, who is responsible for the USB...is there no other one ??

Arne,

Seems like forum support isn't working out well here.  If you wish, we can setup a time to discuss over the phone.

Just shoot me a message privately.

Dear Mr. Seely,

If you want you can call me, my number is 0049-7731-9332-16. I am in the office up to 16:00 pm. I do not know the time shift for germany to you.

Best regards A. Friebel

Dear Mr. Seely,

I have found a hint in the manual.

"Interface signals for the host port #2 are multiplexed with interface signals for USB device port. If the application requires the use of the USB device port, than the USB host port #2 must first be powered down."

Please comment the line and tell me what to do.

What kind of register must be set and how ?

Best regards A.Friebel

Hi Arne,

I'll have to check w. Sunil regarding the wording 'powered down'.   As far as I am aware it should just need to be
 in the IOMM / pinmux registers to select the pins of the device instead of the 2nd host port.   The easiest way to ensure this would be to use HalCoGen to generate the pinmux MMR register values,  there is a button to select USB device.

But the TRM also includes the equivalent information in table 32-1.

I'll check into and confirm on the OHCI controller port power down.   But do you even have the OHCI controller operational? or is it just left in the default state after reset?

Arne,

I talked to Sunil.  He was going to post this but I think he may have gotten busy.

The comment about power down probably has more to do with the OHCI host controller functioning if you are using the USB device,  it's to keep the host controller from responding to device activity.

So I think the question to understand is whether you are using the USB OHCI host controller.  If not then this might be a moot point unless you are also not setting up the pinmux (IOMM) module for the device controller.

You mentioned also that your host does recognize the device, because SOFTCON is set correctly.

So following this there should be several transactions on the bus.  The first one should be a GetDescriptor which requires a response from the device.   Do you see the device responding?  If so how does it respond (what is the data in the response packet..)

PS> our hours don't overlap much at all, missed you today by the time I had gotten to checking forum posts.
Let's see where the questions today lead.  If no-where we can setup a MM# and that way one of us can dial in from home.

Dear Mr. Seely,

I have checked the IOMM Settings before, and they are all correct set. I forget to tell you that the softcon pin is a GPO pin, because I have to use the QEP unit. The GPO pin for softcon is set parallel to the register for the pullup enable. (SYSCON1/PULLUP_EN) 

I do use only the device port. I do only configure the registers that are seen in table 32-30. (USB Device Controller Register) So all others will be set like after reset.

The only valid access in default state is a Get Descriptor and Set Address. I see that pakets will be transfered by the host but the RM46 will not change to drive function (OE remains high). I will not get an address state interrupt, so here a set address commend will be not be understanded. A Get Descriptor, would initiate an setup interrupt, or ? (This I will check)

What I am seeing is that the RM46 will not answer to the incoming paket, and that there will be no switch from receive to drive via the OE at the TUSB. So I suppose that after the USB reset, a setting will be lost or special settings must be made. (A USB reset will clear some registers). My questions is, if a USB reset occurs a softcon disconnect is made by the unit. In the SYSCON1/PULLUP_EN description stands a USB reset will not clear the register.

An exact measurement of the host commands is not so easy, as you know the TUSB package is very small and to adapt there some probes are not so easy. I do not think that this will be the problem. It will be I think not so helpfull to know that the host (PC) will send it...I have look at the signals, regarding the level, the edges and the timing it looked good. But I would see what I could do.

Please check what power down really means ?

Please tell me what kind of interrupt a get_descriptor will initiate ?

Best Regards A.Friebel

Arne,

Hi this is good information.

I think we also need to consider what might keep the USB device from correctly receiving GetDescriptor;  if there is no response as you say then this could be some incomplete initialization step of the USB device,  but it could also be a problem externally on the board, or in clocking.   Both of these could prevent correct reception of the Setup packet for GetDescriptor and if this isn't received correctly the device would not respond with the descriptor data packet.

So I'd also confirm that the receive data is passing through the TUSB1105 correctly - checking pins VM, VP, and RCV to make sure the data passes through and the signal levels etc are good.

And I'd double check that there are no problems in the device level clocking, because if the USB clock isn't set right, it would be like a UART configured for the wrong baud rate.  Frames might come in but would be discarded because of bit timing errors or received incorrectly (with USB discarded is more likely as the checking is a lot more intense..)

Will look at your other questions but wanted to get you thinking about these issues as well.  And I think confirming the signal makes it through the TUSB1105 probably is a quick thing to rule out.

Arne,

This might be of some use.  I setup the HalCoGen CDC Example for RM48 on a bus analyzer and captured what occurs when you plug into a PC.  You can use this as a reference perhaps.  I didn't really test that the build works well as a VCP that can come later but it at least enumerates on my PC correctly which is the step you are stuck at now.

Attaching

   1) a screenshot

   2) The .tdc file.  Used an inexpensive but quite capable Beagle 12 from total phase and I think you should be able to download their data center program and import the .tdc if you want to examine it in more detail than just the screenshot.

  3) CCS Project - it runs on the RM48 HDK if you have one.  It might save some time rather than going through all the steps on the website above...

http://e2e.ti.com/cfs-file.ashx/__key/communityserver-discussions-components-files/312/3005.usb_5F00_cdc.tdc

2677.RM48_USB_CDC.zip

Arne Friebel said:

Please check what power down really means ?

This means that the root hub port is powered down, per the HCRHPORTSTATUS1 register.

Arne Friebel said:

Please tell me what kind of interrupt a get_descriptor will initiate ?

Well the very *first* interrupt I get when I plug in the USB cable is

    if ((USBD_INT_SRC_DS_CHG & uIrqSrc) != 0u) {
        USBDIntHandlerProcessStateChange(USBD_0_BASE);
    }

That I think is due to the reset that you see in the trace.   Are you getting this?

The interrupt that I see due to the Get Descriptor Setup packet is this one:

    if ((USBD_INT_SRC_SETUP & uIrqSrc) != 0u) {
        USBDIntHandlerSetup(USBD_0_BASE);
    }

But I think you can't write the code to expect a predetermined order for these.  So I'd just use this to figure out how far along you are getting.  If you look at the CDC example for HalCoGen it handles the packets however they come in.  Because you might get multiple resets or an SOF interrupt or something you don't expect if you try to hardcode a fixed sequence as a device.  

Dear Mr. Seely,

I am not happy about the quality of this support. I have checked the TUSB signals a few days ago, as I write it to you and I tell you that the host is getting out correct signal levels and that the timing is ok. I have checked the Pins VM, VP and RCV direct on the processor and the signals are ok. But the USB unit is not answering.

I do not get a addess state interrupt or a setup interrupt. I have ask you about the CLK setting, and I measure 48MHz.

In your last email you send me a screenshot, which can not be read. The link you send me leads to an Error page. All time you told me to use the HDK and the CDC Software, but honest your customer does not want to buy the HDK for USB connection. And it leads at the end to the fact, that we have to implented on our board.

Then you send me the information that the port is powered down by the HCRHPORTSTATUS1. Really, a status register, where a few bits can be cleared...you are joking. Have you looked at the register description.

I am still on the point of my first email. I do not get, any address state interupt or a setup interrupt...thats the problem...so the USB device will not recognize the incoming frame.

So I am asking again and again...

Which setting must I made via initialization

How can the set_address or get_descriptor host command fail

How about the usb reset initialization

Why does the GZO will not change to drive mode

I would like to have the support from another person, who can really me !!!!!

Best regards A. Friebel 

Arne,

Arne Friebel said:

In your last email you send me a screenshot, which can not be read.

Yes it appears small, but you can click on it to enlarge it.  This is also why I uploaded the .tdc file so that you can dig into the details.

Arne Friebel said:

The link you send me leads to an Error page.

Not sure what is going on here.  I tested the link after posting and got an error but I immediately corrected the links a few minutes after posting - and given the time it's probably unlikely that you got in during the interim.  But they are working now for me.  In case they still don't work for you the exact URLs are:

http://processors.wiki.ti.com/index.php/HALCoGen_USB_Device_-_driver_%26_CDC_Class

http://www.totalphase.com/products/beagle-usb12/

Arne Friebel said:

All time you told me to use the HDK and the CDC Software, but honest your customer does not want to buy the HDK for USB connection. And it leads at the end to the fact, that we have to implented on our board.

Arne Friebel said:

Then you send me the information that the port is powered down by the HCRHPORTSTATUS1. Really, a status register, where a few bits can be cleared...you are joking. Have you looked at the register description.

Arne Friebel said:

I am still on the point of my first email. I do not get, any address state interupt or a setup interrupt...thats the problem...so the USB device will not recognize the incoming frame.

The address setup interrupt is too far in the enumeration process to be a problem.   Are you getting the first two interrupts that I pointed out in the last response?    If you are getting these then you should be seeing something come out of the device port in response to 'Get Descriptor' or else there is some problem in how the descriptor is being written into the FIFO.   Given that you are sure GZO never is active, you definitely are not getting past this point, so I don't think it makes sense yet to focus on the interrupt for the address state.

The interrupts for various messages are listed in the TRM although to me it is easier to follow the working example.

For example GET_DESCRIPTOR's interrupt is described here:

32.3.7.4 Non-Autodecoded Control Read Transfers
Non-autodecoded control read transfers include the GET_INTERFACE_STATUS,
GET_CONFIGURATION, GET_INTERFACE, GET_DESCRIPTOR, SYNCH_FRAME and class- or
vendor-specific control read transfers. Non-autodecoded control read transfers consist of three stages
(setup, data, and status).
The setup stage of a valid non-autodecoded control read transfer consists of one SETUP transaction from
USB host to USB device. At the end of the setup stage handshake, the USB module generates a CPU
general USB interrupt with the IRQ_SRC.SETUP flag set. The CPU must respond to this general USB
interrupt by setting the EP_NUM.SETUP_SEL bit, which clears the setup interrupt flag. The CPU must
then read 8 bytes from the setup FIFO via the DATA register, clear the EP_NUM.EP_SEL bit, and check
the IRQ_SRC.SETUP flag. If the IRQ_SRC.SETUP flag is set, the CPU must discard the setup data it has
just read and handle the new setup data packet following the same scheme. If the IRQ_SRC.SETUP flag
is cleared, the CPU code interprets this request information and then prepares data for the IN transaction
that follow. This includes placing the data being requested (or the first few bytes, if more than one FIFO
worth of data is being returned) into the endpoint 0 FIFO, and setting the CTRL.SET_FIFO_EN bit.

SET_ADDRESS falls under the 32.3.7.1 Autodecoded Control Write Transfers,  and as figure 32-55 shows, there are no interrupts for the auto-decoded transfers.   You should check though that you do not have autodecoding disabled.

Arne Friebel said:

Which setting must I made via initialization

Arne Friebel said:

How can the set_address or get_descriptor host command fail

Arne Friebel said:

How about the usb reset initialization

Arne Friebel said:

Why does the GZO will not change to drive mode

Arne Friebel said:

I would like to have the support from another person, who can really me !!!!!

Arne,

I will call you at this number to discuss how we can help.

0049-7731-9332-16

Regards,

Dave