• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Answers 2 answers
  • Subscribers 84 subscribers
  • Views 1275 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

USB enumeration fail on F28062

fvangoethem
Prodigy 160 points

Hi,

I work on a TMS320F28062U with USB_dev_bulk example. My controller is clocked at 24MHz (XCLKIN), with a SYSCLKOUT of 90MHZ. I have just modified cmd file to run in ROM due to the limited RAM space on this device.

My USB module is clocked at 60MHz:

SysCtrlRegs.PLL2CTL.bit.PLL2CLKSRCSEL = 3;

SysCtrlRegs.PLL2MULT.bit.PLL2MULT = 5;

DevEmuRegs.DEVICECNF.bit.SYSCLK2DIV2DIS = 0;

I have a good communication, using usb_bulk_example.exe, nothing bad seen until now.

When I check this communication with USB 2.0CV downloaded on usb.org. All is ok except enumerations. It systematically fails between something like 50 and 800 enumerations... After that, my computer is no more able to identify the device.

Here are some details observed. These are based on

-          CCS5 emulator (xds100V2)

-          an oscilloscope connected between D+ and ground

-          an oscilloscope connected between an output pin and ground for USB interrupt detection (toggle)

1/ Without usb_bulk_example.exe & USB 2.0 CV activated, I have a USB interrupt (SOF) each 1ms. Synchronized to this, I see a trame (from the host I suppose) on the USB bus.

  -> USBFIFO0 value does not change

  -> USBFIFO1 to 3 are always refreshed to an higher value (why are these pointers incremented?)

  -> USBIntStatusEndpoint(unsigned long ulBase) from usb.c always return "0" meaning that no TX or RX interrupt have been received.

2/ With usb_bulk_example.exe activated, all seems to be ok. USBIntStatusEndpoint(unsigned long ulBase) returns a non "0" value on each string written in the program.

Between data sent via usb_bulk_example.exe, USBIntStatusEndpoint(unsigned long ulBase) from usb.c continues returning "0" on each SOF interrupt and USBFIFO1 to 3 are still always refreshed to an higher value.

3/ With my oscilloscope, when I launch an enumeration test, I can see an interrupt each ms with a returned trame from my controller to the host. This is really stable. When enumeration fails, traffic on the bus becomes really heavy and no more interrupts from USB are activated. It seems that the USB bus has been disconnected from the device.


Other comments:

1/ Vbus detection is initially configured in your example on GPIO39 (Xint3) but following datasheet, this input cannot be linked to XINT3 (only GPIO0 to 31)...

2/ I found something interesting: http://e2e.ti.com/support/microcontrollers/c2000/f/171/t/113671.aspx?pi177899=1

It is written that there is a fixed divided by 2 after PLL2. So PLL2 must be configured to clock at 120MHz.

Is this "fixed divided by 2" linked to DevEmuRegs.DEVICECNF.bit.SYSCLK2DIV2DIS?

If yes, I can see in usb_dev_bulk that this bit is not configured (1 by default, so no division. page 160 of datasheet) but PLL2 is configured at 120MHz. Something goes wrong...

