Programming ATmega32A with AVR DRAGON_ISP always returns with "verification error"

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Update: 2016-0618 - I have submitted this issue as an avrdude bug.  https://savannah.nongnu.org/bugs/index.php?48261 BUT would like to receive input from the community.

 

Hello all:

First off, I have done my homework on this matter and would not have posted seeking assistance unless it was a last resort.  smiley

 

Background:  Ex-disti-FAE for ATMEL as one of my support lines.  Very familiar with ATmega48/88/168/328, ATtiny25/45/85, ATmega32U4, AT90USB1286 (and somewhat on the ATmega2560).  

 

Development environment:  Using Linux for development running AVR STUDIO in a "Virtual WINDOWS" environment.   AVRDUDE V6.3 for Linux.  ATmega32A, 16MHz external crystal, VCC = 5V (PwrSup is 1A capable).  Fuses set for external high-freq crystal, bootloader at 0x7E00, bootloader reset enabled (lfuse = 0x8F   hfuse = 0x96).

 

Quandary: developing code for ATmega32A; when using AVRDUDE to program FLASH using ISP with "DRAGON_ISP" programmer, AVRDUDE fails with:

avrdude: verification error, first mismatch at byte 0x7e00
         0xff != 0x0f

Command line invokation is:

avrdude -u -p m32 -c dragon_isp -B 1MHz -U flash:w:AVR_Specific_Builds/m32/ATTOBASICV234_m32-16MHZ-uart_btldr.hex

Partial dump from original HEX file around address 0x7E00:

:107D00000000000000000000000000000000000073
:107D10000000000000000000000000000000000063
:107D20000000000000000000000000000000000053
:107D30000000000000000000000000000000000043
:107D40000000000000000000000000000000000033
:107D50000000000000000000000000000000000023
:107D60000000000000000000000000000000000013
:107D70000000000000000000000000000000000003
:107D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:107D9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
:107DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3
:107DB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3
:107DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3
:107DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3
:107DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3
:107DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93
:107E00000F92CDB7DEB711248FE598E09EBF8DBFEE
:107E100084B714BE81FFD6D085E08EBD82E08BB9D9
:107E200088E18AB986E880BD80E189B98EE0B5D065
:107E3000BD9A26E080E39CEF54E040E29DBD8CBDFE
:107E400058BF08B602FEFDCF38B3342738BBA8951B
:107E50002150A1F788249924CC24C394F5E0DF2E87
:107E6000E1E1EE2E73E0F72E91D0813469F48ED0EB
:107E7000898398D08981823811F1813811F485E0A5
:107E800001C083E07FD07BC0823411F484E103C061
:107E9000853419F485E08ED072C0853561F476D0D2
:107EA000082F10E073D090E0982E8824802A912A21
:107EB000880C991C63C0863521F484E07BD080E077
:107EC000E1CF843609F03FC061D060D0B82E5ED0DB
:107ED00080E0881680E7980618F4F401F7BEE8956C
:107EE00000E610E053D0F80181938F01BA94D1F7E6
:107EF000F0E08F16F0E79F0618F0F401F7BEE89562

Addresses 0x7D00 to 0x7DFF is waveform data for DDS function.

 

After failure, partial dump of reback of FLASH memory around address 0x7E00.  Even the data starting at 0x7D00 is incorrect.  

:107D0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF83
:107D1000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF73
:107D2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF63
:107D3000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF53
:107D4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF43
:107D5000FFFF000000000000000000000000000025
:107D60000000000000000000000000000000000013
:107D70000000000000000000000000000000000003
:107D8000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF03
:107D9000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF3
:107DA000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3
:107DB000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFD3
:107DC000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFC3
:107DD000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFB3
:107DE000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFA3
:107DF000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF93
:107E0000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF82
:107E1000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF72
:107E2000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF62
:107E3000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF52
:107E4000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF42
:107E5000FFFFA1F788249924CC24C394F5E0DF2EFA
:107E6000E1E1EE2E73E0F72E91D0813469F48ED0EB
:107E7000898398D08981823811F1813811F485E0A5
:107E800001C083E07FD07BC0823411F484E103C061
:107E9000853419F485E08ED072C0853561F476D0D2
:107EA000082F10E073D090E0982E8824802A912A21
:107EB000880C991C63C0863521F484E07BD080E077
:107EC000E1CF843609F03FC061D060D0B82E5ED0DB
:107ED00080E0881680E7980618F4F401F7BEE8956C
:107EE00000E610E053D0F80181938F01BA94D1F7E6
:107EF000F0E08F16F0E79F0618F0F401F7BEE89562

 

