C6747 USB0 Device operation

Small note as you mentioned Linux host PC used for setup.

Try using usbmon, it is available from some Linux kernel (but probably recompiling the kernel will be necessary) see some external site for usage of usbmon. I have not used it, but it should provide you some basic info about what is going on on USB bus. I am not sure what kind of events on USB bus you can snoop with it - maybe you will see start of enumeration process as it seems EP0 interrupt occurred. Alternatively you can use USB analyzer but those don't go cheap as usbmon. 

Easy check for interrupt occurring is setting breakpoint in ISR routine when EP0 is set, but I guess that isn't working.

As per USB driver you have to know what you are against because driver differ in complexity and compatibility.

The baisc part as Enumeration process is similar to all devices  but during enumeration device provides it's USB configuration which tells what kind of driver it is and other parts like number and kind of endpoints used etc. This differ for each driver type, secondly you have to consider if there is USB driver for linux for that kind of device you are trying to write because if not you probably will end up in developing one.

Hi

I understand from your mail chain, you are not receiving the interrupt at DSP level. Can you verfiy the interrupt setup sequence are correct . I have provided the code snippet of interrupt setup for musb.

#define MUSB_IRQ_NUM         19
#define MUSB_IRQ_EVENT       7

musb_Isr_setup()
{

 ECM_Attrs ecmattrs = {0, 1};   

 ecmattrs.arg = Isr_args_data;

 ECM_dispatchPlug(MUSB_IRQ_NUM, musb_isr_func, &ecmattrs);
 ECM_enableEvent(MUSB_IRQ_NUM);
 C64_enableIER(0x1 << MUSB_IRQ_EVENT);

}

Regards

ravibabu

Hi,

I am receiving now  the interrupt at DSP Level. I had a problem in my own interrupt vector due to my own OS. Thanks.

Now, I took a look on the informations received during the first interrupt and i do not understand. At the first entrance in my ISR routine,  INTSRCR =0xd0001. That means i received RESET interrupt, SUSPSEND Interrupt, SOF Interrupt and EP0 interrupt. I do not understand why ? Normally i should be receive only reset interrupt and that's it.

As i received an EP0 interrupt - 8 bytes, i read 2 times FIFO0 buffer and i got : FiFo0=0x1000680 then FiFo0=0x400000. As far as i know coming from the USB2 specification, I have to receive coming from the host a SETUP TOKEN frame in order to set the adress of the device. Could you detailed me the contains of the SETUP TOKEN frame ? I am not able to catch this information in any documentation...

To be honest, developping an USB driver is much more complicated that i expected at the beginning.

Thanks you very much.

Regards

Alex

Hi

I think it is common to get multiple interrupt sources at one ISR (but I can be wrong)

You should process them according to the documentation to the USB chip inside the processor.

