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

[Hannes Weisbach]

Am 17.07.2012 um 21:50 schrieb Daniel Schulz:

> Hi Hannes!
> 
> Yes, your guess was right - linux. The version is the 5.11.1, compiled
> on Oct 18 2011 - I guess, it is the most current version.
> 
> Hm, it is very difficult to describe. Sometimes it goes to 99% - but
> the read out was not 100% the same, a little bit is missing at the end
> and the whole file is much bigger then the "source"-hex file:
> source.hex: 8376byte
> readout.hex: 19204byte
I guess when you read the flash back, avrdude reads back all 8k, but your hex 
file does not contain 8k of code.
My second guess would be that the difference from 8k binary data in the flash 
to the file size of 19204 bytes is caused by the Intel hex file format.
Is the beginning of readout.hex identical to source.hex? Or the other way 
around: readout.hex should only contain 0xff after about 8376 bytes.
> 
> The other time it works up to 87% and then the read out was around 4000byte.
> If I play with the timing (-b 1000000 or -b 2000000) it works up to
> 99% or 87% but if I decrease the time it works to 11% or even 0%.
That is odd. Did you change the hex-file in between? If your problems are 
caused by the polling-problem it will always hang at the same point - 
regardless of the programming speed or other factors.
> But
> something is working after the output hangs, as I have monitored it
> with a oscilloscope. It seems to be loop.
Can you please run a programming with -vvvvv (5 times)? There will be a lot of 
output. You can redirect stderr and stdout to a file and send that file as 
attachment.
> So can you remember when you
> did your patch to the source?
I had a look and it seems the bug is still in the current SVN revision, so I 
did not submit the patch yet.
> But I'm not sure, if it is the software,
> because I flashed some atmegas in the near past.
> Maybe it is because of my whole setup? Have a look at on
> https://plus.google.com/u/0/photos/115078017107993743967/albums/5765804148693231409/5765804151018534226
Well, I would not use -b 1000000 on that setup. Maybe two zeros less. I can't 
see a short ground connection from your chip to your programmer.

-- 
Hannes