All other ATmega devices program properly using ISP and JTAG, without incident, so I do not believe it is the DRAGON.  The ATmega32A programs properly using JTAG with AVRDUDE and DRAGON, only ISP fails using AVRDUDE.  Using DRAGON (1MHz sck) under AVR STUDIO, ISP programming is successful.

 

I have tried ISP with USBASP and USBtinyISP as well and they function correctly.

 

I have tried with both V6.3 and V6.2 of AVRDUDE.  I have not yet tried any other prior versions of AVRDUDE.  I have looked at the avrdude.conf for other "compatible devices" and found ATmega328p and ATmega329 are accurate.  Using AVRDUDE "-F" switch produces the same verification failure with these two part definitions.

 

I have tried various "-B" settings for AVRDUDE to no avail.  

I have tried using external 8MHz crystal to no avail.   

I have tried using internal 8MHz oscillator to no avail.  

 

I have four (4) NEW ATmega32A's, none are blown as I can successfully program all of them using JTAG but using ISP, all fail in the same manner.  Chinese fakes?  I do not see how as these parts do not look like it. They have ATMEL logo and date code of "1508".

 

Is this an AVRDUDE issue, an ATmega32A issue or combination of both?

 

Does anyone have any answers, ideas or clues to offer?

 

Thank you in advance.

 

Peace and blessings,

Scott

 

Last Edited: Sun. Jun 19, 2016 - 08:53 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Folks:

Is it possible for some one to test with their own AVR DRAGON and a Meg32A?  

 

What is very odd here is that I have generated two HEX test files, both with the full 32KB address range.  One is filled will all 0x00's and the other is random data.  Both files program into the Mega32A just fine.  

 

This lead me to believe that the HEX files generated by AVRASM.EXE (from AS 4.19) might be suspect.  They are, after all, missing data within address ranges where there would normally be 0xFF, which is perfectly legal.  And avrdude plays fine with these same files when programming with a USBtinyISP or USBasp with the same Mega32A's.  However, to disprove it, I used srec_cat to fill in the missing address ranges with 0x00's and again with 0xFF's to generate two separate full 32KB address files.  Once again, avrdude + DRAGON_ISP failed.

 

I have attached a few test files.  Can anyone that has access to an AVR DRAGON and an ATmega32A please download and test with their setup using avrdude, so I can confirm that this is not just happening to me?

 

My Mega32A is running on an external 16MHz crystal.  Fuses are:  lfuse = 0xBF and hfuse = 0x96.

 

Thank you.

 

Peace and blessings,

Scott

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not many people here use M32 unless they are from India surprise and the Dragon has always been flaky so not many people here use the beast.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi JS:

Thanks for the input.

 

When you say that the DRAGON has always been flaky, in what way?  

 

I've been using mine since about 2006 and never had any problems with it.  

 

I've used it in ISP, JTAG, HVPP, HVSP and DEBUGWIRE modes. 

 

On the M32, I know its an older part.  That's clear by its un-enhanced WatchDog timer.  I am using because it has a higher pin count than the M328.

 

Peace and blessings,

Scott

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if you had to buy a 40 pin PDIP AVR you would use anything from the pin compatible Mega164p to the Mega1284. If, for some reason, you have stock of the Mega32 then of course use them. wink

 

I have also used the Dragon in the past and I managed to blow one up, my fault, but many others simply had lots of failures. I still have one around but hardly used since I have a JTAG ICE MK1 (homemade), JTAG ICE MK2, 2 x JTAG ICE Mk3, Atmel ICE, STK500, AVRISP MK1 and an AVR910 style programmer and maybe some more somewhere.

 