Second for the frames you are receiving i think it is   0x80061000, and 0x0040  accordingly (I don't remember which endian is correct for USB bus). This probably is GET_Descriptor  request . For understanding better the descriptor request check USB.org - the USB spec is open and available to everybody but It might seem a little overwhelming at start. I would recommend also USB in nuttshell  ( beyondlogic.org/usbnutshell/usb6.htm - this chapter can give you some basic info about the frames you are receiving)  If in doubt check the USB specification.  Basic USB configuration - the wakeup and interrupts working are over you - next is writing the driver so I don't know if I will be able to help you.

Hi,

The OMAP User's Guide will not have the USB Protocol or Specification information. It captures the implemenation of the specification. You need to consult the spec for protocol and standard related info.

Yes, you sometimes get a spurious interrput and this will be captured on the upcoming errata. The only spurious interrupt I am expecting for you to receive, if you receive it, is multiple RESET interrupt at this stage. This especially happens when a High Speed negotiation takes place, chirping occurs, at times. Once the RESET timeline has expired, it will not happen, i.e. you will never receive a sporious RESET interrupt once you are done with the RESET stage. When it does happen, your RESET ISR should always perform the core initialization since some of the core registers content will be wipped out by the RESET. Just word of caution.

For the interrupts captured above, I think they are all valid interrupts. The suspend interrupt can happen any time after Power Up stage have elapsed. This is way before enumeration takes place. So long as you 3ms or greater no activity time on the bus, the Suspend interrupt will be launched since the core will go into suspend. It will exit suspend stage as soon as it detects bus activity.

The SOF interrupt will be generated right after reset.

Of-course, since the host has already started enumeration process you will be receiving EP0 interrupt. So, there is no problem with the interrupts you have received.

You can start by ignoring all interrupt other than RESET and once you can enable the desired interrupts from your RESET ISR. You probably would want to turn-off SOF interrupt unless you need it for your application or enable it at a later time after enumeration have ended.

The data you have recieved seems to be correct (pls double check it). I have attempted to parse the 8 bytes Data Packet of the SETUP STAGE of a control transfer below.

See sections 9.3 and 9.4 of USB Specification. You probably will want to observe the data in byte mode as opposed to 32-bit mode.

32-bit format: 0x0100_0680 in 8-bit format will result with the followings: Byte0=0x80, Byte1=0x06, Byte2=0x00, Byte3=0x01

32-bt format: 0x0040_0000 in 8-bit format will result with the followings: Byte4=0x00, Byte5=0x00, Byte6=0x40, Byte7=0x00

The 8-byte Request for the above seems as follows (this is just a quick capture and not 100% sure of the mapping, so pls double check). It seems that you have received a GET DESCRIPTOR command expecting a maximum for you to respond on and the host is expecting a 64 bytes max packet data on the DATA Stage of the control transfer.

| bmRequestType |      bRequest                   | wValue (Type/Index) | wIndex   |    wLength                |
|   1000_0000        | GET_DESCRIPTOR=6 |   Device / Index         |     0          | Data Stage Length |
|       byte0               |                 byte1                 |    byte2      byte3       |  byte4/5   |     byte6/7                  |
|        0x80               |                 0x06                  |    0x00       0x01        |  0x0000   |    0x4000                  |

Best regards, Zegeye

Thanks Zegeye,

I am coming back on this topic.

I made some progress, during the enumeration process, the host asks for the Device Descriptor. After receiving the first 8 bytes of the Device Descriptor, the host immediately issues another bus reset.

Then the host sent a Set Address command. That is nice.

I wrote the adress sent by the host in the FADDR register, then I clear the bit RXPKTRDY by setting the SERV_RXPKTRDY bit and I set the bit DATAEND.

Then the host asks again for the 64 bytes of the device descriptor with the same command that the first i received ( Normally the command should be : the host asks for the 18 bytes of the device descriptor ). I sent the descriptor again.

Then the host sent again a Set Address command.

In fact, the enumeration process is launched 3 times in this way then the host reports an error with my device.

I do not understand where i did a mistake. What can i do when i receive the SET ADRESS command ? Should be nothing because it is a zero data request command. Maybe my descriptor is wrong ?

Thanks you for your help

Best Regards

Alexandre

Hi,

Glad to hear of the progress.

One thing to note, prior to answering your question is that, I think the ordering of interrupts received you mentioned above is reversed. You actually have received the Reset Interrupt prior to receiving Endpoint 0 interrupt. So, please ensure that you are servicing the RESET interrupt prior to servicing endpoint 0 interrupt, since reset will wipe out some of your core register initialized values and you need to go through the re-initialization stage every time you receive a RESET interrupt.

I think what is happening is that you are modifying the FADDR value prior to the completion of the SET ADDRESS command. Commands are not completed until the end of the STATUS Stage transaction happens.

This is the detail as to how a SET_ADDRESS command is executed.

===== SETUP STAGE/Transaction of SET ADDRESS Command  =========

**** Host sends SETUP Token

**** Host follows up the SET_ADDRESS Command with the ADDRESS Value embeded within the 8-Byte command using DATA Packet of the SETUP Stage/Transaction.

**** Device H/W acknowledges the request (knowing that it is valid, i.e., has received a valid SETUP Token packet followed by an 8-byte data packet) by sending an ACK packet to the Host.

**** Device fires an interrupt to your application signifying that data has been received by setting RxPktRdy.

This concludes the SETUP Stage/Transaction of the SET Address Command.

You application deciphers the received command and saves the ADDRESS sent by a Host in a Temporary location. Note that at this stage your application SHOULD NOT change the FADDR value since the SET ADDRESS Command has not completed yet. You still are required to respond to address ZERO until the completion of the SET ADDRESS Command (i.e. the completion of the Status Transaction).

Since the SET ADDRESS Command is a Zero Data Request type of command No DATA STAGE exists and need to indicate this by setting DataEnd bit (like you mentioned above). Your application will transition to waiting for the next interrupt as a queue signifying the end of the command.

===== STATUS STAGE of SET ADDRESS Command  =========

**** Host sends an IN Token Packet using Address ZERO (this is the reason you do not want to change the FADDR setting).

**** Device H/W responds with NULL Data Packet

**** Host sends an ACK Packet

**** Device fires an Interrupt to your application indicating the completion of the Command.

Your application, when receiving this interrupt, it should now configure FADDR with the ADDRESS Value received during the SETUP Stage.

Best regards, Zegeye

Hi Krzysztof,

am i right, that u use the USBBIOS? 'Cause i run into a prob, while detecting upcoming USB connection w/o using the USB BIOS. So i've one (or more) questions:

• Is the DEVCTL->SESSION flag set by the BIOS?
• or by the controller itself?

Another problem upcomes when i try to set the SOFTCONN. Until the DEVCTL->SESSION bit isn't set no change of the POWER register is possible.

Does anybody have some hints about this probs?

thx

Hi,

First I think you are right I, but to be sure I am using DSP BIOS from TI as opperating system, not USB BIOS pachakge that TI has avalible.

Secondly I am using USB controler on DSP as USB device, I am not sure if that is the case.

Thirdly DEVCTL->SESSION flag is not set by BIOS or any code if you do not place it there, the controller should set it as Session Request Protocol is started (I can be wrong I am not much familliar with USB OTG specification and SRP) as VBUS is at certain level. In device mode comon scenario is this fimrware enables sofftconnect resitor by POWER->SOFTCONN bit and if USB VBUS is valid SRP will begin and  DEVCTL->SESSION bit will be set. See TI code example I posted in this thread. It initializes USB controler sets the POWER->SOFTCONN and waits till VBUS will be valid.

Another option is trying to manualy trigger session but probably session will end as soon as there is no VBUS on USB line.(I may be wrong)

I am unaware what you tring to achive, probaly more support you will recive from Zegeye Alemu

Hi again,

i try to develop something like a striped down USB2.0 device stack (OTG is not needed, so no SRP), that will only be used for transfering a small footprinted datastruct every few ms. So there is no need, to fullfill the whole USB2.0 specs, 'cause it will only be used in a properietary implementation. Following should be implemented:

• Connection Detection & EP0 init (DevDescritor,..)
• Download of DSP application related Configuration (selfmade OS)
• "Hard scheduled" Upload of data

Host will be a WinXP driven tablet or something like that.

The prob i mentioned before with POWER->SOFTCONN is, that i can't set anything within the POWER register, until the DEVCTL->SESSION flag is active. But i don't think that this is right!

Zegeye, any hints for me?

thx & KR

I haven't relied on POWER register before DEVCTL->SESSION bit is set so I am unable to help you.

Why you need read POWER registerr before setting session ? DEVCTL register isn't enough to check if VBUS is valid ?

Here is the problem:

CSL_FINS(usbRegs->POWER,USB_OTG_POWER_SOFTCONN,1);
while ((usbRegs->DEVCTL & 0x01) == 0);

I only can update the POWER (enable SOFTCONN) register, when DEVCTL->SESSION is set.

So, in my understanding, this is the wrong order.

Are u willing to post or upload your functional source until EP0 is initiated?

The source is posted, it is based on TI code exampel - which with minor corrections works, and I think is correct.

Alternate you can set DEVCTL->SESSION manually result should be the same if VBUS is applied to USB.

If you want to check for USB VBUS is present check DEVCTL.VBUS, this works as logn USB controler is powered, clocked and comparators appropriet compaarators are turned on. DEVCTL.VBUS is measuring voltage on USB0_VBUS pin, if it is correct - this should indicate that USB cable souring power to device is connected.

Hi Bernhard,

What Krzysztof said about the DEVCTL->SESSION bit is correct. Thanks Krzysztof.

SESSION bit is set by the Controller, when operating as a Device, when the VBUS Voltage is above VBUS VALID (4.4V).

The POWER->SOFTCONN field is used for Software Connect/Disconnect, as opposed to PHYSICAL Connect/Disconnect purposes.

If the USB Controller is expected to assume the role of a Device, you need to have the SOFTCONN bit set so that the Physicall Connection is observed by the Controller. As a Device, the controller expects a Host presence and its detection mechanism is by observing a Voltage >= 4.4V on the VBUS line. When it observes this voltage, the Controller will set the Session bit. (as FYI. The only exception to this is when operating in OTG envirnoment, device side s/w can set the SESSION bit directly to initiate SRP protocol which will force the SOFTCONN bit to be set. However, this is not recomended for your setup even though it can work.)

You mentioned that you are unable to set the POWER.SOFTCONN field prior to the Session bit being set.

I think there is something wrong here. I could not see how that is possible, that is how the controller could be able to see a Voltage on the VBUS. If SOFTCONN bit was not set, the Device should be in disconnect state. The only exception is that your s/w is setting the SESSION bit and since that instructs the controller to start SRP, it will automatically set the SOFTCONN bit so that it is connected to the bus.

First thing to ensure is that, are you accessing the right register address? Read the address of the register you are accessing and verify that is correct.

Read the default values of the first few registers and see if that agrees with the default values supplied within the User's Guide. That will let you know if you have access to the USB register file. If not you probably need to ensure that you have enabled the internal clock to the USB peripheral.

The task you are trying to implement is achiveable. You should be able to do that easily.

Start with the simple debug I mentioned above. If that is correct, make sure PHY related configuration is correct. If this does not solve your problem you might want to try using the EVM in order to rule out any possible h/w issue you might have.

Hope this helps.

Best regards, Zegeye

Hi Zegeye,

sorry for my late response & thx for the answer!

Finally i found a stupid typo for the POWER register (i had in mind that it is 16bit wide, and not only 8bit). So MENTOR core is set up correctly, and i'm able to detect the first RESET interrupt from the host. Here i run into a new question, because in sprufm9d on p. 21 it is said that the core itself will do a reset (FADDR, INDEX,...) when he senses a RESET signal on the bus. So should the app do a second reset?

After that a EP0 interrupt should arrive, but with all USB core & VBUS interrupts enabled there is no interrupt shown.

Any hints?

KR Bernhard

I don't quite understand you, when you ask about app doing second reset.

For me it is signal to clear any values related USB stack that application might have saved  (eg device address), last processed command,  and such.

Secondly I assume that after Reset interrupt you clear the interrupt source  (INTCLRR register) not doing this might affect your USB opperation.

For not arriving EP0 interrupt I can't help much, it appears that you have done everything correctly as you are observing RESET interrupt.

If your host is Win XP on bad enumeration you should see popup "USB device unrecognized" so you should observe EP0 interrupt.

See more at http://www.beyondlogic.org/usbnutshell/usb7.htm#Enumeration , if you have any USB analyzer (Hardware is best but software could do too) it would probably boost your work greatly.

Hi,

Glad to see that you are progressing.

I agree with  Krzysztof (thanks for your continuos support). I am also confused by what you referred as app doing a second reset? I will try to cover briefly what is expected of RESET in general.

To make sure we are on the same page, you are configuring your USB Core to operate in Device mode. Do not forget to check your POWER and DEVCTL content after the core is in SESSION to make sure your contorller operating setting.

This means that your device, when it observes a Power on the VBUS line, will enable its internal pull-up on the D+ line so that the external Host will detect a Device presence (FS or HS) causing the external Host to invoke a RESET, by driving both D+ and D- line low. That is, the Host invokes a RESET when it detects a Device presence which is signified by one of the data lines going high.

This act from the Host will cause a Reset interrupt to be recognized by your device. Assuming that you have done proper initialization, inculding enabling and bolting an Interrupt Handler, you should able to observe and service the RESET interrupt. Your Reset interrupt handler, at the minimum should configure the core registers and endpoints for use. Like you mentioned, some of the registers like the FADDR will be cleared to ZERO when a reset is invoked by the external Host. Of-course you need to respond to address Zero after reset and you should not change the FADDR setting until you go through the SET ADDRESS configuration stage of your enumeration. In addition, within your inerrupt service routine, you will need to acknowledge the interrupt you handled by clearing the interrupt and writing ZERO onto EOIR register so that sucessive interrupts will be handled. Also all interrupts at the CORE level (not at the controller level) will also be automatically enabled, when receiving RESET bus condition from an external Host, and you need to insure that the controller level interrupt handler is properly configured if using PDR mode interrupt handling. See CNTRLR register defintion for more info.

There are times that you will be getting additonal RESET interrupt for the same single RESET bus condition Invoked by the Host. I am not sure if this is the 2nd RESET you are talking about. The additonal RESET is a spurious interrupt is the same RESET interrupt that is caused by the Host. You just need to make sure that you go back and run your reset handler the same way you always handle reset interrupt. You also would go through the same initialization again. Note that, during times you receive additional reset interrupt(s), the most you have done by this time is core configuration and no enumeration (EP0) related interrupt would have been received. Just want to make sure that you are aware that this spurious interrupt when it happens, it only happens during RESET time and does not happen at other times.

Again, RESET interrupt is caused ONLY by the external Host. This reset is different from the Controller Reset you invoke through CNTRLR register. The Reset you invoke through CNTRLR register does not invoke an interrupt and should not be invoked in a middle of operation.

Endpoint 0 interrupt will be received after Reset has completed when receiving a SETUP Token from the Host. Since there is no acknowlegement of interrupt handling/processing between the Host and Device, the Host will continue on processing forward by issuing the SETUP Token after proper RESET invokation has completed. What this means is that, even if you have not launched or serviced your other interrupts like RESET, the H/W is minimally configured automatically to accept the SETUP Token from the Host and if all your initialization routine prior to RESET happening is configured properly, you should be able to see at least one EP0 interrupt. The reason for this is because EP0 resource is allocated automatically, i.e., the first 64 Bytes of your FIFO RAM isallocated for EP0 usage automatically and FADDR is cleared to Zero by the Controller when receiving a RESET interrupt and the core has its H/W available and responds to address ZERO request coming from the Host. It will NAK all successive request from Host until you service the first EP0 interrupt.

Best regards, Zegeye

Hi,

Glad to see that you are progressing.

I agree with  Krzysztof (thanks for your continuos support). I am also confused by what you referred as app doing a second reset? I will try to cover briefly what is expected of RESET in general.

To make sure we are on the same page, you are configuring your USB Core to operate in Device mode. Do not forget to check your POWER and DEVCTL content after the core is in SESSION to make sure your contorller operating setting.

This means that your device, when it observes a Power on the VBUS line, will enable its internal pull-up on the D+ line so that the external Host will detect a Device presence (FS or HS) causing the external Host to invoke a RESET, by driving both D+ and D- line low. That is, the Host invokes a RESET when it detects a Device presence which is signified by one of the data lines going high.

This act from the Host will cause a Reset interrupt to be recognized by your device. Assuming that you have done proper initialization, inculding enabling and bolting an Interrupt Handler, you should able to observe and service the RESET interrupt. Your Reset interrupt handler, at the minimum should configure the core registers and endpoints for use. Like you mentioned, some of the registers like the FADDR will be cleared to ZERO when a reset is invoked by the external Host. Of-course you need to respond to address Zero after reset and you should not change the FADDR setting until you go through the SET ADDRESS configuration stage of your enumeration. In addition, within your inerrupt service routine, you will need to acknowledge the interrupt you handled by clearing the interrupt and writing ZERO onto EOIR register so that sucessive interrupts will be handled. Also all interrupts at the CORE level (not at the controller level) will also be automatically enabled, when receiving RESET bus condition from an external Host, and you need to insure that the controller level interrupt handler is properly configured if using PDR mode interrupt handling. See CNTRLR register defintion for more info.

There are times that you will be getting additonal RESET interrupt for the same single RESET bus condition Invoked by the Host. I am not sure if this is the 2nd RESET you are talking about. The additonal RESET is a spurious interrupt is the same RESET interrupt that is caused by the Host. You just need to make sure that you go back and run your reset handler the same way you always handle reset interrupt. You also would go through the same initialization again. Note that, during times you receive additional reset interrupt(s), the most you have done by this time is core configuration and no enumeration (EP0) related interrupt would have been received. Just want to make sure that you are aware that this spurious interrupt when it happens, it only happens during RESET time and does not happen at other times.

Again, RESET interrupt is caused ONLY by the external Host. This reset is different from the Controller Reset you invoke through CNTRLR register. The Reset you invoke through CNTRLR register does not invoke an interrupt and should not be invoked in a middle of operation.

Endpoint 0 interrupt will be received after Reset has completed when receiving a SETUP Token from the Host. Since there is no acknowlegement of interrupt handling/processing between the Host and Device, the Host will continue on processing forward by issuing the SETUP Token after proper RESET invokation has completed. What this means is that, even if you have not launched or serviced your other interrupts like RESET, the H/W is minimally configured automatically to accept the SETUP Token from the Host and if all your initialization routine prior to RESET happening is configured properly, you should be able to see at least one EP0 interrupt. The reason for this is because EP0 resource is allocated automatically, i.e., the first 64 Bytes of your FIFO RAM isallocated for EP0 usage automatically and FADDR is cleared to Zero by the Controller when receiving a RESET interrupt and the core has its H/W available and responds to address ZERO request coming from the Host. It will NAK all successive request from Host until you service the first EP0 interrupt.

Best regards, Zegeye

Hi,

Glad to see that you are progressing.

I agree with  Krzysztof (thanks for your continuos support). I am also confused by what you referred as app doing a second reset? I will try to cover briefly what is expected of RESET in general.

To make sure we are on the same page, you are configuring your USB Core to operate in Device mode. Do not forget to check your POWER and DEVCTL content after the core is in SESSION to make sure your contorller operating setting.

This means that your device, when it observes a Power on the VBUS line, will enable its internal pull-up on the D+ line so that the external Host will detect a Device presence (FS or HS) causing the external Host to invoke a RESET, by driving both D+ and D- line low. That is, the Host invokes a RESET when it detects a Device presence which is signified by one of the data lines going high.

This act from the Host will cause a Reset interrupt to be recognized by your device. Assuming that you have done proper initialization, inculding enabling and bolting an Interrupt Handler, you should able to observe and service the RESET interrupt. Your Reset interrupt handler, at the minimum should configure the core registers and endpoints for use. Like you mentioned, some of the registers like the FADDR will be cleared to ZERO when a reset is invoked by the external Host. Of-course you need to respond to address Zero after reset and you should not change the FADDR setting until you go through the SET ADDRESS configuration stage of your enumeration. In addition, within your inerrupt service routine, you will need to acknowledge the interrupt you handled by clearing the interrupt and writing ZERO onto EOIR register so that sucessive interrupts will be handled. Also all interrupts at the CORE level (not at the controller level) will also be automatically enabled, when receiving RESET bus condition from an external Host, and you need to insure that the controller level interrupt handler is properly configured if using PDR mode interrupt handling. See CNTRLR register defintion for more info.

There are times that you will be getting additonal RESET interrupt for the same single RESET bus condition Invoked by the Host. I am not sure if this is the 2nd RESET you are talking about. The additonal RESET is a spurious interrupt is the same RESET interrupt that is caused by the Host. You just need to make sure that you go back and run your reset handler the same way you always handle reset interrupt. You also would go through the same initialization again. Note that, during times you receive additional reset interrupt(s), the most you have done by this time is core configuration and no enumeration (EP0) related interrupt would have been received. Just want to make sure that you are aware that this spurious interrupt when it happens, it only happens during RESET time and does not happen at other times.

Again, RESET interrupt is caused ONLY by the external Host. This reset is different from the Controller Reset you invoke through CNTRLR register. The Reset you invoke through CNTRLR register does not invoke an interrupt and should not be invoked in a middle of operation.

Endpoint 0 interrupt will be received after Reset has completed when receiving a SETUP Token from the Host. Since there is no acknowlegement of interrupt handling/processing between the Host and Device, the Host will continue on processing forward by issuing the SETUP Token after proper RESET invokation has completed. What this means is that, even if you have not launched or serviced your other interrupts like RESET, the H/W is minimally configured automatically to accept the SETUP Token from the Host and if all your initialization routine prior to RESET happening is configured properly, you should be able to see at least one EP0 interrupt. The reason for this is because EP0 resource is allocated automatically, i.e., the first 64 Bytes of your FIFO RAM isallocated for EP0 usage automatically and FADDR is cleared to Zero by the Controller when receiving a RESET interrupt and the core has its H/W available and responds to address ZERO request coming from the Host. It will NAK all successive request from Host until you service the first EP0 interrupt.

Best regards, Zegeye

Hi,

first of all THX for your patience!

1) USB Core is configured as device (also tried with "don't override PHY").

