Objective Development Forums

Have you tried to measure while you read the entire flash? You should see at least one second of activity. It may be hard to read off the frequency during that time, but we don't need exact figures anyway. A storage scope would, of course, be helpful.

My old scope doesn't measure this very well. I tried during the reading process but the scope just doesn't handle it too well. And it could be me not knowing how also. But if I'm reading this right, it looks to be a pulse width of 5 usec.

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.

I am supplying 9V into a 5V reg (7805) on the breadboard for the 8515. Measured a couple of times just to verify. 4.99V according to my Fluke. Works well though with parallel cable thru Bascom. Any other thoughts?

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?

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).

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.

The 8515 is powered via battery. I do not use usb power for it, just ground, reset, sck, mosi & miso. The usb hub/doper is powered via motherboard.

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.

I have sent the email. Thanks.

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.]

All seems to be okay now as I can successfully used avrdude serial & hid modes. Avrstudio is also now working via pc usb port. I really appreciate all your time and effort in this project as well as putting up with me.

Once again, thank you.
Tommie

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

This must be a problem with the programming algorithm. I don't have a mega16 for testing, though. Has anybody else seen this problem?

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?