I tried to build a minimal version of AVR-Doper. Everything works fine till the applications become bigger. A certain combination of characters in the hex-file causes the programmer to crash in CDC-mode (integrated in avr-studio. When i put a couple of bytes extra in the hex-file everything works fine.
The same hex-file programs fine using AVRdude in HID-mode.
If necessary, I can send you the hex file causing the programmer to crash.
Possible error in Stk500protocol
-
Guest
Every host i try has the same problem. When I let avrstudio log what's happening I get the following result (excerpt of the last few lines).
When I use a port monitor to spy what's going on in the communication, I get a the following response
Sending packet 05/16/2008 09:35:16.868
(5000ms) > 1B 1B 00 4A 0E
(5000ms) > 13 00 40 A1 0A 40 4C 20 FF 00 40 00 40 00 FE 1F
> FE 1F FE 1F FE 1F 00 0E 00 1E 00 10 00 10 00 10
> FE 1F FE 0F FE 1F FE 1F E0 00 B0 01 18 03 0C 06
> 06 0C 02 18 00 10 FE 1F FE 1F 00 10 00 10 00 10
> 00 10 00 10 00 10 FE 1F FE 1F
(5000ms) > 3F
Sequence number 27, message size 74, checksum 63
CMD_PROGRAM_FLASH_ISP
Receiving packet 05/16/2008 09:35:17.879
(5000ms) (expected 5 more bytes but timed out)
Sequence number n/a, message size n/a, checksum n/a
No data in packet
Returned status: Client: Total timeout exceeded (PC side gave up)
Sending packet 05/16/2008 09:35:22.887
(1000ms) > 1B 1C 00 03 0E
(1000ms) > 11 01 01
(1000ms) > 1B
Sequence number 28, message size 3, checksum 27
CMD_LEAVE_PROGMODE_ISP
Receiving packet 05/16/2008 09:35:25.891
(1000ms) (Error number: 128692)
(expected 5 more bytes but timed out)
Sequence number n/a, message size n/a, checksum n/a
No data in packet
Returned status: Client: Total timeout exceeded (PC side gave up)
Port closed
Returned status: Command succeeded
When I use a port monitor to spy what's going on in the communication, I get a the following response
as the reply on the data of packet with sequencenumber $1BStatus $C00000001
-
Guest
Possible error in stk-protocol
Dear,
It is not a problem with the STK-protocol, but a timing problem in the code for 16MHz. I tried exactly the same hardware, but compiled for 12 MHz and that works fine.
It is not a problem with the STK-protocol, but a timing problem in the code for 16MHz. I tried exactly the same hardware, but compiled for 12 MHz and that works fine.
OK, I finally had the time to try this myself. It works well with my computer (a Macbook Pro) and as you reported, it depends on the AVR's clock rate.
The problem is therefore very likely not an implementation bug in AVR-Doper, but the well known reliability problem of CDC mode.
It's still not known whether the transmission errors in CDC mode are caused by a driver bug or by communication errors. Anybody who captures a USB trace of such an error is welcome to submit it to us (obdev). See http://forums.obdev.at/viewtopic.php?t=1360&start=15 for an example. This example reveals a problem on the host side, though, not in our driver.
The problem is therefore very likely not an implementation bug in AVR-Doper, but the well known reliability problem of CDC mode.
It's still not known whether the transmission errors in CDC mode are caused by a driver bug or by communication errors. Anybody who captures a USB trace of such an error is welcome to submit it to us (obdev). See http://forums.obdev.at/viewtopic.php?t=1360&start=15 for an example. This example reveals a problem on the host side, though, not in our driver.