You are describing a phenomenon I have never experienced.
Well, consider yourself lucky then.
AFAIK the USB driver does not have any timeouts (with regard to the user packets) once the USB device is configured(although I would not call myself a USB pro). I have used libusb (MinGW, Windows XP) extensively and there an API has an explicit transfer request timeout YOU define. Could be an hour, a weekend or forever, but this timeout is the user's choice, not an underlying USB driver's timeout as your posts suggest.
That is not true. Once the setup packet is sent, the device has to respond in time, otherwise the OS will time it out and declare the device dead.
For example, increasing timeouts for the USB HID protocol in the Linux kernel:
http://lxr.free-electrons.com/source/drivers/hid/usbhid/hid-core.c (around line 158)
If you are debugging both applications you are free to set the timeouts arbitrarily long or disable those. OT: There is also a choice of an asynchronous communication.
Now, if host had not received an ACK from a device (because of uC's breakpoint) then it would retransmit the same packet 1ms later and it is pushing out those futile packets till death.
Um, certainly not. It will try a few times, but eventually it will give up and signal an error. Come on, if what you are saying was true, then the computer could never figure out that you have disconnected the USB device or cut its power (if it is self powered). It would just keep sending forever.
Can you give a reference?
May it be that the smartass STM32L1xx does NACKs when halted by debugger
That could also explain why I do not face those timeouts you describe. Just speculating
See the source code above. Also here you can search for the keyword "timeout":
http://lxr.free-electrons.com/ident?i=timeout Did you notice how many of those are in drivers that are in the "usb" subtree? Especially those in the "core" or "hid" in the filename. I obviously cannot show you Windows source code, but I am pretty sure it is going to be similar - it is basic functionality.
Also USB spec here (sorry, I don't have access to a "more official" one):
https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/usb-dev.htmlTransfers to an endpoint are serialised in the pipe. A transfer can either complete, fail or time-out (if a time-out has been set). There are two types of time-outs for transfers. Time-outs can happen due to time-out on the USBbus (milliseconds). These time-outs are seen as failures and can be due to disconnection of the device. A second form of time-out is implemented in software and is triggered when a transfer does not complete within a specified amount of time (seconds). These are caused by a device acknowledging negatively (NAK) the transferred packets. The cause for this is the device not being ready to receive data, buffer under- or overrun or protocol errors.
You are obviously referring to the second form - those are indeed controllable from software, when you are sending the setup packet. However, I am speaking about the first ones, there isn't any NAK from device necessary for that to happen. If the device doesn't reply in time, either by ACK or NAK, the host will consider it failed/disconnected and game over. The USB phy in the chip won't do that for you, it cannot know that you aren't busy at the moment and are able to reply to the incoming request.
This document even has some of the timeouts specified:
http://www.beyondlogic.org/usbnutshell/usb6.shtmlThey even make an explicit comment on the timeouts being an issue during debugging there.