2) I misunderstood some post above the RESET topic. This is the reason for my question, because i didn't think that there should be a second RESET be done by the app, but i read it like this. Ok, so nothing to do here.

3) Still the same problem with the EP0 interrupt. All core & PDR interrupts are enabled and unmasked. Here i see the RESET interrupt. WinXP starts here with the search driver routine. At this point i should recieve a EP0 interrupt at the USB core and/or the INTMASKEDR. But nothing happend. EVTFLAG0.19 rises, so the USB core does something. But the core itself didn't either recieve a valid SETUP Token, or didn't process it. PERI_CSR0 also didn't change.

Tried it also on a second PC w and w/o HUB. No change.

Another interessting thing is, that after the USB Core init 0xA08F7B93 is shown up everytime in the FIFO0. Also after the RESET was recieved and processed (FADDR was cleared) FIFO0 contains the same value. 

What am i missing?

KR

Hi,

OK.

It might be good to check few registers again.

What exactly is your PHY Configuration value?

If you are Not overriding PHY configuration, you need to ensure that the VBUS Levels as well as the ID is properly driven external from the device.  What are the values of the POWER and DEVCTL registers after the core is in session, that is, after the SESSION bit is set?

Have you tried using the EVM as a Device?

Try overriding the PHY in order to eliminate VBUS and ID related driving issue in addition to clock related issue. Configure CFGCHIP2 with 0x000049F2 (configure for Device Operation and Internal Clock Source).

 If all of the above came with good value and still are having problem, I would suggest placing a bus analyzer to identify what is exactly happening on the bus.