Ah yes 3 Keyfob programmers for AVRs and another one from AlanK2 for AVRs/Xmega with another addition of the later shortly, another PDI programmer from DocJC. cheeky

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi JS:

Thanks for the additional reply.

 

Yes, I have stock of the Mega32A.

 

Okay, so yes, I do recall that I had blown my 1st and 2nd DRAGON nearly right away.  MOUSER replaced both of them and I have not had a problem with the 3rd.  Now that was 2006'ish.  I know that there was a problem with the TI voltage regulator on them and if for some reason the host's USB port could not provide the high inrush current then the TI voltage regulator would pop.  I believe that at that time, ATMEL had issued a statement on that particular problem and the "fix" was to use the DRAGON with a USB hub being externally powered.  I ordered a few of those TI voltage regulators "just in case" but never had a problem since the 3rd DRAGON.

 

What do you use for debugging in hardware?

 

Peace and blessings,

Scott

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have a circa 2007 Dragon. I have several ATmega32 chips.
I do not have any 32A chips. I can see no point in buying a 32A when a 324PA is better endowed in every way.
Of course, I am not from India where the 32A seems to be very popular.
.
My Dragon's firmware is updated to the current version of AS7
If you want me to ISP my ATmega32 chips with the Dragon, say so.
.
I can NOT believe that ISP behaviour would be different for a 32 or 32A.
Nor would it be different for any Mega chip e.g. 324PA.
.
Although Atmel are determined to destroy JTAGICE-mkII operation, the Dragon has worked with every version of AS4,5,6,7.
.
David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David:

Yes, please see if you can make your Mega32 fail with the DRAGON and avrdude as I have consistently been able to do.  My version of avrdude is 6.3 but I was able to make it fail with v6.0 and v6.2 as well.

 

I think my experiences and conditions have been documented fairly well for you to follow. 

 

Thank you.

 

Peace and blessings,

Scott

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, I will give it a go. Later this morning.
I presume that your -B1Mhz switch is parsed as -B1 i.e. 1us SCK period.
And you are using -pm32 i.e. it should suit mega32 and mega32A

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dave:

Here is the command line I am using.

avrdude -u -p m32 -c dragon_isp -B 1MHz -U flash:w:[file_name]

There is no "m32a" definition for AVR dude.  AVRDUDE v6.3 introduces a more easily (human) readable bitrate specification by letting one specify the bitrate in Hz, kHZ and Mhz now.  So the "1Mhz" would be the same as if using AS and setting the bitrate to "1Mhz".

 

Thanks!

 

Peace and blessings,

Scott

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What do you use for debugging in hardware?

It depends, at times the JTAG ICE MK1 with some clients provided boards (M128) as I don't want to risk the JTAG ICE MK2.

