• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 1 answer
  • Subscribers 82 subscribers
  • Views 1416 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.

TMS320F28069F: Sporadic USB enumeration fails (STALL) after device reset

Mathias Felix
Prodigy 172 points

Part Number: TMS320F28069F
Other Parts Discussed in Thread: C2000WARE

Hi,

Since the rise of windows 10 we are increasingly confronted with USB communication errors.That motivated us to migrate to the latest USB stack and rework the communication in general. Our device acts as a generic USB HID device and we use Interrupt Transfer for both IN and OUT endpoints. After some modifications to the library code the communication seems to be stable now with different host systems. So far so good.

The things look different on our integration test system. During a complete run we ge multiple communication errors, everytime after a device reset. The reset is triggered on application layer to get the device in a defined state before a new test case is executed. During a reset, the device is still powered and connected to the USB bus. According to the USB logger, the communication hangs during device enumeration. Sometimes a plugout - plugin of the cable is sufficent to get the communication restored but in rare cases a power cycle is mandatory.

System environment

  • Generic USB device with interrupt endpoints, based on HID keyboard example
  • USB library 4.00.00 (C2000Ware 1.00.06.00)
  • TI-RTOS
  • Endpoint0 handling is done in HWI while interrupt endpoint handling is forwarded to SWI
  • Whole project has optimization level 4 (otherwise there's not enough flash memory)
  • Some modification with compiler switchs were made to further reduce memory footprint (host and OTG stuff removed)

Does anyone have experience with a similar system environment or has stumbled over the same problem? We are grateful for every little tip!

Best regards,
Mathias

  • 0
    TI__Mastermind 32995 points
    Hi,

    First, using --gen_func_subsections compiler flag should help you to save some code space if you are not already using it.

    Second, when the device hangs during enumeration, can you try to clear and reset the SOFTCONN but in the USB peripheral? This may help you to disconnect and properly connect again.

    Hope this help. Unfortunately, we do not have much experiencing integrating USB and RTOS.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 172 points
    Hi Sal,

    Unfortunately, we allready have activated this compiler flag. Which compiler settings / optimization level do you use in your examples? We try to exclude all possible influences.

    What's the easiest way to detect a stall condition on applicaton side and it is mandatory to respect a special timing requirement to clear and the the SOFTCONN bit? We have already thought about such a solution but that just eliminates the symptoms. We would like to know the cause.

    Thanks and best regards,
    Mathias
  • 0 in reply to Mathias Felix
    TI__Mastermind 32995 points
    HI Mathias,

    We use very few in examples since they are examples only. What you have described is what I would recommend. Namely, using optimization level, speed/vs switch, and the --gen_func_subsections flag. There may be some other helpful ones. You can search the compiler user guide and the CCS project properties for other flags.

    I believe there is a global variable in the library which signals whether or not the device has enumerated and connected properly. You can search the library and examples or the USB Library User Guide PDF which is provided in C2000Ware.

    It is difficult to say what the cause would be. In debugging this, I would suggest you look at the interrupt status flags when an interrupt is triggered and compare a proper enumeration and this faulty enumeration to begin your debug in diagnosing what may be cause this unseccessful behavior.

    Hope this helps,
    sal
  • 0 in reply to Sal Pezzino
    Prodigy 172 points
    Hi Sal,

    We played around with other compiler settings (going down from highest possible level of optimization back to nearly no optimization) but there was no striking change in behavior detectable. Tendentially, the effect is less frequent. On average it takes around one hour on the testsystem until the error occures for the first time. It takes a relatively long time until a statement regarding the stability can be made.

    One problem we have is that we're not able to stay connected with the microcontroller during a reset squence. As I wrote eralier, the reset command is needed to bring the device back to a defined state and is executed in advance of every testcase. Unfortunately this does not work with a connected debuger since the controller does not automatically restart (which can only be done by user intervention). Maybe this is just a setting in the studio but so far we have not figured out how to do it.

    Best regards,
    Mathias
  • 0 in reply to Mathias Felix
    TI__Mastermind 32995 points
    When the device resets, you will loose USB connection. This is expected.

    Keep in mind debugger resets act differently than POR resets. Perhaps you can try to get the USB into the same known state every time. Perhaps before doing clearing and setting SOFTCONN, you could disable the USB peripheral clock and enable it to get the USB into a known state.

    This is my best suggestion to resetting the USB and getting it into a known state. Try this.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 172 points
    Hi Sal,

    I have to clarify myself. During our integration tests the device is allways powered and USB allways mechanically connected. All we do is sending a reset command over the service interface. The reset command itself triggers a watchdog reset. And yes, during the boot sequence the USB connection is lost. That was never a problem. No matter what was the reason for a reboot of the device, the USB enumeration should success in all conditions. But we can check at which time the USB interface is initialized during bootup.
    The problem with the lost connection is related to the debugg adapter. The conenction is not really lost but in debug mode, the MCU is halted after a watchdog reset. You have to start the MCU through the CCS. On a workplace this may works but during automated integration tests this is very tedious. You have to imagine that an integration test job takes up to one hour and during this time hundrets of device resets are executed (for each test at least one).

    Best regards,
    Mathias
  • 0 in reply to Mathias Felix
    TI__Mastermind 32995 points
    To aid in this, we have something called DSS scripting. DSS scripting should enable you to run the device via the emulator in an automated fashion.

    For this, I suggest opening up another E2E thread so we can support you better.

    sal
  • 0 in reply to Sal Pezzino
    Prodigy 172 points
    Hi again,

    Thank you for the information. I will open another thread concerning the debug thing since this is not the first time that we struggle with this.

    In the meantime we worked on the USB bug and now we get a slightly different behavior. The good thing is, that the enumeration problme is gone (or at least , it can not be reproduced within a day).
    Unfortunately the communication is still not very stable. From time to time the communication stalls (not an USB STALL but a stall on protocol layer). We suspect that the cause is the interaction between USB stack and the RTOS.

    We also found a reliable solution to fix the USB problems on host side. This allows us to go back to the original USB implementation which is based on control instad of interrupt transfer and the older USB 1.4 library. We favor this approach because less risk is added than changing the complete stack and because we don't want put too much effort in this product anymore.