Go Down

Topic: Random verification errors when flashing a bare atmega328p via USBtinyISP (Read 1 time) previous topic - next topic

michael_x

I have an atmega328p running on a breadboard and I'm using usbtinyisp to program it.

The chip runs at internal 8MHz and I have added a suitable entry to my Boards list.

It is powered by the usbtinyisp providing 5V. All works fine for small sketches.
With larger sketches, I notice read verification errors at random  adresses:

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0c00
            0x2e != 0x80
avrdude.exe: verification error; content mismatch


I have the impression it's better when I don't use the IDE's function 'Upload using Programmer' but when I run avrdude maually, like this:

>C:\arduino-1.0.1\hardware\tools\avr\bin\avrdude.exe -v -p m328p -c usbtiny
   -U flash:w:C:\Users\<...>\Temp\build4374060643153925675.tmp\MyTest.cpp.hex:i

The only disadvantage here is that every new IDE start creates a new Temp\build... directory and I have to adjust my bat file.

However when my MyTest.ino grows even more, this trick using avrdude.exe externally also does not help any more.
A sketch of 13k works well:
avrdude.exe: reading on-chip flash data:
Reading | ################################################## | 100% 26.60s
avrdude.exe: verifying ...
avrdude.exe: 13230 bytes of flash verified

A sketch of nearly 16k fails "always", but on different locations.
( See first sample output:  0x0c00 is well in an area that was written fine with a smaller sketch )

And the sketch behaves different after another upload try, sometimes it runs anyway, sometimes it hangs, sometimes only most functions work
This makes me guess the problem is in Writing, not in Verification.

There are lots of timing parameters logged, which do not tell me too much, nor do I know where to tune them eventually:

Code: [Select]
avrdude.exe: Version 5.11, compiled on Sep  2 2011 at 19:38:36
            Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
            Copyright (c) 2007-2009 Joerg Wunsch

            System wide configuration file is "C:\WinAVR-20100110\bin\avrdude.conf"

            Using Port                    : lpt1
            Using Programmer              : usbtiny
avrdude: usbdev_open(): Found USBtinyISP, bus:device: bus-0:\\.\libusb0-0001--0x1781-0x0c9f
            AVR Part                      : ATMEGA328P
            Chip Erase delay              : 9000 us
            PAGEL                         : PD7
            BS2                           : PC2
            RESET disposition             : dedicated
            RETRY pulse                   : SCK
            serial program mode           : yes
            parallel program mode         : yes
            Timeout                       : 200
            StabDelay                     : 100
            CmdexeDelay                   : 25
            SyncLoops                     : 32
            ByteDelay                     : 0
            PollIndex                     : 3
            PollValue                     : 0x53
            Memory Detail                 :

                                     Block Poll               Page                       Polled
              Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages MinW  MaxW   ReadBack
              ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- ---------
              eeprom        65     5     4    0 no       1024    4      0  3600  3600 0xff 0xff
              flash         65     6   128    0 yes     32768  128    256  4500  4500 0xff 0xff
              lfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
              hfuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
              efuse          0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
              lock           0     0     0    0 no          1    0      0  4500  4500 0x00 0x00
              calibration    0     0     0    0 no          1    0      0     0     0 0x00 0x00
              signature      0     0     0    0 no          3    0      0     0     0 0x00 0x00

            Programmer Type : USBtiny
            Description     : USBtiny simple USB programmer, http://www.ladyada.net/make/usbtinyisp/
avrdude.exe: programmer operation not supported

avrdude.exe: Using SCK period of 10 usec
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.05s

avrdude.exe: Device signature = 0x1e950f
avrdude.exe: safemode: lfuse reads as E2
avrdude.exe: safemode: hfuse reads as D0
avrdude.exe: safemode: efuse reads as 5
avrdude.exe: NOTE: FLASH memory has been specified, an erase cycle will be performed
            To disable this feature, specify the -D option.
avrdude.exe: erasing chip
avrdude.exe: Using SCK period of 10 usec
avrdude.exe: reading input file "C:\<...>\Temp\build4374060643153925675.tmp\MyTest.cpp.hex"

avrdude.exe: writing flash (13230 bytes):

Writing | ################################################## | 100% 40.08s



avrdude.exe: 13230 bytes of flash written
avrdude.exe: verifying flash memory againstC:\<...>\Temp\build4374060643153925675.tmp\MyTest.cpp.hex:
avrdude.exe: load data flash data from input file C:\<...>\Temp\build4374060643153925675.tmp\MyTest.cpp.hex:
avrdude.exe: input file C:\<...>\Temp\build4374060643153925675.tmp\MyTest.cpp.hex contains  13230 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 26.60s

avrdude.exe: verifying ...
avrdude.exe: 13230 bytes of flash verified

