C6747 USB0 Device operation

Now I am trying to check if USB interrupt is run when I connect the usb device to PC host, i use the code above, and DSP Bios where I connected HWI_INT6 to event 19 which is responsible for USB0 interrupt, the code in interrupt does nothing or sth like 

volatile Uint32 i =0 ;

i++;

Just to set the breakpoint and check the status of registers,

Unfortunately breakpoint is never reached, again am I missing something ? 

There is already plan to have support for USB in BIOS environment from TI.  Can you not use this release for your product.

regards

swami

When will the USB BIOS driver be released? It would help us much if we could show a running application (with no Linux code)  to use it in product, or at least see how it is builded, and how the hardware is handled.

Pl. contact your TI FAE for the information on the same.  Pl. note that the BIOSUSB release will be in binary form for the most part and only example applications will be available in source format.

regards

swami

Thanks for the replay. I think I can't wait for TI BIOSUSB package, especially if it is in binary format. 
I am still developing the USB device driver on my own, and came across strange problem.

When the software should really SET_ADDRESS – in documentation it is stated that it should be done in next status phase, which occurs in next interrupt ( that is my assumption) But when I even do that, I got no status phase in SET_ADDRESS command, 
Not setting address will result in discarding next packages because of wrong address. 

I can not find any more information on STATUS stage in 

http://focus.ti.com/dsp/docs/dspsupporttechdocsc.tsp?sectionId=3&tabId=409&abstractName=sprufm9b

or  direct link 

http://focus.ti.com/lit/ug/sprufm9b/sprufm9b.pdf

only info available is on page 22 and on Figure 4,5 on page 25 

any help would be very appreciated 

It seems to work right now, but there is another problem. Addres is set on the device but USB IC seems to don't accept any new requests on new address, the Host will then reset the device and story goes 3 times all over again. I can see all that on USB analyzer but from logs on DSP, I don't see the requests with new addresses so they are silently discarded by USB IC. Any iddeas why is that happening ?

Krzysztof Kanas said:

It seems to work right now, but there is another problem. Addres is set on the device but USB IC seems to don't accept any new requests on new address, the Host will then reset the device and story goes 3 times all over again. I can see all that on USB analyzer but from logs on DSP, I don't see the requests with new addresses so they are silently discarded by USB IC. Any iddeas why is that happening ?

Moreover I think there is USB reset inerupt occuring after status stage of SET_ADDRESS command and next interrupt.

I stumble on another problem, I don't see mentioning how it is posible to NAK the response to Host in Perypherial mode.

I solved previous problem and couple of others. But I have some trouble using data toggle feature in USB device for not EP0 endpoint.  I checked the USB standart and performed data toggle on set configuration and Celar endpoint feature, but I get not send packets or don't get data interrupt on OUT enpoints. I think this is caused by Clear endpoint feature, is there a way to check Data toggle on specyfic endpoint ? I see that USB is able to set data toggle to data0 . Or any other way to diagnose the problem.

Still this is about USB Device and I am using DSP bios, not using DSP Bios USB package.

Problem sovled, but the clear endpoint feature was not only issue, so there was cumulative number of errors and it was harder to trace acctual issue.

I am trying on the same thing and having similar problems on C6745 custom board. The first problem is that the usb_isr isn't called when I plug in the usb to usb0. 

One difference is that I am using internal PLL clock from 24M xtal, so my USB2PHYCLKMUX = 1.

My tcf file has

bios.HWI.instance("HWI_INT6").interruptSelectNumber = 19;

bios.HWI.instance("HWI_INT6").fxn = prog.extern("usb_isr");

My usb_init and usb_isr are at http://docs.google.com/View?id=ddskp47r_35gwz3qhhs

More investigation seemed to suggest the HWI isn't triggered at all. So am I doing this correctly?

• bios.HWI.instance("HWI_INT6").interruptSelectNumber = 19;
• bios.HWI.instance("HWI_INT6").fxn = prog.extern("usb_isr");

Is there anything else needed?

I can see USB Interrupt Source Register (INTSRCR) changed to 0x000D0001 after I plug or unplug.

Also the EVTFLAG0 turned into 0x00080000 after CSL_FINS(usbRegs->POWER,USB_OTG_POWER_SOFTCONN,1); and stayed at 0x00080000 forever until a system reset.

Have you enabled interrupt HWI6, you can see it by checking INTER (or sth simmilar)

C64_enableIER(C64_EINT6);

