[avr-chat] Funny verification happenings with uisp and avrdude on a ATMega8L

[Stuart Longland (VK4MSL)]

Hi all,

Firstly, I'm a bit of a newcomer to AVR programming.  Done a bit with
MSP430 and ARM in the past, but AVR is something different.

I've got a project where I'm using the ATMega8L.  Ultimately this will
be running with a 4MHz crystal oscillator, but for initial stages, I've
just got the MCU on a bread board, powered from a 4.5V (3 dry cells)
supply, and running on its own internal oscillator.

Digging around in the junk box, I was able to cobble together a
programmer loosely based on the DASA serial cable; the differences:

        - TXD, CTS and DTR are routed through a MAX232 buffer IC
        - RTS feeds into the base of a BC548B which pulls down nRESET
        - At one point, I had RXD also routed through the MAX232

Consequently, I need to tell both uisp and avrdude to invert the
signals.  No problem, uisp I specify -dinvert=reset,sck,mosi,miso and it
works.  Similarly avrdude, I just define a new programmer.

With this set up, I'm able to do a chip erase and program the chip.  I
find however, that the chip refuses to run the program I give it.  On
verification, it fails:

> address@hidden ~/projects/batteryvalue-wmon $ uisp -v=2 
> -dinvert=reset,mosi,miso,sck -dprog=dasa -dserial=/dev/ttyUSB0 -dt_sck=500 
> -dvoltage=4.5 -dpart=atmega8 -dt_wd_flash=18000 --erase --upload --verify 
> --segment=flash if=hello.hex 
> AVR Direct Parallel Access succeeded after 0 retries.
> Atmel AVR ATmega8 is found.
> t_wd_flash = 18000
> Erasing device ...
> Reinitializing device
> AVR Direct Parallel Access succeeded after 0 retries.
> Atmel AVR ATmega8 is found.
> t_wd_flash = 18000
> Uploading: flash
> #####
> (total 136 bytes transferred in 6.40 s (21 bytes/s)
> Polling: count = 3, min/avg/max = 87.99/88.04/88.13 ms
> Verifying: flash
> #flash error at address 0x0: file=0x12, mem=0x00
> flash error at address 0x1: file=0xc0, mem=0x00
> flash error at address 0x2: file=0x2d, mem=0x01
> flash error at address 0x3: file=0xc0, mem=0x01

I've tried tinkering with -dvoltage (tried 3 and 5 as well) -dt_wd_flash
and -dt_sck without success on uisp; and similarly -i on avrdude.  I
show the uisp output above, as the mem= output seems rather telling ...
0x00 twice, then 0x01 twice, then 0x02 twice... why such a consistent
pattern?

avrdude will program the chip, but it fails on the verify step.  I do
believe my problem is either something I'm doing wrong with the
hardware, or some funny edge case that my hardware configuration is
triggering.

For reference, the software versions in use are:
> address@hidden ~/projects/batteryvalue-wmon $ uisp --version
> uisp version 20050207
> (C) 1997-1999 Uros Platise, 2000-2003 Marek Michalkiewicz
> 
> uisp is free software, covered by the GNU General Public License.
> You are welcome to change it and/or distribute copies of it under
> the conditions of the GNU General Public License.
> 
> address@hidden ~/projects/batteryvalue-wmon $ avrdude --version
> [...]
> 
> avrdude version 5.11.1, URL: <http://savannah.nongnu.org/projects/avrdude/>

Host platform is Gentoo Linux/AMD64, with a crossdev-built avr-gcc
toolchain.

Anyone able to shed some light as to why I'd be seeing such an odd bit
pattern in the flash?
-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.

-- 
Stuart Longland (aka Redhatter, VK4MSL)      .'''.
Gentoo Linux/MIPS Cobalt and Docs Developer  '.'` :
. . . . . . . . . . . . . . . . . . . . . .   .'.'
http://dev.gentoo.org/~redhatter             :.'

I haven't lost my mind...
  ...it's backed up on a tape somewhere.