I am not sure what the content of the FIFO would be if reading data from it when it has nothing inside it. It is not a good idea to do that since internal pointers will be modified for each access. But remember, since you have not received any EP0 interrupt, its content should be junk anyway. COUNT0 register holds the size of data inside the FIFO when data is present. If this register content is ZERO, you should refrain from reading data from the FIFO.

Best regards, Zegeye

Hi again,

after all, i throw the old one in the corner, and take a new EVM.

é voilà, RESET arrive, is served, EP0 interrupt arrives and could be served... Don't know what was going wrong - probably i will take a look on that later again.

Full of beans, i went further, and read in the specs that EP0 has a fixed FIFO size of 64byte.

• Is at the address FIFO0 (0x01E00420) only the 8byte MENTOR core? And should it be read out by the app?
• Is the RXFIFOADDR only for EP1-4?

KR, Bernhard

Hi,

Glad to hear that you are making progress.

All Endpoints require a memory location residing within the Controller (accessed via a set of FIFOs). For each Endpoint (0,1,2,3, and 4) there exists a corresponding FIFO register where all are 32-bits wide at address 0x01E0_0420, 0x01E0_0424, 0x01E0_0428,  0x01E0_042C, and 0x01E0_0430 respectively. Both Read and Write to the allocated memory is by reading or writing to this corresponding register. Acces to this register is smart enough to know if you are performing 8-bit, 16-bit, or 32-bit access and this is handled automatically by the H/W based on the data type variable you have created within your program.

