[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [avrdude-dev] Verify errors,

From: Daniel Williamson
Subject: RE: [avrdude-dev] Verify errors,
Date: Fri, 18 Jul 2003 10:40:22 +0100

Yesterdays testing,

I told win 2k not to never use interrupts on the parallel port, and i set
the min and max delays to 9000
I had a few good writes but then I got some errors, mainly on location
0x0100, and 0x4800, as alex said it's always on a page boundary.  When the
error occurrs, inspecting the data in the chip reveals that either two or 4
bytes are incorrectly set to 0xff starting at the page boundary.  Today I've
set the min delay to 18000 and the max to 32000 and see how it goes. so far
I've had 6 good writes!


-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Daniel Williamson
Sent: 17 July 2003 09:43
To: Avr Dude (E-mail)
Subject: RE: [avrdude-dev] Verify errors,

Erm didn't you mean the dual processors not being the problem?  I'll look at
the data in pony prog and compile a list of locations as well.

Interesting how we're both running w2k SP2?  I never had any problems before
the upgrade.  I also found that like others it seems to be fine for several
attempts and then will suddenly start failing.

I've told w2k to not use interrupts on the parallel port so maybe that will
help,  I'll send a message later to let you know how it goes.


-----Original Message-----
From: address@hidden
[mailto:address@hidden Behalf
Of Alex Shepherd
Sent: 16 July 2003 22:55
To: address@hidden
Subject: RE: [avrdude-dev] Verify errors,

> Right, I've looked through the archived for the thread called
> program error?
> It seems to end with alex saying he had Win2K SP2 on a Dual
> Celeron 466,
> I'm running a 1.1 GHz Athlon but the same OS.

Hmmm... that would tend to suggest my dual processor being the problem. That
just leaves the timers in cygwin or some other subtle flaw!

> What was the conclusion, apart from doubling the timing on
> the processor
> defenition?

We have not reached a conclusion yet. Not many people seem to have this
problem and it probably works fine on the code maintainers PCs - there in
lies the problem. :(

I have had a play around with the 4.0.0 source code bundle and can
.configure and recompile it under the cygwin install I have but my system is
not up to the mark to do a CVS checkout and build. It has problems building
the configure scripts.

I have made several changes already and will continue to play with it. I
wondered if there was an issue with timing and so someone came up with an
alternative timing mechanism using the select() function, but so far I have
not been able to apply this patch locally. I guess I will have to do it
manually. :(

I did read somewhere that the cygwin people had done some changes to the
implementation of usleep and family to now call nanosleep() which must have
been recently (earlier this year) added to cygwin. I was not able to find
any comments about why they changed to this so I wonder if there was an
issue that someone has fixed with the new nanosleep() implementation.

My observations are that the verify error is always at the beginning of a 64
byte block so I now suspect that the code is not waiting long enough between
blocks. Can you note the verify error locations and preferably have a look
at the location in the AVR FLASH with PonyProg and see what the value is in
FLASH? I am pretty sure mine were all still at FF which is a bit suspicious.

The overall programming time under Win2K seems to be faster compared to
running under Linux on the exact same hardware. Under Win2K it takes about 8
seconds to program my bit of test code (6.8k long) but on Linux it take
about 11-12 seconds. So this tells me that either delays are shorter on
Win2K or somehow the code path on Linux is much longer - maybe doing the LPT
port IOCTLs.



avrdude-dev mailing list

avrdude-dev mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]