you can use this line by including some header files

#include <hwi.h>
#include <c64.h>
#include <c6x.h>

probably this should be sufficent.

I have more less working project but I stumbled again across SET_ADDRESS bug this time it occurs differently

1. when I am using USB Hub and I have disabled SOF intterupts form USB, I set the addres in next Interrupt - I think this is Status stage when I should write it to FADDR,  But on USB analyzer I see that Addres was set and transaction compleated but next transaction are unable to comply because I get no respose from DSP USB interface, next after reset as windows error handling I see that I still get no resoosne to addres 0 - I think this is because I have addres already set as 6 (not zero) so I dont get innterupt.

2. Second case the same but I set address at the time I got from USB driver, but then I am unable to compleate succesfull set addres commmand b/c it is for addres 0 not 6

I have couple of other case but I think it boils down to this when I should set address command, or when is status stage of request.

Hi,

The sample code you displayed below is a working code. Just make sure and check if you are properly configuring your system.

For operating in Device mode you need to insure one of the two setups are followed:

a. If you are using the USB ID and USB VBUS pin, then you need to insure that the USB ID state is pulled high on your board or the type of connector you are using is mini (micro)B connector. Also need to insure that there is a valid Host and is supplying the required 5V supply. You need to insure that you are not overriding the PHY and ensure your CFGCHP2 register setting.

b. If you are bypassing these pins, i.e., you are not using the USB ID and VBUS lines and you are overriding PHY values, you need to communicate to the core that via CFCHIP2 Register.

As a Device the OTG Controller operates in Full- and High-Speed only (per usb 2.0 spec) and the D+ is required to be pulled high. D- should not be pulled high since this is a Low-Speed device settings and do not expect to see this. The USB core has internal Pull-Up that it enables when it observes that the state of the USB ID pin is high.

Assuming that you have enabled the USB Clock and CFGCHIP2 register configuration has taken place correctly reflecting Device mode of operation, when you set the DEVCTL.SESSION bit field, the USB Controller will determine as to the role it is to assume (Device or Host) by sensing the state of the USB ID pin and if it is high, it will assume the role of a Device. For debug purposes, you can place a while (1) statement after you set this bit and observe if the DEVCTL.BDEVICE bit is set along side DEVCTL.SESSION (you need to be in session for DEVCTL.BDEVICE bit field to indicate the correct state of the controller). Note that since the controller needs time to sense the USB ID pin and assume a role, this takes some time and you need few thousands of CPU cycle prior to the register setting to reflect the correct state.

The only reason that the device could not go into session is if the above configuration is not followed correctly. The CFGCHIP2 register has other fields that are in relation with clock frequcy and you need to insure all that is configured appropriately.

I will comment further once you have passed this stage.

Best regards, Zegeye

Hi,

I replied to your earlier question instead of the follow up. It seems that you have already passed the USB Controller assuming the role of a Device. By the way, both the old and the new code should work.

I think the problem with your SET ADDRESS command execution is the time that you are configuring the FADDR register. You most likely have configured the new address prior to SET ADDRESS command completion.

The following captures the steps that is followed for SET Address Command. The referance to Device Application is what your application should do.

**** SETUP Stage of the SET ADDRESS Command ******

* Host sends a SETUP Packet with Address Value imbeded within the 8 Byte SETUP Packet.

* Device Controller Sends an ACK to the Host acknowledging the reception of the SETUP Packet.

* Device Application receives Endpoint 0, receive data, interrupt from the USB Controller.

* Device Application reads the 8 Byte request and within that 8 Byte add and determines that it is a SET ADDRESS Command.

* Device Application indicates to the core that it has read the 8 Byted request/data from the Host by writing 0x40 (serviced RxPktRdy) onto USB_CSR0 and also also indicates that no Data Stage will exist by setting the DataEnd bit field within USB_CSR0. Note that you have not yet updated your FADDR register with the new address.

**** NO DATA Stage exists for SET ADDRESS Command ***

**** STATUS Stage of SET ADDRESS Command ****

* Host now starts the Status Stage by sending an IN Token (note that Host is still using Address ZERO). I think you are not responding to this packet because by this time your FADDR setting has changed from ZERO to the new Address. This should remain set to ZERO at this stage.

* The USB Controller will sends a NULL Data Packet to the Host signifying an acknowledgement to the Host.

* The Host will send an ACK Packet back to the USB Controller.