For most of my work I use JTAG ICE MK2 and AS4.18. (and a lot of assembler too but don't tell anyone)

 

For my latest project using the Xmega32E5 I have used one of the 2 x JTAG ICE Mk3 or Atmel ICE wit AS7.

 

I carry one of the JTAG ICE Mk3 with my laptop for field use, a few years ago I would take out the Dragon to some client's premises.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I put a mega32 onto a 16MHz board.

 

avrdude-6.1 produced verification errors with both -c dragon_isp and with stk500v2 (on a real STK500 board).

avrdude-6.1 worked fine with -c avrdude_jtag

avrdude-6.1 worked fine with -c usbasp

 

The Dragon worked fine in AS7.

 

I presume that atprogram.exe will work fine too.   After all,  this is probably how AS7 uses the Dragon anyway.

 

No,  I have not bothered to see why avrdude is going wrong.   Presumably this has come up before.

Nor have I installed avrdude-6.2 or avrdude-6.3

 

David.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David:

Thank you for checking and confirming that it was not my specific, albeit generic, setup.

 

In AS 4.19, the DRAGON_ISP works fine for me as well.  So it looks to be an DRAGON_ISP specific issue then.

 

Peace and blessings,

Scott

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No,   it seems to be an avrdude issue.

 

I did not try AS4.19.   I get fed up with firmware upgrade / downgrade.   Especially when ISP protocol is never going to change,

 

I suggest that you just use atprogram.exe or invest in a $3 USBASP.   Mind you,  they seem to be less than $1 now!

 

Why do you want to use a Dragon for ISP?

If you are developing,  you would use JTAG.

 

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi David:

Yes, that is my conclusion as well.  I didn't complete the sentence.  "It looks to be an DRAGON_ISP and avrdude specific issue." :)

 

In the original posting, which you may not have (completely) read, I stated that I have already testing this setup with USBtinyISP and USBasp (I have them both) and they work correctly.

 

I am using Linux as my development system.  I only use WINDOWS in a virtual machine when I use AS 4.19 for hardware debugging with the DRAGON.

I get fed up with firmware upgrade / downgrade. 

I did as well.  Not sure why every time AS version changes, there is a firmware upgrade.  I thought that aside from whether or not the MCU supports DEBUGWIRE, JTAG or TDI for hardware debugging, which should be known by the programmer, there should be little to no differences in the ISP, JTAG, TDI, HVSp and HVPP hardware modules since they are "IP cores being dropped into the particular MCU's design before fabrication. 

Why do you want to use a Dragon for ISP?

Because I can and it has worked well ... until the M16A/32A.  

 

I prefer the JTAG debugging interface but not all parts, like the ATtiny and many lower-pin-count ATmega series parts, do not support anything but DEBUGWIRE, which requires ISP (via AS) to set (and reset) the DWEN fuse.  My DRAGON is always on my bench and always used when I am developing and debugging code.  It is an indispensable tool.  Since I only use the "virtual WINDOWS machine" with AS4, there is no reason to "boot it" just to program an MCU.  Hence and since, I use Linux as my OS, avrdude seems to be the only (and not a bad) choice I have available.  I have written a programming script that runs under BASH that assists in easing the burden of repeated command line typing.  Yes, I know there are GUI front-ends but I prefer the command line interface.  My BASH script allows the selection of a particular MCU, the HEX files available for that MCU (or to set fuses), then a programmer that supports the chosen MCU.  Thus far, with avrdude, I am able to support the AVR-109 (LUFA CDC), ARDUINO, USBtiny, USBasp, DRAGON_ISP,  DRAGON_JTAG,  DRAGON_HVSP and  DRAGON_PP protocols.  DFU programming is supported but needs a different programming tool.

 

This is all part of the AttoBASIC project that I am soon to release a newer version that supports the ATtiny85, ATtint84, ATmega16(A) and ATmega32A devices.  At this time, with conditional assembly, I am generating 115 different build HEX files for 14 MCU's at 4 clock speeds each, some with/without USB SIO or with/without UART support, as well as with/without a bootloader.  The BASH script makes it easier for one to select all that was mentioned above and program their particular MCU.

 

Thank you again for checking the M32 for me.

 

Peace and blessings,

Scott

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not sure why every time AS version changes, there is a firmware upgrade.

But it is WORSE now since the later versions of AS7 introduced Jungo V12. If you are switching between older versions of Studio and AS7 then you need to actually switch the USB driver for the tool provided that you have separate tools for say AS7 and maybe AS6 or AS4, not just the upgrade/downgrade dance.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[off-topi comment ensues ...]

Some one I know has high hopes that AS will be integrated into MPLAB.  smiley  I am not holding my breath because I think there is much (disruption) going on out on "home base" for ATMEL.  I have a support ticket in on another issue, I posted it recently on AVRFREAKS concerning using the SPM instruction and an issue I am running into.  I was told three weeks ago, 2 days after submitting the ticket, that it "would be looked into" and I would hear back "ASAP".  No response after two weeks and even a "ping" asking for an update yields silence.  Local ATMEL FAE says he even escalated the issue (2 weeks into it) but still no response.  Sigh .....

 

Peace and blessings,

Scot