Hi!
In my project i use mega168 and USART. Usually baudrate is 9600 and all is OK, but sometime i have to change it to 38400 temporary. When i change it from 9600 to 38400, after first packet device is frozen. OS is Win XP, transfer is half duplex, packet size is up to 64 bytes. Any help?
AVR-CDC problem
This is a problem with interrupt latency. If the USB interrupt is blocked for too long, USB packets are lost causing the host to stall the device. The problem occurs much more likely with higher baud rates.
Have you tried the latest version of the driver as it ships with PowerSwitch? We could slightly optimize some of the timing. This might improve the behavior. Please note that you may have to change some macro invocations since we have modified the interface to more esoteric features of the driver.
Have you tried the latest version of the driver as it ships with PowerSwitch? We could slightly optimize some of the timing. This might improve the behavior. Please note that you may have to change some macro invocations since we have modified the interface to more esoteric features of the driver.
-
Guest
Yes, i try new driver just now, but same problem happens. Look, device is blocked after baudrate change. If i start it with one speed (doesn't matter 9600 or 38400) all is ok, but when i change baudrate when device is working, error occurs. I was try to disable interrupts during baudrate change, but it was not good solution.
Anonymous wrote:Yes, i try new driver just now, but same problem happens. Look, device is blocked after baudrate change. If i start it with one speed (doesn't matter 9600 or 38400) all is ok, but when i change baudrate when device is working, error occurs. I was try to disable interrupts during baudrate change, but it was not good solution.
Sorry, i did not see that i was no logged in.
If you are sure that you have no bug in your baud rate setting code, then
one possible problem might be data toggling on the USB side.
When the data stream is reset, it must be initialized to either DATA0 or DATA1 (don't know which, please look at the code for a definitive answer). It is possible that setting the baud rate resets the stream and thus requires an initialization of data toggling.
one possible problem might be data toggling on the USB side.
When the data stream is reset, it must be initialized to either DATA0 or DATA1 (don't know which, please look at the code for a definitive answer). It is possible that setting the baud rate resets the stream and thus requires an initialization of data toggling.
Now i connect scope to see what happens on the serial line. I have connected PC - CDC - my device. Communication is half duplex, packets up to 64 bytes.
1. set br 9600, send packet, receive packet
2. set br 38400, send packet, receive timeout (nothing received)
3. set br 9600, send packet, receive timeout (nothing received)
4. set br 38400, send packet, receive timeout (nothing received)
From step 2 communication is broken. PC sends packets and receive nothing. But on the serial lines all is correct. When PC send a packet, CDC transfer it to my device, device send answer, but CDC does not transfer it back to the PC.
1. set br 9600, send packet, receive packet
2. set br 38400, send packet, receive timeout (nothing received)
3. set br 9600, send packet, receive timeout (nothing received)
4. set br 38400, send packet, receive timeout (nothing received)
From step 2 communication is broken. PC sends packets and receive nothing. But on the serial lines all is correct. When PC send a packet, CDC transfer it to my device, device send answer, but CDC does not transfer it back to the PC.
Receive and transmit data are sent through different endpoints. Receive data is transferred through a bulk-in endpoint.
Your example suggests that this bulk-in endpoint stalls when you set the baud rate. Windows hosts stop polling bulk-in endpoints when an error occurs, e.g. when the device does not react to a poll or if data toggling gets out of order.
I really suspect that you need to reset data toggling for the bulk-in endpoint when the baud rate is set.
Your example suggests that this bulk-in endpoint stalls when you set the baud rate. Windows hosts stop polling bulk-in endpoints when an error occurs, e.g. when the device does not react to a poll or if data toggling gets out of order.
I really suspect that you need to reset data toggling for the bulk-in endpoint when the baud rate is set.