*The USB Controller will generates an interrupt to the Device Application that the Command has executed properly.

*The Device Application will now configure the FADDR register with the new Address.

Best regards, Zegeye

Hi,

Thanks  for anwsering, the transaction goes as you described, and I have code working by that design. I wanted to make sure if I got it right.

Best regards, Chris

Hi, 

I have another problem, after switching from evaluation board to prodcut board USB controller seems to not work. Processor is more likely the same - before I was using C747 in board OMAPL137 now I am using C6748 in omap L138. 

I am pretty sure I did everything ok. 

I turned on Power domain responsible for USB0 turned on PINMUX responsible for Clocking the USB PLL. 

Turned on USB PHY setup PLL provided PLL and waited till PLL clock is stable as in usb_init from first post - but USB controller doesn't invoke interrupts on DSP processor. 

Right now the USB interrupts that are invoked are USB SUSPEDN and USB resset babble , and SOF. 

I see that Windows picked new device on USB line. So the soft connector on USB worked and D+ or D_ line pullup was turned on. But was unable to enumerate it properly as I haven't got any EP0 interrupt (I am not responding and don't send ACK to Host transactions) 

When I manually invoke interrupt my DSP interrupt is beaning invoked and processed. 

Is there anything I could miss ? I think I am still missing something in the Initialization code but I am not sure what ? 

 

Ok corrections - USB controller don't see SOF and probably isn't pulling up the apriopriete Data line for USB detection, that is (probably) fault of external hardvare I am using.

Hi,

You are describing the configuration where c6748 is assuming the role of a Device and you are connecting to an external Host.

You also have mentioned that the Host has detected the USB Device and and also enabled the RESET interrupt.

It seems you have done things right but need to go back and double check.

The first Interrupt you are supposed to receive when operating as a Device should be a RESET interrupt. You should not be receiving EP0 interrupt. As soon as the Host sees a Device connected to it (for our Device that would be the D+ line pulled high since as a Device USB 2.0 spec requires the support for Full- and High-Speed operation only, not Low-Speed and D- will never be pulled high - just want to convey), the Host would place the attached device in Reset by pulling both D+ and D- line low. This should trigger a RESET interrupt on the USB Device, which is an indication for the user to start configuring the core. At times, you could be receiving several reset interrupts and your code should be robust enough to handle this condition. Since RESET will wipe out some of your register settings, you need to perform a full USB Core initialization when receiving a single or multiple reset.

Please ensure your Device intialization as well as RESET interrupt enabling task is in place prior to proceeding. If you still are having a problem, capture your PHY configuration settings as well as POWER and DEVCTL register settings after the controller is in Session (DEVCTL.SESSION will be set when the controller is in session).

Best regards, Zegeye

Hi,

thanks for anwsering. I finaly figured out where problem was. It was because using some external multiplexer chip that is responsible for mux of USB lines. Unfortunetly on startup because of this chp I am recognized as some device on the line and that way enumeration starts up. I don't get interrupts becuse of the lines aren't acctualy connected to the bus.

I got another question - relatively simple I think. It is about USB clock for USB PHY - the clock input should be exactly as CFGCHIP2.USB0REF_FREQ bit (so either 12Mhz, 24 and so on). Or is it like that you provide some clock to USB PHY and it locks on specified frequency specifed by CFGCHIP2.USB0REF_FREQ ?

Hi,

Yes, you are correct. The clock generated should be precise and its frequency is communicated via CFGCHIP2.USB0REF_FREQ bit field. The PLL is only aware of the MULTIPLIER value to use in order to generate the UTMI Clock (60 MHz) and bit clock (480 MHz) clock from the supplied input clock. So, if you supply a 12 MHz clock and communicate to it as the clock frequncy is 24 MHz it is going to be generating a 30 MHz and 240 MHz operational clock frequncy which of course will not work.

Best regards, Zegeye

Hi,

Observed that you have mentioned that you have a multiplexer on your data path. I do not see how High Speed operation will work if have inserted another device in the middle of the data path which will cause a severe signal quality degradation. The only way I see your setup working is if your multiplexer is a Hub like device. So, be ware on signal integrity issue on your design.

Best regards, Zegeye

Hi,

Based on the code snipset you posted above, you are not overridding PHY values, which is a good thing for your setup. So, there is no problem with your code. Just make sure that you are indeed not overriding the PHY values.

     BootCfg->CFGCHIP2 &= 0xFFFF9FFF; // 00= > Do Not Override PHY Values

