Re: [avrdude-dev] Bad programming speed on AT90S8535 using AVRdude

[Brian Dean]

On Mon, Nov 17, 2003 at 11:46:04AM +1100, idefixx wrote:

> I did some oscilloscope measurments on the SCK signal (using pony
> programmer dongle) and found out the following:

Excellent sleuthing!

> Why does AVRdude perform so many min_ and max_write_delay's? And why
> does the behaviour change at 40% ?

I think your delays are caused by the data polling flash code.  I can
no longer find a datasheet for the AT90S8535, however, I'm assuming it
is similar to an ATmega8535, and it's datasheet says that when you
poll the flash after writing a value, it reads back as 0xff until the
value is written at which time the chip is ready to accept another
value.  Some chips have two data polling values to contend with,
depending on the memory type being written, thus the config file
supports up to two read-back values.  It is a difficiency in the
AVRDUDE logic that both are checked.  However, if only 1 polled
readback value is supported for that part/memory type, both readback
values should be set to the same thing.

My guess is that, at around 40% through your code, you have a lot of
zero-valued data, which matches the second polled read-back value
defined in the config file for the AT90S8535 and that causes AVRDUDE
to wait the max programming time as per the datasheet recommendation.
Since that chip only supports 1 readback value of 0xff for the FLASH
memory, try setting 'readback_p2' to 0xff (same as readback_p1) and
see if that helps or eliminates the problem.

We should never really be trying to even write 0xff to FLASH, I think
that optimization was made a long time ago, so in theory, we should
never go into the usleep() wait code for this condition.

Let us know the result - if that works, we'll fix the config file.

Good work!

-Brian
-- 
Brian Dean
address@hidden
http://www.bsdhome.com/
http://www.bdmicro.com/