AVR Doper
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
OK. 5 usec is fast enough to avoid any timeouts.
Another possible cause for timeouts is that the supply voltage for the target is too low. There is a tighter limit for programming than for other operations. If the internal programming voltage does not reach its minimum, programming won't work and we'll never get the OK from the target. The operation eventually times out.
Another possible cause for timeouts is that the supply voltage for the target is too low. There is a tighter limit for programming than for other operations. If the internal programming voltage does not reach its minimum, programming won't work and we'll never get the OK from the target. The operation eventually times out.
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
Look here: SUCCESS
C:\WinAVR\bin>avrdud -c stk500v2 -p 8515 -P avrdoper -y -u -U flash:w:test.hex
avrdud: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.41s
avrdud: Device signature = 0x1e9301
avrdud: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdud: erasing chip
avrdud: reading input file "test.hex"
avrdud: input file test.hex auto detected as Intel Hex
avrdud: writing flash (384 bytes):
Writing | ################################################## | 100% 1.59s
avrdud: 384 bytes of flash written
avrdud: verifying flash memory against test.hex:
avrdud: load data flash data from input file test.hex:
avrdud: input file test.hex auto detected as Intel Hex
avrdud: input file test.hex contains 384 bytes
avrdud: reading on-chip flash data:
Reading | ################################################## | 100% 0.55s
avrdud: verifying ...
avrdud: 384 bytes of flash verified
avrdud done. Thank you.
I plugged in a generic USB hub into mainboard then plugged in the doper. Why is that making a difference?
C:\WinAVR\bin>avrdud -c stk500v2 -p 8515 -P avrdoper -y -u -U flash:w:test.hex
avrdud: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.41s
avrdud: Device signature = 0x1e9301
avrdud: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdud: erasing chip
avrdud: reading input file "test.hex"
avrdud: input file test.hex auto detected as Intel Hex
avrdud: writing flash (384 bytes):
Writing | ################################################## | 100% 1.59s
avrdud: 384 bytes of flash written
avrdud: verifying flash memory against test.hex:
avrdud: load data flash data from input file test.hex:
avrdud: input file test.hex auto detected as Intel Hex
avrdud: input file test.hex contains 384 bytes
avrdud: reading on-chip flash data:
Reading | ################################################## | 100% 0.55s
avrdud: verifying ...
avrdud: 384 bytes of flash verified
avrdud done. Thank you.
I plugged in a generic USB hub into mainboard then plugged in the doper. Why is that making a difference?
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
Works only in HID. Tried via other mode and rec'd:
C:\WinAVR\bin>avrdud -c stk500v2 -p 8515 -P com4 -y -u -U flash:w:test.hex
avrdud: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.23s
avrdud: Device signature = 0x1e9301
avrdud: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdud: erasing chip
avrdud: reading input file "test.hex"
avrdud: input file test.hex auto detected as Intel Hex
avrdud: writing flash (384 bytes):
Writing | ################################################## | 100% 1.03s
avrdud: 384 bytes of flash written
avrdud: verifying flash memory against test.hex:
avrdud: load data flash data from input file test.hex:
avrdud: input file test.hex auto detected as Intel Hex
avrdud: input file test.hex contains 384 bytes
avrdud: reading on-chip flash data:
Reading | ################################################## | 100% 0.50s
avrdud: verifying ...
avrdud: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdud: verification error; content mismatch
avrdud done. Thank you.
This all thru a Hong Kong generic usb hub (GL850A chipset).
C:\WinAVR\bin>avrdud -c stk500v2 -p 8515 -P com4 -y -u -U flash:w:test.hex
avrdud: AVR device initialized and ready to accept instructions
Reading | ################################################## | 100% 0.23s
avrdud: Device signature = 0x1e9301
avrdud: NOTE: FLASH memory has been specified, an erase cycle will be performed
To disable this feature, specify the -D option.
avrdud: erasing chip
avrdud: reading input file "test.hex"
avrdud: input file test.hex auto detected as Intel Hex
avrdud: writing flash (384 bytes):
Writing | ################################################## | 100% 1.03s
avrdud: 384 bytes of flash written
avrdud: verifying flash memory against test.hex:
avrdud: load data flash data from input file test.hex:
avrdud: input file test.hex auto detected as Intel Hex
avrdud: input file test.hex contains 384 bytes
avrdud: reading on-chip flash data:
Reading | ################################################## | 100% 0.50s
avrdud: verifying ...
avrdud: verification error, first mismatch at byte 0x0000
0x0c != 0x00
avrdud: verification error; content mismatch
avrdud done. Thank you.
This all thru a Hong Kong generic usb hub (GL850A chipset).
This is indeed very interesting and I have no obvious explanation for it.
One possible explanation: Bulk endpoints need lots of CPU time on the AVR. The timing with your host may be so that there is no (or almost no) time left for programming the AVR. Thus the timeout. When you insert a hub, timing parameters change and there may now be enough CPU time left.
What's interesting, though, is that you get the same behavior in HID mode. There's no such timing problem in HID mode as described above (no bulk endpoints involved).
Are you connecting the two supplies (USB and target) directly? That should not be done and it may cause all kinds of problems.
One possible explanation: Bulk endpoints need lots of CPU time on the AVR. The timing with your host may be so that there is no (or almost no) time left for programming the AVR. Thus the timeout. When you insert a hub, timing parameters change and there may now be enough CPU time left.
What's interesting, though, is that you get the same behavior in HID mode. There's no such timing problem in HID mode as described above (no bulk endpoints involved).
Are you connecting the two supplies (USB and target) directly? That should not be done and it may cause all kinds of problems.
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
Sorry, but I'm out of ideas. At least you've found a configuration which works.
There's one more thing you can try: If you use the "-v" option to avrdude multiple times, you get more verbose output. Please use "-v -v -v" to see all the communication detals. Please send that to me in e-mail (http://www.obdev.at/avrusb/feedback.html) as an attachment (would probably be too large for the forum).
I'm interested in logs for HID mode with hub (programming works) and HID mode without hub (programming fails). I could then compare the two to hopefully get a hint from the difference.
Please also create a log of Serial Emulation mode with hub and without hub. There seems to be a difference between the two, although both fail: The former fails during verify while the latter fails with a timeout.
There's one more thing you can try: If you use the "-v" option to avrdude multiple times, you get more verbose output. Please use "-v -v -v" to see all the communication detals. Please send that to me in e-mail (http://www.obdev.at/avrusb/feedback.html) as an attachment (would probably be too large for the forum).
I'm interested in logs for HID mode with hub (programming works) and HID mode without hub (programming fails). I could then compare the two to hopefully get a hint from the difference.
Please also create a log of Serial Emulation mode with hub and without hub. There seems to be a difference between the two, although both fail: The former fails during verify while the latter fails with a timeout.
OK, thanks for the valuable input! I have found a bug in the ISP code when doing "value polling". This mode is used for older devices such as the AT90S8515.
We will release a new version soon which fixes this firmware bug.
[This still does not explain why connecting through a hub makes a difference, though.]
We will release a new version soon which fixes this firmware bug.
[This still does not explain why connecting through a hub makes a difference, though.]
-
- Posts: 17
- Joined: Sat Jan 20, 2007 6:55 pm
Hi all.
I've got the same problem.
My command line is:
avrdude.exe -c stk500v2 -P com4 -p m16 -e -v -U flash:w:"S:\cerebro.hex":i -B 10
I got the same timeout (0x80) problem. I'm using 5V VCC.
The interesting is that I can read the flash into a file and also read/write the eeprom!
Only the flash write fails
I've got the same problem.
My command line is:
avrdude.exe -c stk500v2 -P com4 -p m16 -e -v -U flash:w:"S:\cerebro.hex":i -B 10
I got the same timeout (0x80) problem. I'm using 5V VCC.
The interesting is that I can read the flash into a file and also read/write the eeprom!
Only the flash write fails
Hi! Sorry for bad english
Thanx for AVR-Doper! I was buy the board with components and preprogrammed ATMega8 - http://icdarom.ru/show_good.php?idtov=2130723908.
And I think its based on AVR-Doper project. The scheme is identical, but added 20-, 28-, and 40-pin sockets.
When I make the device and connect it to PC with USB 2.0 Windows see it as Unknown Device and can't install the driver. But when connect to old PC with USB 1.1 all works OK. If I connect to PC with USB 2.0 throu the 4-port USB 1.1. HUB it's too works OK. I think AVR-Doper have a bug - when it receive USB 2.0 packet it work uncorrect. But other USB 1.1 devices (USB-keyboard, mouse, joystick, mobile phone) works OK with USB 2.0 port.
And i have a question - how i can program the AT89C4051 controller? Or information about supported chips here - http://icdarom.ru/show_good.php?idtov=2130723908 is incorrect and AVR-Doper can't burn conrollers like AT89C4051 - without SPI interface?
Thanx for AVR-Doper! I was buy the board with components and preprogrammed ATMega8 - http://icdarom.ru/show_good.php?idtov=2130723908.
And I think its based on AVR-Doper project. The scheme is identical, but added 20-, 28-, and 40-pin sockets.
When I make the device and connect it to PC with USB 2.0 Windows see it as Unknown Device and can't install the driver. But when connect to old PC with USB 1.1 all works OK. If I connect to PC with USB 2.0 throu the 4-port USB 1.1. HUB it's too works OK. I think AVR-Doper have a bug - when it receive USB 2.0 packet it work uncorrect. But other USB 1.1 devices (USB-keyboard, mouse, joystick, mobile phone) works OK with USB 2.0 port.
And i have a question - how i can program the AT89C4051 controller? Or information about supported chips here - http://icdarom.ru/show_good.php?idtov=2130723908 is incorrect and AVR-Doper can't burn conrollers like AT89C4051 - without SPI interface?