You do not need to clear the SOFTCONN bit either. That is not the problem here. The SOFCONN  bit allows you to perform Soft Disconnect from the Bus when desiring not to perform a physical disconnect. So, that is indeed not the problem.

You are also observing the right Register Field, DEVCTL[4:3], to observe the Voltage level on the VBUS line.

I am suspecting that there is still a Voltage on the VBUS. The PHY is observing a Voltage above 4.4V on the VBUS line, based on the field value you observed, and the Device thins that there is still a presence of Host out there. Most likely the DVCTL[SESSION] bit field is also set. Please check this too.

Assuming that the above is true, the quickest way to debug this issue probably is by you directly grounding the VBUS line after physically disconnecting the VBUS from the Host. The PHY should be able to detect the Voltage level and report to the controller and the DEVCTL register settings should reflect the correct voltage. I am also expecting that you should observe a Disconnect Interrupt when the DEVCTL[SESSION] bit clears, that is the Voltage on the VBUS is removed.

Do the above and if the device behaves accordingly, you need to debug your board ckt. Let me know what you have populated on the USB lines.

Best regards, Zegeye

Thanks again for your help, I indeed have overridden

  BootCfg->CFGCHIP2 &= 0xFFFF9FFF; // 00= > Do Not Override PHY Values

to  slave operation and, again there was some hardware error so Vbus line was powered somewhere from inside the board.

The advice was very helpful.

Hi,

Are you using Internal or External Clock source? Regardless, with the clock source, you need to insure that this clock source is acurate. Please confirm. You have not mentioned if you had performed a h/w change or not.

Also, from the code snipset you have shown above, I can not tell if the CFGCHIP2.USB0REF_FREQ(bits3:0) field is 0x4? The value of 0x4 will inform the USB PLL to generate the right UTMI clock and bit clock.

In summary, you need to have a clock source of 19.2MHz and need to communicate this frequency via CFGCHIP2 for proper clock frequency generation.

Best regards, Zegeye

kanas

Please refer to the following sequence to configure usb phy .

#define CFGCHIP2_USB_PHYCTRL 0x01C14184

     unsigned int reg = 0;
    *(volatile unsigned int *)CFGCHIP2_USB_PHYCTR = 0x09F2;
    reg = *(volatile unsigned int *)CFGCHIP2_USB_PHYCTR;
    reg |= (1 << 4) | (1 << 5) | (1 << 6) | (1 << 8) | (1 << 11);
    reg &= ~((3 << 13));
    *(volatile unsigned int *)CFGCHIP2_USB_PHYCTR = reg;
    while (!(*(volatile unsigned int *)CFGCHIP2_USB_PHYCTR & (1 << 17)))
        ; \

Regards

Ravibabu

Thanks Zegeye for answer as for question I have CFGCHIP2.USB0REF_FREQ(bits3:0) field set to 0x4 for 19.2Mhz frequency,

For Ravi B, I have similar initialization  but I set (clear the CFGCHIP2 fields not simultaneously) but I don't think it matters because the frequency locks

  while (!(*(volatile unsigned int *)CFGCHIP2_USB_PHYCTR & (1 << 17))) - the processor isn't stuck on that line.

I guess that USB controller goes into suspend mode and is unable to get out of it,

In the initialization above there is setting bit of POWER register for UTMI signaling, what is it ? I couldn't find this in USB spec for Freon.

I think the controller is configured good but I observed that the soft connection bit don't turns on the resistor on the line so no interrupts are generated and no request are sends.

The code for enabling the SOFTCONNECT resistor is

void softconnEnable(){

 usbRegs->POWER |= (1<<6);
  while ((usbRegs->DEVCTL & 1) == 0);
 }

Hi,

Thanks both. I am replying based on the preceding messages. Just to make sure we are all on the same page, what you are trying to attempt is to operate c6747 on Device mode and you have changed the clock source to 19.2MHz and is now unable for the device side to operate. Please confirm.

The POWER register definition is given in Table 53. The SOFTCONN bit allows the user to connect and disconnect the Data Lines from the bus, which should result with an identical situation where a live device is connected or connected onto a USB system.

Assuming that your Device Initialization is correct, the reason DEVCTL.SESSION(bit0) is not set is because the USB Controller is not seeing a VBUS VALID Voltage on the VBUS line. It thinks that there is no Host out there. So, please first check is if the Host is sourcing power on the VBUS line.

