Hello,
Sometimes, my controller hangs after being polled by a CDC connection. I see when I debug the ISR that my device status registers contains the vale 0x41 (11110001), which can be interpreted using the following data sheet table:
bit0 The frame interrupt occurs every 1 ms. This is used in isochronous packet transfers. bit1 Fast endpoint interrupt. If an Endpoint Interrupt Priority register (USBEpIntPri) bit is set, the corresponding endpoint interrupt will be routed to this bit. bit2 Slow endpoints interrupt. If an Endpoint Interrupt Priority Register (USBEpIntPri) bit is not set, the corresponding endpoint interrupt will be routed to this bit. bit3 Set when USB Bus reset, USB suspend change or Connect change event occurs. Refer to Section 13â€"11.6 “Set Device Status (Command: 0xFE, Data: write 1 byte)†on page 366. bit4 The command code register (USBCmdCode) is empty (New command can be written). bit5 Command data register (USBCmdData) is full (Data can be read now). bit6 The current packet in the endpoint buffer is transferred to the CPU. bit7 The number of data bytes transferred to the endpoint buffer equals the number of bytes programmed in the TxPacket length register (USBTxPLen).
I don't fully understand why this is happening (it just appears after some time; no endpoint is triggered anymore as a result). Windows issue? software failure? Thanks in advance
I meant to say that the controller keeps on working, but the CDC connection is broken and requires the controller to be reset before it can be restored.
my controller stood frozen on a break point for a while, and now everything works again without a reset.
"...the vale 0x41 (11110001)..."
0x41 or 10000001 ?
that is the binary representation of 0x41 to help people understand the information that follows.
We've had 11110001 and 10000001.
I'll try 01000001.
11110001 base two would be 0xF1 which would be 241 decimal (looking slightly like the 0x41 of your claim) ;)
oops. that's what I meant...0xF1 !
Just from the device status register, the cause isn't specified.
What do you mean CDC connection is broken? No transfer goes to PC, or comes from? Or read or write on the COM port shows error on the PC application?
Some related matters are,
a) End of IN transfer on the CDC bulk IN endpoint - ZLP (Zero-Length Packet) When the transfer ends with a full-packet (64 bytes), ZLP is always required to terminate the transfer.
b) Extra ZLP for IOCTL_SERIAL_WAIT_ON_MASK - usbser.sys When the PC app waits for income of data on IOCTL_SERIAL_WAIT_ON_MASK, long delay may be observed after the device sends data over the bulk IN EP. Extra ZLP speeds up the process on usbser.sys
c) Weak recovery from noise - usbser.sys Noise on the bus easily makes bulk IN traffic hang on usbser.sys Reset the device driver with IOCTL_SERIAL_RESET_DEVICE
Tsuneo
OMG.
The sort of mistake that can result in lost lives!
Hello Tsuneo,
I did not yet recreate this problem while a sniffer hangs on the bus. however, I can say that the device's endpoints are never triggered once it goes wrong (however, I have here a system running all night long without a failure). the ISR in the device is triggered, it is only that the endpoints are not. I did not write the PC side application so I cannot tell what its serial calls return...
Reset the device driver with IOCTL_SERIAL_RESET_DEVICE
I understand that this can only be done fro the PC side...? Not being a USB expert, how can I send a ZLP packet using Keil's software? is attempt to send an empty buffer good enough?
Come on, man, get a life...
One for the epitaph?
Look, I really don't have time to start one of these quarrels now (busy busy busy busy X 100^123, that is far more that the number of particles in the known universe). I would suggest you address Cpt. Vince for a Greek/Latin lesson (he made a few funny "fishy" remarks in Latin in the past; search the forum!).
Look, I really don't have time to start one of these quarrels now
Clearly your sense of humour is less well developed than your engineering skills.
I'll take that is a compliment.