If no, It means that I can divide PLL2 output by 4 if I want. Something is not clear in the datasheet, between fig.p86, fig.p404 and fig.p75. I have some difficulties to clearly identify SYSCLK2...

  • 0
    Prodigy 160 points

    No idea? I really need some support...

  • 0 in reply to fvangoethem
    Prodigy 160 points

    I really need a feedback from TI... Here are main points that need a support from you:

    - Is in fact RAM space too small for usb driver on F28062U?

    RAML0_L5 is used in F28069U bulk example for .text and RAML6,7,8 for .ebss, .econst, .esysmem . In F28062,  I have not these RAML6,7,8 banks so I have no more RAM space for .ebss, .econst, .esysmem variables. For this reason, I pass .text space in FLASH and then have enought RAM space for my variables.

    - USB clock configuration, Is it ok?

    My USB module is clocked at 60MHz, based on a 24MHz external oscillator:

    SysCtrlRegs.PLL2CTL.bit.PLL2CLKSRCSEL = 3;

    SysCtrlRegs.PLL2MULT.bit.PLL2MULT = 5;

    DevEmuRegs.DEVICECNF.bit.SYSCLK2DIV2DIS = 0;

    I am a bit confused regarding 120MHz configuration...

    - USBFIFO1 to 3 are always refreshed to an higher value. Is it a normal behaviour if I do not send data to the device?

    - Most of the time, USBIntStatusEndpoint(unsigned long ulBase) from usb.c returns a "0" on each SOF interrupt. So interrupt is generated but not treated by usb driver. Is it a normal behaviour?

    I wait for your feedback...

  • 0 in reply to fvangoethem
    TI__Mastermind 22025 points
    1. There  should be plenty of RAM and flash for you to run your USB application.  This part has 128k flash and 52k RAM.  You may have to massage the linker files though.
    2. There is a built in divide by 2 on the output of the PLL  this is why we shoot to generate 120MHz.
    3. The values in the FIFOs are indeterminate if there is no data in them.
    4. No SOF interrupts should be a status of 8.  This seems off.
    If you're having trouble getting USB up and running, I would recommend you start with one of the examples and then modify the clocking and linker files so that it works with your 24MHz osc and smaller device.  Then from there you can customize to your application needs.
  • 0 in reply to Trey German289
    Prodigy 160 points

    First many thanks for these information's!! Could you give me more details about:

    1. Could you just confirm that running USB code from flash is not a problem? It seems that there is not enought RAM space to run all the program code in RAM. One other option would be to fragment .text between RAM and flash but I don't really know how to do that...

    2. Is this built-in divided by 2 controlled by DevEmuRegs.DEVICECNF.bit.SYSCLK2DIV2DIS? if yes, default value is 1 (divided by 2 not activated) and I can not see this bit configured to 0 to activate the "divided by 2". So my conclusion is that the target should not be 120MHz but 60MHz...

    3. I completely agree with you but what is strange is that I am talking about USBFIFO1 to 3 that are pointers to RAM FIFO space (if I do not make mistakes). These pointers should not be incremented if no communication...

    4. USB interrupt detects a SOF. After that, USBIntStatusEndpoint(unsigned long ulBase) should return which endpoint is the target but this function returns "0" meaning that no TX or RX interrupt have been received.

    One thing I could do is to check on a F28069U device but I still need to order it... Not easy to work with bulk example due to the fact that all the driver is included in a librairy...

    Again, many thanks for your feedback,

    Frédéric

  • 0 in reply to fvangoethem
    TI__Mastermind 22025 points

    Yep, No problem!

    1. Absolutely, we normally run the USB stack out of flash.
    2. The built in divide by two is always there and is separate from the divide by two you are referring to.  Its part of the PLL block and is definitely poorly documented.  I thought it was called out more clearly, but someone may have accidentally removed it.  You'll notice that all of the examples use the 20MHz oscillator and a multiplier of 6 which would yield 120MHz, but the built in divide by 2 brings us down to 60MHz.  You'll also notice that we never touch that second divider.
    3. Your analysis seems correct to me, but I don't have that much visibility into the actual design so I can't say.
    4. I checked here and I do get the interrupts correctly with the latest examples that have been released.  Maybe you are just misinterpreting what is happening/should be happening?
    Behavior should be the same between the devices...no need to track down a 69U.  The source code for all the PC USB stuff is included in the F2806x package...take a look at the MWare\tools directory.

    Regards,
  • 0 in reply to Trey German289
    Prodigy 160 points

    Many thanks Trey!

    With 120MHz as target, I have better results. Enumerations still fails but after a much higher number -> I'll do more tests to be sure that I have not damaged HW.

    These better results are done just by:

    - setting PLL2 to 120MHz

    - deleting all configuration lines about DevEmuRegs.DEVICECNF.bit.SYSCLK2DIV2DIS (so PLL2 is no more configured by "void InitPll2(Uint16 clksrc, Uint16 pllmult, Uint16 clkdiv)" found in "F2806X_SysCtrl.c".

  • 0 in reply to fvangoethem
    TI__Mastermind 22025 points

    If enumeration fails sometimes, I would suspect a problem with clock jitter.  You could try a higher multiplier and divider (this will help to average out jitter) or a different external osc.  Do not use the internal oscillator to clock USB.

  • 0 in reply to Trey German289
    Prodigy 160 points

    ...I have no other divider on PLL2 than SYSCLK2DIV2DIS. It means that PLL2 output should reach 240Mhz before being divided by 2?

    If I do that, my computer detects and loose immediately communication, starting again and again detection of the device...

    BUT I can see on page 86/1193 of the global datasheet: "Whenever the user changes the clock source using these bits, the DEVICECNF[SYSCLK2DIV2DIS] bit will be automatically forced to zero. This prevents potential PLL overshoot. The user will then have to write to the DEVICECNF[SYSCLK2DIV2DIS] bit to configure the appropriate divisor ratio."

    My final opinion is that this "fixed divider by 2" is the SYSCLK2DIV2DIS automatically configured to 0 due to the fact that I modify clock source. I checked and saw that default value for this bit is "0" and not 1 as said in datasheet. Could you check that?

    I check again my HW regarding jitter. Due to the multiplier, this could in fact be the source of my issue!

    Many thanks for your support,

    Frédéric

  • 0 in reply to fvangoethem
    Prodigy 160 points

    Ok, problem solved (I hope!).

    That's by moving usb stack from flash to RAM that enumeration issue has disappeared… Running it from flash gave me limited results (enumeration fail after 100 to 1500 enumerations) but a correct communication. I now can easily reach 20000 enumerations without any fail.

    For those who have some difficulties with memory management or a limited RAM space to execute all the source code in RAM, the .map file in the debug folder of the project is a really powerful tool.

    Many thanks Trey for your precious support!

  • 0 in reply to fvangoethem
    Prodigy 20 points
    Hello

    I am facing similar issue ,I am new to this C2000 series controller .Can you help me ?
    How to move usb Stack from flash to RAM.I see F206x series had dedicated RAM section for USB operation 0x040000 to 0x000800.
    is it the same thing you to or something different ?
  • 0 in reply to Kiranreddy singareddy
    Prodigy 190 points
    Hi,

    fvangoethem is not working for our company anymore and his account is linked to his professional e-mail address from the company. So I doubt he will be able to get your message.

    Concerning your question, I recently had problems too with the usb library for our device.

    It seems the solution used back in 2013 was to use the source code of the library, directly copied to the application project to allow modifying files. By doing so the usb code was placed in RAM the same way as our application code was (using pragma to redirect the code to a specific run from RAM area).

    But we had to update it from V136 to V151 due to usb BOS descriptor failures (about 2 to 5% of the time). Doing so I used directly the .lib files provided by TI instead of copying the sources. I asked a contact from TI how to relocate the code in RAM as before without requiring to modify the files directly but have no response for now.

    That's all I can tell for now.
    Hope this helps.