For proper operation, this is what I am expecting to happen.

a) As soon as you set the POWER.SOFTCONN bit, the Data Lines are going to be connected to the controller.

b) Assuming a working Host presence, like you mentioned, it will be driving both data lines low via a 15K ohm resistor and the Host is also sourcing 5V on the VBUS line.

c) c6747 USB Controller will see the Power on the VBUS line and it will set DEVCTL.SESSION bit. This will kick the controller to start sensing the USB ID state and configures itself, as a Device in this case. (Note that this is the handshake that a Device uses to detect a Host presence, Voltage on VBUS line.)

d) When it gets configured as a Device, it will enable the 1.5Kohm pull-up on its D+ line.

e) The Host will detect that the D+ line has been pulled-up and realize that a Device is connected. Its Connect interrupt will be triggered. (Note that this is the handshake that a Host uses to detect a Device presence, D+/- line going high.)

Based on the above steps, I agree with you that the pull-up on the D+ is not enabled (step d). But for that to happen the preceding steps have to be true. So, please check step b.

Thanks and best regards, Zegeye

Thanks for replay.

To clarify setup I confirm  I am still trying to run device mode of operation of USB stack on C6747. I have changed the clock to 19.2MHz and the driver is unable to operate.

I have used your advice before and I do not force the mode of USB operation, so I am able to sense USB_VBUS by DEVCTL reg and is reporting above VBusValid.

I have checked the level with multimeter and VBus is about 5V.

 Before SOFTCONNECT register  the DEVCTL.SESION bit is logical 0, and after enabling  SOFTCONNECT register  the DEVCTL.SESION bit is set to logical 1.

Is it possible that is hardware problem ?  Either D+ D- lines aren't connected to physical bus or something like that (Edited) I have checked and I think there is connection of D+ and D- to the physical bus.

I think SOFTCONNECT setup is good because also bit in CONFIGDATA.SOFTCONE is set to logical 1.

Update: I checked my previous version of code on EVM138 (or OMAP138)  with 24 MHz clock and different processor, and no USB mux, and it works, the initialization procedures are similar except the frequency and the MUX hardware. Last possibility is that - some module not regarding the USB is undoing my work ( I load more drivers than only USB) because hardvare switching is good. Also Initialization of processor is changed, but I don't seem to find easy connection to what can be undoing my work.

I have next question not related to that problem,

It is about USB hardware, I think I missed something or something else suggested me wrong. But Is it possible to USB Enpoint different than 0 for TX and RX at the same time ?

So Endpoint would be presented during enumeration as IN and OUT eg. configuration 1 EP 1 IN and still in the same configuration EP 1 OUT

Hi,

OK. Thanks for your confirmation. We also know Power is sourced. Now the one thing we need to identify is if the USB Controller truely assumed the role of a Device.

Follow up questions:

1. Does the driver work with other clock frequencies?

2. Have you tried connecting it to a Desktop/Laptop Host and see if it is being detected?

3. What is DEVCTL.BDEVICE content after DEVCTL.SESSION  is set to 1 (please allow some time like several thousands of CPU cycles prior to capturing the state of DEVCTL.BDEVICE)?

4. Do not clear any interrupts and observe the content of INTSCR register for interrupts flags coming at the time you are on step 3. This will tell us error condition and also other stuff like in case it is attempting to configure itself as a Host, etc. in stead of a Device.

Best regards, Zegeye

Hi,

Unlike other endpoints, Endpoint 0 is a special endpoint and is both IN and OUT. That is why it has a single register for control (for both Tx and Rx) and a single flag for interrupt (for both Tx and Rx), etc.

For the issue you are having, you only require the initialization that you have performed. Endpoint 0 resource is allocated by H/W and is ready all the time. So you are OK with that, at the minimum the first Token Packet will be acknowledged by the H/W provided that the Host sent a Token packet. But in your case, you are not here yet. You are not even getting a RESET interrupt from the Host.

It would be helpful if you have a bus snooper to detect bus activity. We would need to quantify if the Host is seeing the Device and Vice Versa (is one seeing the other but the other one is not or may be both are not seeing each other, etc...?). If Controller assumes the role of a Device, it has detected the presence of a Host, it will enable its pull-up and also update its status register bit fields like DEVCT.BDEVICE. If the Host detects a Device, it will attempt to RESET the attached device. By you trying to connect the c6747 with a Desktop Host, will confirm the the c6747 has assumed the role of a device and the c6747 device has enabled its pull up on the D+ line.  This also confirms that the Host is attempting to Reset the Device but the c6747 device is not seeing the RESET, etc.

