Re: [avrdude-dev] Fwd: FTDI flashing stops at different positions

[Daniel Schulz]

2012/7/20 Hannes Weisbach <address@hidden>:

...
>> -vvvv of, it stops again at 97%.
>> Idont really know what to do. Should I buy a "real" flashing device?
>> Or what can you recommend?
> Since your issues seem to be timing related, I don't think anymore your 
> problem relates to the infinite loop I was talking about.

Hm I've heard from another avrdude user, that some days ago avrdude
starts making some problems. He is on avrasp, but it works not
reliable for now. He is on linux too. Maybe there are issues on
udev/usb or whatever?!


>> Ah, additionally I've tried to get a log, but there is only a
>> FTDI LOG: 80 20 fb 82 00 00
>> FTDI LOG: 80 60 fb 82 00 00
>> repeatedly in the file. Is this right?!
> No. there should be more. This is only the flashing of the programming led 
> (for the standard avrftdi configuration).

Sounds strange because I used the standard procedure to redirect the
output to a file by using a ">" - and on the file i only have the
lines mentioned above. On the screen there is much more output, but
this would not be redirected tothe file - dont ask why, I've no clue!!

>> My command line looked like this:
>> avrdude -p m8 -c avrftdi -b 1000000 -U
>> flash:w:/home/daniel/ng/quax/17a410_i2c_r08/hex/bl-17a_p40_m1.hex:a
>> -vvvv >avrdude_quax.log
> As I said, -b 1000000 is too fast. The additional output on the terminal 
> slows the program down. Try -b 10000.

But if I use 100000 or less, nothing happens - the flashing process
stops at 0%! I will try it on another computer.
Maybe it is important for you: my Linux is a debian sid derivative:
siduction, kernel 3.4-4.towo-siduction-amd64 x86_64 (64 bit, gcc:
4.7.0)

> Ha! By browsing through the source, I think I found the source of your 
> problem:
> Someone committed a faulty flush-routine, which cleans buffers instead of 
> flushing them ("ftdi_usb_purge_buffers()"). If you set your programming speed 
> too high, data in transfer buffers will be deleted by this call (instead of 
> being pushed to the AVR). This is the reason why -vvvv helps - it slows the 
> program flow down, because the program has to do terminal I/O. You can choose 
> a lower frequency (10kHz should be fine). At worst you have to keep -vvvv on 
> :(
> I have the fix for this ready too. I will submit it in the next week or so.

> Best regards,
> Hannes