??? 08/15/08 02:32 Modified: 08/15/08 02:49 Read: times Msg Score: +1 +1 Good Answer/Helpful |
#157496 - Initialization problem Responding to: ???'s previous message |
But the problem with enumeration occurs on the computer with MSI mainboard... It works well on the other computers. I found out that the program freezes in the section where the device descriptor is being sent...nothing happens and then reset interrupt comes... Sound like a typical initialization problem. While your firmware does start-up initialization, the PC starts enumeration. Your firmware doesn't respond to the request from PC until initialization finishes. When your firmware responds to the request held on the USB engine, timeout has already occurred on the PC side. PC detects device connection by the voltage rise at USB D+ (or D-) line. The pull-up resistor to D+ line on the device side causes this change. After detecting device connection, at least 100 ms delay is guaranteed by the USB spec until PC starts enumeration. But actual delay depends on the PC. Some PC gives longer delay, but shorter delay of just 100ms on another PC. When the initialization of your firmware takes longer than 100 ms, your firmware succeeds on the PC with longer delay, but fails on shorter one. The solutions are, a) Speed up start-up initialization Move the PLL setting to the early stage of start-up initialization. It depends on the compiler. For KEIL, move the PLL setting to startup.A51 For SDCC, do it in _sdcc_eternal_startup() b) Enable D+ pull-up resistor after initialization finishes. On AT89C5131, DETACH bit of USBCON register controls attach/detach of the D+ pull-up. As the default after power-on reset, the pull-up is attached (DETACH = 0). Then, detach it in the startup.A51 or _sdcc_eternal_startup(). When the initialization finishes on your main(), attach it again. How can I detect that the enumeration process is at the end and I am able to send user data to the host? It depends on the USB class, and your application. For the HID keyboard/mouse, Put a dummy packet to the interrupt IN endpoint (EP) on the initialization. ZLP (Zero-Length Packet) will do. When you see that this packet is sent, by the interrupt of this EP or polling TXCMPL bit, your firmware knows that the PC start to read out the IN EP. When you make up a vendor-specific HID implementation based on this example, you have to take another strategy. Windows system starts to poll the interrupt IN EP of your device just after enumeration finishes, before your PC application opens your device. You have to send some command from the PC app, to notify that your app has grabbed your device. Tsuneo |
Topic | Author | Date |
AT89c5131 enumeration problem... | 01/01/70 00:00 | |
Initialization problem | 01/01/70 00:00 | |
Windows bug | 01/01/70 00:00 | |
continuing problem... | 01/01/70 00:00 | |
End of enumeration | 01/01/70 00:00 | |
Zero-length data packet | 01/01/70 00:00 | |
ZLP to the interrupt IN EP | 01/01/70 00:00 | |
My fault... | 01/01/70 00:00 | |
Which example? | 01/01/70 00:00 | |
Implementing the USB Enumeration Process... | 01/01/70 00:00 | |
Packet size of the interrupt IN EP | 01/01/70 00:00 | |
packet size... | 01/01/70 00:00 | |
Detailed log...![]() | 01/01/70 00:00 |