If you want you can send me a snapshot of your schematics and layout if you have one and we will see if any possible H/W issue exists. So long as your PHY Iniitalization and ID configuration is done right, there is not much needed for detection to take place.

Best regards, Zegeye

Hi, thanks for help

Some answers

1.  Driver should work with other clock frequencies as only clock dependent thing is USB and I set the clock right in CHIPCFG2 |= 0x4 ( and the other bits as well too)

2. I have tried it and it's never gets recognized - except when I switch between the lines - there is hardware error because of which device get recognized but this is only happening when D+ and D- are disconnected from the USB bus - so that really not concerns me  as it is known issue

3. DEVCTL.BDEVICE is set to 1 so this means that we are B device or simply Device after  DEVCTL.SESSION is set to 1.

4. I do not clear any interrupts,and they are setup earlier so I should get Interrupt service routine working ( I have breakpoint there ) but it is never ran.

I have USB analyzer and excluding the situation from point 2 there is nothing going on USB bus. To that point that when my code is in USB mode and performs soft connect and disconnect the analyzer is never triggered ( I tried various settings for trigger but it never gets fired)  My suspect is that the D+ D- Lines are somehow not connected to the USB bus and that is why PC host don't start the enumeration. For schematic I think it sufficient to say I use TI High Speed USB 2.0 MULTIPLEXER/DEMULTIPLEXER switch, http://focus.ti.com/docs/prod/folders/print/ts3usb221.html nothing more is connected to Data lines (as VBUS lines are sensing correctly)

That question was related not to my problems from above but rather to hardware possibilities. I know that Endpoint 0 is bidirectional (In/Out) but I have never came across hardware that had EP1-4 that can be IN/OUT at the same time. Is this possible, for me it is little bit strange but I may be suggested the previous hardware configuration.

So in summary configuration shown during enumeration that EP1 is IN and have  size 512  and in the same configuration EP1 is OUT and have size 512 is good configuration  regarding the C6747 and the USB chip available there.

Hi,

I think we are miss-communicating here. May be you answered my question but I am still not getting it.

1. When I am referring about the Driver I meant to refer to the USB. Refrasing my question: Does the USB work with other input clock source? I have seen past questions from you and this was no problem and was wondering if the change was only clock frequency change. So, has the same initialization code, of course with the difference in CFGCHIP2 register only, was working with other input clock frequencies? It is always good to get the right answer than assuming, which is the reason I am asking.

2. About the interrupt. What you need to do is Enable all interrupts from the Core level (INTRUSBE, INTRTXE, INTRRXE) and Mask all interrupt from the Wrapper Level (INTMSKCLRR is set to 0xFFFFFFFF). You do not have to have an ISR or ISR running. You can either run a while(1) where you are waiting for a RESET interrupt and after running the initialization code, observe if any of the INTSRCR bits are set. This will tell us if a change of event has had happened and the cause of the change of event, if there exists.

3. Good that you are monitoring the Bus. If you are seeing no activity on the bus, that means at the minimum Host is not seeing the Device. Like you mentioned, since the D+ line is not being pulled high, the Host is not seeing the Device. The Device is seeing the Host since you mentioned that the VBUS voltage is communicated to the controller as being above VBUS Valid. Based on your #2 comment, I see why you commented that the USB is in Suspend some emails back.

Would you please try the following?

* Do NOT Set the Soft Connect bit.

* Set the SESSION bit yourself (it is OK to do this since it is an OTG core). This will force the SOFTCONNECT Bit to be set and let us see if this makes a difference.

 -----------------------------------------------------

About you Endpoint question/remark (I assumed you were basing the question for this particular issue): Endpoints other than EP0 being both IN and OUT are not part of the spec and do not exist. For e.g. EP1-IN and EP1-OUT are two different endpoints, unlike EP0. For this reason, the design treats them as separate targets and design will allocate separate resources. In our design, only the FIFO resource can be shared amongst an IN and OUT endpoint, all other resources are differnt (as an e.g. they both have dedicated TxMaxP for OUT and RxMaxP for IN max packet length for max packet length supported). In our design I can only think FIFO sharing to be the only common thing that is available and this is only important and meaningful if you are running low in FIFO RAM space.

Best regards, Zegeye