A total of 4K RAM is available for all Endpoints and the size of the RAM to be allocated for each Endpoint is user configurable. The first 64Bytes is by default alloacted for Endpoint 0 and for this reason there is no configuration register dedicated for configuring resource for Endpoint 0. This first 64Bytes of location is used both In and Out transactions. However, for the other Endpoints (EP 1 to 4) the user is required to partition the remaining FIFO RAM (4KBytes - 64 Bytes) according to the application need.

You only require two information (one is size and the other is start address). Note that it is the responsiblity of the User to insure that Resources are not overlapped and the H/W does not check for this type of user configuration.

Even though the same FIFO Register is used to read/write data out or into the FIFO RAM, the actual Read/Write location accessed could be different (very rarely users use the same FIFO location for both IN and OUT transactions). Based on the direction of the transfer the user is performing, the H/W will access the right FIFO RAM location based on the Start Address that is programmed and the FIFO Register the program is accessing.

In summary, RXFIFOADDR is required to be configured for Receive Endpoints 1 to 4 and TXFIFOADDR is required to be configured for Transmit Endpoints 1 to 4. Endpoint 0 has dedicated resource and there is no dedicated registers like other endpoints exist to alter/change its resource.

Best regards, Zegeye

Hi,

I have the same problem that EP0 interrupt is not triggered or detect by C6747 DSP. I receive several SOF interrupts and the PC shows "USB device not recognized".  I use a scope to see the bus signal and it appears to be good. As I'm using my own board I can't guarantee any hardware errors. I found something different among my board and EVM board: the EVM board uses a 1Mohm resistor and a 0.1uF capacitor to couple the connector shiled to gnd. My board doesn't have this rc network. Anybody beliaves that this could be the problem (before in this post, some member told he exchange the board and his firmware starts to get EP0 interrupt).

If not, and know it is an inialization mistake, but I use a pretty close code that usb_init3 supplied before.

Could anybody give me any idea to check and found why I can't get EP0 interrupt even I receiving SOF interrupt flag?

Thanks, Ana Leticia

Hi,

As you might have eluded, at all times, it was not the c6747 device that was the cause of the problem. So, it makes sense for you to look into your h/w and s/w. Based on the info you provided, I think you might have a s/w issue. I do not think that not have the resistor and caps on your VBUS line is going to affect your operation so long as you attempt not to exercise the OTG functionality. You have also mentioned that you are receiving SOF interrupt.

I am assuming that you are configuring the c6747 as a Device. I am not sure as to how you can tell Bus condition status from observing the signals on the scope. I understand you can use a Breakout board and observe the signals but that is only used when performing Electrical test for compliance testing. You might want to us a Bus analyzer to insure detection of the correct bus activity. You need to decipher the packet information on the Bus so that you know exactly what is being sourced by the Host.

You mentioned that you have been receiving SOF interrupts. That is good. This tells me that you have undergone through Device Detection, Reset, etc. Also you have configured the PHY properly too. That means that your initialization routine is good. At least the clock settings and core configurations are good.

If you can detect SOF interrupt, I am assuming that your interrupt handler configuration is also good. Just make sure that your Endpoint interrupts are also enabled. When the Host reset the c64747 device, I am referring to USB Reset, the core interrupts are enabled by default. You need to insure that the interrupts at the wrapper level is enabled if using PDR enabled interrupt. The initialization routine you are using should have that enabled, but is worth mentioning. So, start by insuring that you have PDR interrupt enabled (CTRLR.UINT=0), and check for the content of INTSRCR register. I am expecting to see INTSRCR.bit0 to be set if a correct SETUP interrupt is received from the Host.

I am assuming that you have not altered the content of FADDR by mistake. This should be ZERO and the core clears it to ZERO when it receives a RESET Bus condition. However, if you change the content of this register prior to you getting a SET ADDRESS request, the c6747 device will not respond to Address ZERO.

While in the stage where the Host is continually sending SOF interrupt (every 125uS or 1ms depending upon the type of speed negotiated) let me know the status of the POWER and DEVCTL registers.

In summary, ensure that the c6747 device is up and running properly. Check the DEVCTL and POWER Register. Place a Bus analyzer and observe exactly what was on the bus. Also check the Interrupt registers to see if the Core has acknowledged at least the first SETUP packet.

Hope this helps.

Best regards, Zegeye

Hi,

Thanks for your reply.

I captured all USB interrupts(reading INTSRCR on USB interrupt routine) and I got

0x0000000000010000, 0x0000000000040000, 0x0000000000050000, 0x00000000000C0000, 0x00000000000C0000 and PC showed "USB device not recognized".

Analysing theses values, I got a suspend, reset, suspend+reset, reset+sof and reset+sof interrupts signaling. I believe it is wrong all these suspend bits.

How should I serve all these suspend requests?

DEVCTL is 0x99 and POWER is 0x42 after this phase.

Every time I receive an USB reset, I reconfig interrupt registers to  INTRUSBE = 0xf6, INTRTXE = 0x1f, INTRRXE = 0x1e;

Any idea what more else I should try? I don´t have a USB BUS ANALYSER (hardware) to check the bus activity.

Best regards

Instead of USB Bus analyzer you can use Windows PC with some custom software that logs USB acctivity, but I am not sure if one exist which gives information about Enumeration process. Sometimes that program costs, but there is free alternative use linux and usbmon - kernel device driver.

For USB interrupts, I am not sure if they reoccur if you don't clear/acknowledge their source - see INTCLRR reigster, but when you in interrupt  clear/acknowledge all of them that should help.

This is hint only, hopes that helps

Hi,

I agree with Krzysztof. I am going to suggest the same. You are possibly seeing the same Suspend interrupt. You can write INTSRCR back onto INCLRR register to clear it. It only takes 3ms of inactivity for the device to go into suspend.