avrdude.exe: safemode: lfuse reads as E2
avrdude.exe: safemode: hfuse reads as D0
avrdude.exe: safemode: efuse reads as 5
avrdude.exe: safemode: Fuses OK

avrdude.exe done.  Thank you.


Any ideas ?

Does it help to add a serial connection to my breadboard, burn a bootloader, and upload sketches via the Serial port ?

Coding Badly


Check for loose connections.

Other than the programmer, is anything connected to the MOSI, MISO, or SCK pins?

Are you certain the target is running at 8 MHz (when your program runs does the timing seem correct)?

Try a different section of the breadboard.

Other than the target, is USBtinyISP powering anything else?


Quote
Does it help to add a serial connection to my breadboard, burn a bootloader, and upload sketches via the Serial port ?


It would be good test and I believe uploads will be faster.  If that works, the problem lies with the programmer or wiring.  If that does not work, the target is toast.

michael_x

#2
Nov 18, 2012, 09:47 pm Last Edit: Nov 19, 2012, 12:50 am by michael_x Reason: 1
Quote
Check for loose connections.
Other than the programmer, is anything connected to the MOSI, MISO, or SCK pins?

An SD card module. Removed, no change:
13k works, 16k shows error, this time:
avrdude.exe: verification error, first mismatch at byte 0x0500

Quote
Are you certain the target is running at 8 MHz (when your program runs does the timing seem correct)?

Yes, 1000 millis are a second, roundabout. How precise must it be ?

Other than the target, is USBtinyISP powering anything else?  
-> Not really, SD card signal lines removed, edit: a few mA from a DS1307  and a TSOP31238 IR Receiver. And a 3.3V regulator on the SD module (to feed LCD signals with 3.3V when drained by atmega outputs)

I also have the impression that serial upload is faster ( or is it due to the fact that the other system runs at 16MHz  ?)
I'll give it a test try, though it should not be a solution.
My goal was to build a naked system with just the required stuff: no external oscillator, no serial line, no bootloader.

Is there a way to write to flash from a sketch ( how does bootloader do it ? ) ???
I could run a kind of memory check then ?

What is strange to me is that an address ( 0x0500 ), which obviously works well in the 13k sketch, now fails with a 16k sketch.
And that the failing address varies.


Thanks, so far. Any more ideas welcome ;)

michael_x

#3
Nov 18, 2012, 10:06 pm Last Edit: Nov 18, 2012, 10:28 pm by michael_x Reason: 1
Removing the SD module and its 5->3.3V regulator completely,  does not help:

The failing address is still random. 3 uploads produce these messages:

avrdude.exe: verification error, first mismatch at byte 0x1280
            0x80 != 0x77

avrdude.exe: verification error, first mismatch at byte 0x2300
            0x10 != 0xd8

avrdude.exe: verification error, first mismatch at byte 0x0c00
            0x2e != 0x80

Does it say something that it's always a xx80 address ???

Will grab a USB to Serial and tell how it goes with a Bootloader.


Could not stop experimenting:
Slowing avrdude down, ( -B 50 ) helped !
Is the default (10 µs) too fast (or critical) for an 8MHz chip ?
Is it a problem of my breadboard wires, or the 20 cm between usbtinyisp and the breadboard ?

So many questions, with probably vague answers :-)

Coding Badly

Quote
Are you certain the target is running at 8 MHz (when your program runs does the timing seem correct)?

Yes, 1000 millis are a second, roundabout. How precise must it be ?


Close enough.  I was looking for 8 MHz versus 1 MHz.

Coding Badly

What is strange to me is that an address ( 0x0500 ), which obviously works well in the 13k sketch, now fails with a 16k sketch.


It could a problem with the programmer.  I vaguely recall something like being discussed in the forum.  If you have an Arduino board, I suggest trying it as a programmer.

Coding Badly

Could not stop experimenting:
Slowing avrdude down, ( -B 50 ) helped !


Huh.

Quote
Is the default (10 µs) too fast (or critical) for an 8MHz chip ?


No.  The minimum SCK time is four (target) clock cycles or 4/8000000*1000000 = 0.5 µs.  10 µs should be way beyond the minimum necessary.

Quote
Is it a problem of my breadboard wires, or the 20 cm between usbtinyisp and the breadboard ?


I doubt 20 cm wires are the problem.  I'm fairly certain I've used wires that long without any problems.

It's looking more and more like a problem with the programmer.

michael_x

Quote
It's looking more and more like a problem with the programmer.

That recommends using it one last time to flash a bootloader, then to use an USBtoSerial adapter instead for serial uploads "the Arduino way".

When I'm busy with Arduino, I either apply code changes, or are happy to see it run 24*7.
Spending a full Arduino as ISP would be just a test, not a solution.


Thanks for your comments!

Go Up