1.  I have seen the USB chip(or IC I perfer that terminology instead of driver)  working but with Linux Driver with another frequency 19.2Mhz, the code is obviously different from my driver but it should prove that USB chip should work with another frequency. Unfortunately the test was done not on my board - I did the same thing with Linux on my board but with 24Mhz and it didin't work but some time ago the driver worked. I will investigate more after the weekend but that is more likely hardware issue.

2. I have interrupts set as for normal work and they worked on 24Mhz so nothing changed here,  rest will be answered at 3

3. I tried to do according your advice

so I

* Didn't Set the Soft Connect bit.

* Set the SESSION bit yourself (it is OK to do this since it is an OTG core). This will force the SOFTCONNECT Bit to be set and let us see if this makes a difference.

I managed once and only once to receive interrupts the one I got were from USB core

USBCORE.SESSREQ next

USBCORE.SESSREQ next

USBCORE.RESET_BABBLE next

USBCORE.DISCON and that was last interrupt I received. Unfortunately at that time I wasn't using USB analyzer so I didn't actually saw what happed on USB BUS but I think that was it.

Next I tried to re running the whole experiment again and I was unable to get the same result

-----------------------------------------------------

About Endpoint remark, So it is possible to use EP1 IN and EP1 OUT at the same time, that is waht I thought after looking deeper into USB Chip specification. But also I found in USB standard statement like this

"

A USB device has one or more configuration descriptors. Each configuration has one or more interfaces
and each interface has zero or more endpoints. An endpoint is not shared among interfaces within a single
configuration unless the endpoint is used by alternate settings of the same interface. Endpoints may be
shared among interfaces that are part of different configurations without this restriction.
Once configured, devices may support limited adjustments to the configuration. If a particular interface has
alternate settings, an alternate may be selected after configuration.  
"

This should be at page 293 of USB specification available at http://www.usb.org/developers/docs/usb_20_052709.zip  ( I may have used older version). So if we want to have driver that is USB compliant it should not use EP1 IN and EP1 OUT at the same time ? So we would waste some of hardware resources. I am no expert on USB compliance test so I may be wrong.

Hi,

I forgot that you have a switch on the bus. This might change the behaviour.

It seems that it started being recognized and the Switch started to reset the c6747 Device and suddenly got disconnected.

I do not think this is going to make a difference and probably result with the same outcome of your previous experiment but atleast would allow us to understand the issue better.

* Please go back to your previous configuration, i.e., after setting the SOFTCONN bit, set the POWER.RESUME bit.

*Clear it between 10ms and 15ms CPU time.

About endpoint usage:

The information you mentioned agrees with the info I was attempting to pass across on my previous email. EP1-Tx(OUT) and EP1-Rx(IN) are different resources and they can be used on the same interface. You are OK, you can use all the endpoints supported (EPx-Tx and EPx-Rx) if have the need for it.

What they are saying is that you can not multiplex the use of an endpoint, i.e., use multiple configurations for the same resource (as an example EP1-Tx). Once the Device and Host agree the usage of EP1-Tx configuration during enumeration (say for e.g. for EP1-Tx to be used as Bulk-Out endpoint with a max packet size of 512 bytes) you can not change this attribute of EP1-Tx for it to be used for an Interrupt transfer (or other Bulk EP-Tx with different max packet size requirement). That is not allowed, not to say it is impossible, unless you have a total control of both the Host and Device driver operations. If you have control of both Host and Device drivers (a custom unique solution) you can do whatever you want since you will have your own underline protocol built in within your Host and Device drivers to signify change of EP usage assignement as needed. What I am saying is that this restricition is from S/W or Usage perspective not H/W.

In fact when using the controller as a Host, we multiplex the use of Endpoints. The Host needs to do that in order to be able to communicate with multiple devices. Otherwise it will be preety much impossible to connect to multiple devices with out this capability.

In summary, since you are using the controller in Device mode,  you should not multiplex the use of endpoints but can use both EPx-IN and EPx-OUT endpoints since IN and OUT endpoints are different resources.

Best regards, Zegeye

Hi