Something strange is going here. Per USB 2.0 specification, a USB 2.0 Controller when operating as a Device, it can only operate as a Full-Speed or High-Speed device. This means that DEVCTL.FSDEV bits need to be set whether you are operating as FS or HS. I See that POWER.HSEN bit is not set, so I assume you want to operate at Full-Speed.

Are you overriding PHY values? If not, ensure that you have the right cable end attached to the connector.

Try overriding the PHY value by using Internal Clock source and Overriding PHY ID State value by configuring CFGCHIP2 register with 0x49F2.

Do the same that you did previously, i.e., observe the DEVCTL, POWER, INSRCR, CFGCHIP2 registers.

Best regards, Zegeye

Hi,

I agree with Krzysztof. I am going to suggest the same. You are possibly seeing the same Suspend interrupt. You can write INTSRCR back onto INCLRR register to clear it. It only takes 3ms of inactivity for the device to go into suspend.

Something strange is going here. Per USB 2.0 specification, a USB 2.0 Controller when operating as a Device, it can only operate as a Full-Speed or High-Speed device. This means that DEVCTL.FSDEV bits need to be set whether you are operating as FS or HS. I See that POWER.HSEN bit is not set, so I assume you want to operate at Full-Speed.

Are you overriding PHY values? If not, ensure that you have the right cable end attached to the connector.

Try overriding the PHY value by using Internal Clock source and Overriding PHY ID State value by configuring CFGCHIP2 register with 0x49F2.

Do the same that you did previously, i.e., observe the DEVCTL, POWER, INSRCR, CFGCHIP2 registers.

Best regards, Zegeye

Hi

I am not expert on hardware, but from software perspective since you are seeing SOF on the bus, did you observe the setup packet (8bytes) sent by Host on Bus?. If  you observe the setup packet on the bus, please check whether the device send ACK/NAK for this. If the device does not respond, there could be problem in configuring the endpoint-0 FIFO. Hence controller may not able to move the setup packet to endpoint FIFO. And hence there is ep0-interrupt. This could be probable issue. please Check the fifo configuration and verify again.

Regards

Ravi B

Hi

typo error re-sending the mail

I am not expert on hardware, but from software perspective since you are seeing SOF on the bus, did you observe the setup packet (8bytes) sent by Host on Bus?. If  you observe the setup packet on the bus, please check whether the device send ACK/NAK for this. If the device does not respond, there could be problem in configuring the endpoint-0 FIFO. Hence controller may not able to move the setup packet to endpoint FIFO. And hence there is no ep0-interrupt. This could be probable issue. please Check the fifo configuration and verify again.

Regards

Ravi B

Hi,

I'm working toward the same goal, but making very little progress, and time is getting short. So my question is: does anyone know of a software consultant/contractor who is familiar with the C6747 USB 2.0 port and who would be prepared to develop minimally functional device code (not host or otg)? Say, code that could successfully pass the enumeration phase and handle the standard requests but no more (data endpoints can be added later). For a price, of course. I figure it needs an initialization routine, an isr, and an ep0 handler. Written in C, using DSP/BIOS for the HWI, but not using BIOSUSB, Jungo or Linux. The platform is the OMAP-L137 SDK from Spectrum Digital. Please call me if you know of such an individual or company.

Don Knudsen (613) 267-1165 ext 101
Knudsen Engineering Limited

Don,

You could engage with a company called Mistral who are familiar with the controller.  Probably they can help you with this request.

I would also like to understand any specific issues in using BIOSUSB package.

regards

swami

Hi Zegeye,

I have exactly the same problem with Alexandre Amiez. post  at 10-29-2009 1:35 AM

The reset interrupt occured with end point 0 interrupt every time .I just do not understand what shall i do in the reset interrupt service routine.

In my case ,I found whether i reenable the interrupt enable register like CTRLR,INTRTXE,INTRRXE,INTMSKSETR,INTRUSBE or not didn't count.

Would you please give me some advice. Any help would be appreciated!

Thank you .

Best Regards.

Hi,

Spurious reset interrupt when it happens, it happens only when RESET Bus condition occurs. It does not happen other times. If so, the controller will not be usable. Btw, this is very common. All you have to do is to re-initialize the core.

What I think is happening is probably your ISR is not clearing the Interrupt it has serviced. Make sure you write back a '1' onto INTCLRR, the bit field the interrupt you serviced. Then after write a ZERO onto EOIR register.

Hope this helps.

Best regards, Zegeye

Hi,Zegeye

Thank you for your response.And  I 'm sorry to bother you again.

I have cleared the interrupt when i serviced it and written a ZERO to the EIOR register.But the problem still exists.

Here is my debug info:

clock is good
USB init done
USB Reset done
USB End point0 init done
USB End point0 init done
USB End point1 init done
USB End point2 init done
USB Set params done
intc is good
interrupt is enabled
USB Test Passed!!
USB Test Passed!!

0
reset interrupt
suspend interrupt

USB SUSPEND Callback
0

0
reset interrupt
end point 0  interrupt
GET_DESCRIPTOR
DEVICE_DESCRIPTOR
18
256
USB transaction done
0