I thanks for help, especially for the endpoint clarification ( I haven't seen that many USB devices). For the Pull up connection Issue I found out that it is hardware related not code fault. I changed the board for another one and it works. I am not sure what could be the problem but I am guessing that there was some connection to the ground with 1M Ohm resistor so even if the pull up was connected the data line was held low.  That's my guess I haven't had the time to check it.

Hi Krzysztof

I am working on the OMAP L137 - DSP side and i need also to developp my own USB driver.

I am facing the same problem as you detailed few posts before. I am using my own RealTime OS and I am trying to check if USB interrupt is running when I connect the usb device to PC host. I am using the same initialisation routine as you and I connected an HWI interrupt to event 19 which is responsible for USB0 interrupt

The internal USB registers show that the interruption endpoint 0 occurs : INTSRCR = 0x1. All interrupts are enable and non-masked. But the DSP USB0 interrupt never occurs : the EVTFLAG 19 still 0 and IFR also.

I am wondering how you solved your problem ? Did i miss something ?

Thanks for your help

Regards

Have you enabled the Interrupt mapped to Event 19 - so your Interrupt routine will run ?

I think this is IER register in the processor,  I think that can be source of your problems.

So you should map Event 19 to some interrupt number and then Enable IER for that number.

I am not C67x expert but It shows that USB controller  interrupts are working but core processor is not receiving them. And I think all of them are disabled on the start

IER is enabled for that number. The interrupt mapped to Event 19 is enabled.

It should work but it is not the case and unfortunately I do not know why.

I am wondering what was your problem at the beginning when no interrupt occured ?

With your experience on this component, how many time do you need to developp a USB driver ?

Thanks a lol

Hmm from code posted above I think you should also reset USB controller on the start before doing any work, I think that code example how to initialize USB controller works posted under usb_init3()

 For the time to develop question I can answer only with question :

For what role will be the driver used :

Host or  Device or OTG ?

If device there is question what will be the driver on the other end (host driver linux or Windows or sth else), if it will be a standard driver or  vendor specific.

I don't have much of experience  with that because I used some older code from different platform so my job was rather porting the hardware change to old USB driver code

Hi,

You mentioned you are observing that INTSRCR is set to 0x1. This signifies an Endpoint 0 Interrupt.

By this I am assuming that you have already passed the Device Detection period and are starting or are in a middle of enumeration. I am wondering how your setup handled the interrupts prior to Endpoint0? You should have atleast received a Reset Interrupt. INTSRCR register would have displayed values other than 0x1.

It would be good to start from the beginining. I agree with Krzysztof suggestion. You need to ensure you have gone through proper initialization to insure that USB Interrupt generation event would not be the cause of your issue.

Please check the followings?

You mentioned, INTSRCR has captured event change. How about INTMASKEDR? Do you see the same flag set there?

Make sure CTRLR.UINT[bit3]=0. If INTMASKEDR flag is set then a USB Interrupt event will be sent to the Interrupt Handler. This would allow you to determine if the issue you are having is from the USB side or Interrupt Handler configuration issue on the DSP side.

This thought just occured to me. Also make sure you write ZERO to EOIR register after handling your interrupt.

Best regards, Zegeye

Thanks both of you,

I used the OMAP as a USB device, so i want to developp a USB device driver. My PC is the host with a host standard linux driver inside.

I have not yet big experience on USB using. Consequently, I am not sure but i guess that the device detection period is already passed because when i halt DSP :

- By checking the registers, the USB seems correctly recognized as a device (DEVCTRL = 0x99)

- My registers have the following values inside INTSRCR = 0xD0001 and INTMASKEDR = 0xD0001. That means the enumeration started.

My problem is that even if INTMASKEDR = 0xD0001, no event is generating on the DSP side.  The HWI interrupt is linked with the USB event. It is enabled and ready to work.

But it does not work. No interrupt is generated on the DSP side, because it seems that no USB event is generated. CTRLR is correctly set with UINT = 0.

You asked me to write ZERO to EIR. Okay, I effectively read that in the documentation. But could you said me the role of the register INTVECTR ? I am not able to find any help in the documentation.

Thanks you

Regards

Alex

Hi,

I agree there is not much info on INTVECTR. This is identical with INTSRCR. Please ignore this register. In fact it might be useful to mask this register as Reserved because it has no use for users. Sorry for about the confusion.

You need to check your interrupt handler setup and ISR. It seems that your have already received the interrupts and they have not been serviced or acknowledged after being serviced.

Any interrupt recognized within INTMASKEDR will be sent to the Interrupt Handler. You have recived RESET, Start Of Frame, and Suspend Interrupts in addition to Endpoint 0 Interrupts and it is highly probable that your Interrupt handler setup or ISR is the cause of the issue.

Best regards, Zegeye