0
reset interrupt
end point 0  interrupt
SET_ADDRESS
Addr is 1(In this period ,the addr hasn't been written to the FADDR register.Same as following)
0

0
reset interrupt
end point 0  interrupt
GET_DESCRIPTOR
DEVICE_DESCRIPTOR
18
256
USB transaction done
0

0
reset interrupt
end point 0  interrupt
SET_ADDRESS
Addr is 1
0

0
reset interrupt
end point 0  interrupt
GET_DESCRIPTOR
DEVICE_DESCRIPTOR
18
256
USB transaction done
0

0
reset interrupt
end point 0  interrupt
SET_ADDRESS
Addr is 1
0

0
end point 0  interrupt
suspend interrupt

USB SUSPEND Callback
1

As I know ,during the enumeration,the reset signal occurs just before and after the GET_DESCRIPTOR request.

And I think whether i respond to the reset interrupt doesn't affect the enumeration procedure.

In my isr for the reset interrupt ,I enable the interrupt enable register (INTRTXE,INTRRXE,INTMSKSETR,INTRUSBE)and nothing else.

I don't know where is wrong .

Thank you for your advice.

Best regard!

Hi,

Thanks for the info. This is strange. I am very inclined to say that this could be a valid RESET Bus Condition initiated from the Host. This is not one of those spurious reset that happens occasionally when a valid RESET is invoked by the Host. I can assure you that this is not a Device issue since this is the first I have heard of this issue and would like to concentrate on the other components.

Have you tried using another Host?

I am not sure if you have tried to use a Bus Analyzer to determine what is on the Bus. We need to remove this uncertainty.

Have you tried to run your code on the EVM?

We can take a look at your schematics if you desire.

What you are doing within your ISR when servicing RESET interrupt is OK. Btw, the RESET should also enable the core interrupts automatically.

Please try the following just to check if this is a valid RESET coming from the Host or not. Since all core Interrupts Enable registers are enabled automatically when a valid reset happens, on your first Reset interrupt handling, disable EP1-3 Tx/Rx interrupts and verify that it is disabled by reading it back since you are not using these endpoints during enumeration. See if these interrupts are re-enabled by the core when receiving the next interrupt, after the completion of your GET DESCRIPTOR command. This might be one of the quickest way to determine if new RESET Bus condition interrupt is coming from the Host or not. In addition, please also capture the content of INTSRCR after servicing the first RESET and also while you are in the middle of the GET DESCRIPTOR Command (prior to moving to the DATA Stage) and when receiving the next RESET interrupt prior to servicing the RESET interrupt. What I am trying to see here is that to insure that there is no RESET interrupt registered after servicing the RESET and monitoring this event throughout the completion of one control transfer.

Best regards, Zegeye

Best regards, Zegeye

Hi ,Zegeye

Thank you for your response. 

According to the debug info this time ,I think the reset is  valid .

I am using the EVM board from SEED ELECTRONIC TECHNOLOGY .There is little chance that there is something wrong with the board,I think.

Using my own PC of xp system, the problem still exists and seems the same.But when I plug my board to another PC of xp system,the result is different.

Here is the debug info of another PC:

clock is good

USB init done

USB Reset done

USB End point0 init done

USB End point0 init done

USB End point1 init done

USB End point2 init done

USB Set params done

intc is good

interrupt is enabled

USB Test Passed!!

The value of FADDR is 0

The value of INTSRCR is 10000

suspend interrupt

USB SUSPEND Callback

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 40000

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 10000

suspend interrupt

USB SUSPEND Callback

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 40000

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

GET_DESCRIPTOR

DEVICE_DESCRIPTOR

The value of INTSRCR is 80000

USB transaction done

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is c0001

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

end point 0  interrupt

SET_ADDRESS

Addr is 1

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

The value of FADDR is 1

The value of FADDR is 0

The value of INTSRCR is c0000

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

The value of wLength is 64

GET_DESCRIPTOR

DEVICE_DESCRIPTOR

The value of INTSRCR is 80000

USB transaction done

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is c0001

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

end point 0  interrupt

SET_ADDRESS

Addr is 1

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

The value of FADDR is 1

The value of FADDR is 0

The value of INTSRCR is c0000

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

GET_DESCRIPTOR

DEVICE_DESCRIPTOR

The value of INTSRCR is 80000

USB transaction done

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is c0001

reset interrupt

The value of INTRRXE after previous reset is 1e

The value of INTRRXE before next reset is 0

The value of INTSRCR is 80001

end point 0  interrupt

The value of wLength is 0

SET_ADDRESS

Addr is 1

The value of FADDR is 0

The value of FADDR is 0

The value of INTSRCR is 80001

end point 0  interrupt

The value of FADDR is 1

The value of FADDR is 1

The value of INTSRCR is 90000

suspend interrupt

USB SUSPEND Callback

The value of FADDR is 1

In this pc ,I can receive the status phase interrupt of SET_ADDRESS request during which I can change  FADDR  to the address value I received.

But another reset interrupt occurred later cleared FADDR, works before become useless.

I'm sorry to trouble you .Thank you  very much.

Best regards,Jun.

Hi,

Sorry to hear that you are still having a pb. You should not be seeing SETUP END bit set if the Control Transfer was handled properly. Make sure that the DataEnd bit is set. This is the only time that this bit gets set. You mentioned you do set the DataEnd bit but you are stating that SETUP End is set. You need to write both bits together, i.e.,  PERI_CSR0 |= 0x48. See comment below. If correcting this issue does not solve your problem, you probably need to use a Bus Analyzer and observe what is on the Bus. Based on your reply, it seems that the Host is invoking a RESET. Why, it probably is doing that because the Control Transfer did not complete properly.

Yes, you are correct about the timeline as to when the FADDR is updated with the new address. It has to be AFTER the Completion of the SET ADDRESS Command.

Here is a High Level SET_ADDRESS Transaction implementation on our device:

When Host Sends SETUP Packet with 8-Byte Command for SET_ADDRESS (Setup Stage of the Control Transfer) then the Device replies with an ACK Packet and then generates an EP0 Interrupt:

        SETUP STAGE

EP0 Interrupt is generated (PERI_CSR0:RXPktRdy is set, PERI_CSR0:COUNT0 hold # of Bytes received)

=> User S/W: Reads 8-Byte Command and Decode Request (saves the Address value to change FADDR content after the completion of this control transfer)

=>User S/W: Sets PERI_CSR0:ServicedRxPktRdy and also sets PERI_CSR0:DataEnd bits; usbRegs->PERI_CSR0 |= 0x48;

Host then moves to the Status Stage of the Control Transfer

      STATUS STAGE (Completes without user S/W intervention; handled by the H/W)

Host sends an IN Token Packet

DEVICE H/W replies back with Zero Byte Data Packet

Host Sends an ACK Packet.

Device Generates EP0 Interrupt.

      SET ADDRESS Control Transfer has Ended.

=> User S/W writes FADDR with the Address value.

Best regards, Zegeye

Hi sorry to cut into discussion but I have question of different nature

Devctl register filed VBUS

states

4-3 VBUS 0-3h These read-only bits encode the current VBus level as follows:
0 Below Session End
1h Above Session End, below AValid
2h Above AValid, below VBusValid
3h Above VBusValid

So I managed to dig up form USB.org usb otg document what might the different session means

Below seesion end                   < 0.2V
Above Session End, below AValid     0.2V - 2.0 V
Above AValid, below VBusValidi      2.0V - 4.0V
Above VBusValid                     > 4.0V

Is this right ? Or I made checked wrong ? (secodly if we are B-device and not using OTG HNP host should give Above VBusValid on USB VBUS   )

Hi Krzystof,

These voltages are the voltage levels at the pin. For e.g. the VBUS voltage at the Device B side is less than Device A side and controller is only sampling the voltage at the device boundary.

Vbus Valid >= 4.4V (I would say 4.7V if A side to account for the loss but the controller will not complain so long as it is >= 4.4V)

Session Valid for A Device beween 0.8V and 2.1V for B Device it is between 0.8V and 2.0V

Session End between 0.2 and 0.8V

Session Valid for A is the same as AValid.

If you ar B-Device and not using HNP your major voltage threshold you need to worry about is Vbus Valid only.

HNP is only used if you desire to change role with out powering down the communication and it requires that the Voltage is above VBUS Valid for it to change role and the OTG Original Host is in suspend. If the VBUS is not at that level, the B Device would request for the A Device to start sourcing power using SRP.

To make sure that you are not using HNP, allow the controller to control the SESSION, that is do not allow your s/w to set or clear the DEVCTL.SESSION bit. Also never set DEVCTL.HOSTREQ bit.

Best regards, Zegeye

Hi,

I have one more general question, not sure you can relate to it.

But is it possible processor/USB IC is loosing some interrupts if interrupt rate is very high / and or Interrupt service routine is very slow (not sure about last one).

Right now I am stuck with some strange error and only possible solution is that processor/USB IC is missing some of interrupts. I am not using DMA mode of operation,

and this is for EPX where X is different than 0. 

On the other hand maybe the USB IC have some error condition not cleared and will stop issuing any Interrupts from that point .

Glad to be of help,

I have question to Zeyege, is there any situation in wihich USB controller will stop to issue Interrupts, one I found is when FIFOFULL  is set  in EPX OUT endpoint.

Any other situation this could happen on IN endpoint.  I use BULK endpoints ?

Hi Krzysztof,

Btw, this is the order of the interrupt handling when multiple interrupts are set:

Resume, Session Request, VbusError, Suspend, Connect, Disconnect, Babble, Reset, SOF, EP0, TxEP, RxEP

If the FIFO FULL bit is set, the controller will be NAKing the request from the Host. Since no data is moving and out of the Device, there is no room within the FIFO, no interrupt will be generated.

Since I do not know the role the USB controller is assuming, I will try to make it as generic as possible.

For requests that require data to be driven out of the USB controller, TxPktRdy bit is set when data is ready to be driven out. When the data is driven out, the controller will clear this bit and generates an interrupt to let the user know that room within the FIFO is now available.

For a receive type of transaction, when data arrives and there is room available within the FIFO, in this case RxPktRdy bit was initially cleared, after loading the FIFO with the received data, then the controller will set RxPktRdy bit and generate an interrupt. The FIFO FULL bit could be set too. If that is the case, after unloading the data from the FIFO, the user needs to clear the RxPktRdy bit. If the FIFO FULL bit was set, the controller will clear the FIFO FULL bit then loads FIFO within new data, set RxPktRdy bit and generate an interrupt.

The only time the controller will shut down servicing incoming or outgoing transactions is when STALL conditions are invoked. This happens when the user sets SendStall bit. Until the time the SentStall bit is cleared, that endpoint will send a STALL to the Host and will keep on sending STALL if the Host keeps on requesting service to the particular Endpoint that is stalled. Endpoint will be ready for use when the SentStall bit is cleared.

Having said that, for a normal transfer where no error is introduced, the controller will keep on generating interrupt based on the availability of new data, in receive mode, and the availability of space, in transmit mode.

The H/W, based on the status of the FIFO or data, will either reject (NAK) or accepts the request. So long as you are clearing the interrupt bit and RxPktRdy bit at the end of your ISR, you should not loose any data. If you happen to be slow in handling it, then the h/w will NAK the request.

Since your interrupt handler is working, I do not think that this is an issue but worth mentioning it. If you are handling interrupt at the PDR level, not core level, you should make sure not to read or write to any core interrupt registers. You have to use the PDR level registers to interface with the Interrupt Handler. You should also not open a Watch Window where you are observing the content of memory at the Mentor Interrupt address space since you could accidentally clear an interrupt when the core Interrupt Flag register is read.

In EPx OUT transaction, as a Device, you are receiving data. There is an intermediate FIFO like memory used by all Endpoints with other data ready to be transferred to your allocated FIFO. When you clear RxPktRdy, the controller should clear the FIFO Full bit and it should quickly set RxPktRdy bit again. Try double buffering and that should keep this bit cleared so long as you service it prior to all buffers being full.

In EPx In Transaction, there is no FIFO Full bit. You will always need to make sure that the TxPktRdy bit is cleared before writing onto the FIFO.

In summary, unless a Stall condition is present and Endpoint is halted or unless previous interrupt flag has not been cleared, you should be able to receive interrupt when new events occur.

Best regards, Zegeye

Hi ,Zegeye.

Sorry to trouble you .

I'm now configuring ep1 for bulk In end point.And I have driver and a control panel in the pc side.I'm not using DMA mode.

When pc side asks for data from ep1,it will send an in token packet.I'm now wondering when DSP recevied the in token ,will it generate an ep1 interrupt?

My condition is that I can't receive ep1 interrupt ,but  PERI_TXCSR is 0x0004 .The underrun bit is set which means DSP has received an in token.

Shall I get the data ready before the request of pc,or just wait for the pc in token after which I load my data to  FIFO1.

Could you give me some advice .Thank you very much.

Best regards,Jun.

Hi,

We know for sure that the FADDR is configured properly if you are getting an UnderRun interrupt, it means that the controller has accepted the IN Token request from the Host and has sent back a NAK response to the Host since it is not ready with the data, i.e., it did not have the data to be sent out within the FIFO by the time the request was received. Also make sure that the ISO bit is cleared to ZERO. I am assuming that all interrupt handling related registers and tasks are initialized properly and are operational.

Data UnderRun and OverRun conditions are usually catagorized as Error conditions, it depends as to how you consider these events to call them error or not, and there is no dedicated interrupt allocated to capture this event. When receiving an Endpoint interrupt, you will need to insure that these bits are not set, i.e., the interrupt generated for these events share the same interrupt used for driving data in and out of the device.

UnderRun event exists or generated when no data within the FIFO is present and an IN Token is received from the Host. The user s/w needs to clear this bit field priror to setting the TxPktRdy bit after placing data within the FIFO. When the data you have placed within the FIFO is sent out, for an IN request received after you have placed the data within the FIFO, an interrupt will be generated when the last data within the FIFO is sent out as an indication to the user s/w signifying that memory space is available for you to load data prior to the next IN token is received.

You can also use double buffering so that you can be able to load data for 2 packets allowing you some time to service the FIFO.

Yes, it is usually a common practice to load the FIFO with the data to be sent out prior to the arrival of the IN request since you are aware of the request that is to be coming prior to the request coming. You will need to try to avoid getting an UnderRun or OverRun conditions as much as possible which is the reason that they are classified as Error conditions as opposed to status.

Best regards, Zegeye

Pl. refer to the below link for musb related initialization sequence and programming to get the USB controller working

http://git.denx.de/?p=u-boot.git;a=tree;f=drivers/usb/musb;h=952fd24275b7c1cca70c0b4a1d07f59c0af25a32;hb=HEAD

musb_core.c     -      Implements the generic musb functionality

musb_hcd.c      -       Implements the host related musb functionality

musb_udc.c      -       Implements the device related musb functionality

da8xx.c               -        Implements C67xx related platform specific initialization such as phy on/off, platform init etc.

This is a bootloader level code and hence does not involve any Linux/OS related implementation/complexities.  So it is easier to understand and more closer to a non-os level (CSL) type of implementation.

regards

swami

Krzysztof, Yan, Jun, Zegeye, and anyone who is interested,

I am required to develop our own C674x USB driver. Our requirements are simple: Single bulk-IN and single bulk-OUT.

May I ask what is your status? Is there an option to cooperate regarding this issue?

Best regards,

Uri

Please feel free to contact me directly at:      uri at zoro-sw dot com