avrdude + Atmel ICE = Verification Error

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

Hi,

 

I had to use avrdude for our production site. I created a GUI using python.

 

Issue is that the verification always fails and the controller doesnt work after programming.

 

Same controller when I programmed using the Atmel Studio from the same Atmel ICE it works just fine.

 

controller: ATmega128rfa1

programmer: ATMEL ICE

 

Command used:

avrdude.exe -e -p m128rfa1 -P usb -c atmelice -U lfuse:w:0xe2:m -U hfuse:w:0x90:m -U efuse:w:0xff:m -U flash:w:D:/HEXFile.hex:i

 

 


avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0002
             0x02 != 0x52
avrdude.exe: verification error; content mismatch

This topic has a solution.
Last Edited: Tue. Mar 17, 2020 - 11:54 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1


If you are saying that a command run at the command line behaves different to the identical command invoked within Python then assuming it really is being invoked identically the assumption has to be that the "environment" it runs in is different.

 

But first to check that it is being invoked the same replace avrdude.exe with something like:

#include <windows.h>
#include <stdio.h>
#include <stdint.h>


int main(int argc, char * argv[])
{
    for (int i = 0; i < argc; i++) {
        printf("arg: %d, = %s\n", i, argv[i]);
    }
}

If I build and run that and set the command line arguments to be the same as your command above I see the following both invoking it at the command line and then from within Python:

 

 

It looks as if I've got the Python invocation correct as I appear to have got the program to receive identical parameters but I'd suggest you do a check like this to be sure you Python/GUI invocation is the same as the command line invocation.

 

If it is then I'd suggest that it must be something about the "command environment" that the Python's subprocess.run() generates that is different to your normal command prompt invocation.

 

 

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

Hi thank you so much for very detailed information. However the issue has nothing to do with python.

My concern is the same HEX file with same ATMEL ICE programmer the controller works fine if i use Atmel Studio to program. But if i use AVRDUDE, then the controller doesn't work and AVRDUDE throws verification error.

Difference between working and non working scenarios is AVRDUDE.

The issue happens with or without python invocation.

Last Edited: Thu. Mar 12, 2020 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

firoz3321 wrote:
The issue happens with or without python invocation.

You could have mentioned that in the first place!

 

What happens if you program with Atmel Studio, and then just verify with AVRDUDE ?

 

Or if you program with AVRDUDE, and then verify with Atmel Studio ?

 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh right, apologies - I misunderstood your description. In that case maybe use the AS7 command line tool (atprogram.exe) rather than avrdude.exe ? The command line tool should work the same as AS7 (because basically the GUI invokes it!)

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

Hi Thank you @awneil, but to suppor the avrdude i had to replace the drivers using 'Zadig' and since then the ATMEL Studio doesnt detect the ATMEL ICE and repair of Atmel Studio didnt help either.

 

@clawson, I wasnt aware of this. This too doesnt detect the ATMEL ICE as i changed the drivers but as a final solution I may look into this if i dont have other workarounds with AVRDUDE.

 

Thank you for valuable feedback. I really hope avrdude works 

Last Edited: Fri. Mar 13, 2020 - 09:08 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

firoz3321 wrote:
... i had to replace the drivers using 'Zadig' and since then the ATMEL Studio doesnt detect the ATMEL ICE ...
ideally a driver re-install from within Atmel Studio

firoz3321 wrote:
... and repair of Atmel Studio didnt help either.
then clean may be the other option

 


How do I get my Tool to be recognized by Atmel Studio? | Atmel Studio 7

IIRC, the most recent Atmel Studio 7 clean :

Atmel Studio 7 - Problems installing - Application cannot start | AVR Freaks

 

"Dare to be naïve." - Buckminster Fuller

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi 

 

I finally am able to get AVRDUDE to work but only if I remove the FUSE settings from avrdude command

 

Below command with ONLY FUSE Settings is working

 

avrdude.exe -p m128rfa1 -P usb -c atmelice -U lfuse:w:0xe2:m -U hfuse:w:0x90:m -U efuse:w:0xff:m

This command with ONLY HEX File  is also working:

avrdude.exe -p m128rfa1 -P usb -c atmelice -U fl:w:D:/HEXFile.hex:i

The below Command with both FUSE and HEX doesn't work:

 

 avrdude.exe -p m128rfa1 -P usb -c atmelice -U lfuse:w:0xe2:m -U hfuse:w:0x90:m -U efuse:w:0xff:m -U flash:w:D:/HEXFile.hex:i

 

For now, I am sending 2 commands, first I am sending the FUSE command and then the HEX command.

 

Any suggestions?

 

 

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

gchapman wrote:
ideally a driver re-install from within Atmel Studio

 

Can you please let me know how this can be done ?

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

"Dare to be naïve." - Buckminster Fuller

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

It didnt work and that was the first thing i tried and many other ways from many suggestions online too. the device manager Says its detected without any errors but Atmel Studio cannot find it.

Any ways as long as AVRDUDE works i am ok with it.

 

It will help me if someone can let me know why this works:

 

avrdude.exe -p m128rfa1 -P usb -c atmelice -U flash:w:D:/HEXFile.hex:i

 

but this doesnt work ?

 

  avrdude.exe -p m128rfa1 -P usb -c atmelice -U lfuse:w:0xe2:m -U hfuse:w:0x90:m -U efuse:w:0xff:m -U flash:w:D:/HEXFile.hex:i

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

You are removing the CHKDIV8 fuse @1MHz and then expecting to program the Flash @8MHz.
I am not sure whether avrdude will speed up between individual commands on the same session.
It should be easy enough to test the avrdude /atmelice behaviour on any regular AVR e.g. a Uno.
.
The actual ISP operation is a few ms per page. But sending SPI data to a 1MHz target is what slows down the programming.
I suggest that you do fuses and flash in two separate avrdude commands.
.
Untested. But I am sure that others have discovered the quickest way to do production programming with atprogram.exe or avrdude.exe
I doubt if the 128RFA1 is different to any other chip
.
David.

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

david.prentice wrote:
You are removing the CHKDIV8 fuse @1MHz and then expecting to program the Flash @8MHz.

I don't think I fully understood. Where am I mentioning the avrdude to flash at 8Mhz ? the FUSES are fixed for end application and any change in fuse setting will not work (Code as Fuse checking)

 

 

david.prentice wrote:
I suggest that you do fuses and flash in two separate avrdude commands.

This is my current implementation. I guess I will continue with this then.

 

Thank you all for your patience and support.

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

 

I have the same problem but although I use two separate commands unfortunately it doesn't work.

I want to use AVRdude for production programming also. I can program alright with AVRstudio (ISP) but when I try with AVRdude I get the verification error.

The fuse change command works fine and I can read the programmer through AVRdude. Any ideas ?

 

The commands are the following:

avrdude -p t85 -C avrdude.conf -P usb -c jtag2isp -U flash:w:ATtiny85_Reader_v1.0b.hex -v -e -u -b 3   //<< not working

avrdude -p t85 -P usb -c jtag2isp -U efuse:w:0xFF:m -U hfuse:w:0xD5:m -U lfuse:w:0x62:m -u              // OK

 

         Programmer Type : JTAGMKII_ISP
         Description     : Atmel JTAG ICE mkII in ISP mode
         Vtarget         : 5.0 V
         SCK period      : 8.00 us

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x1e930b (probably t85)
avrdude: safemode: hfuse reads as D7
avrdude: safemode: efuse reads as FF

avrdude: safemode: hfuse reads as D7
avrdude: safemode: efuse reads as FF
avrdude: safemode: Fuses OK (E:FF, H:D7, L:62)

avrdude done.  Thank you.

 

Here is a great GUI for AVRdude showing the error

 

 

 

 

Last Edited: Mon. Sep 20, 2021 - 01:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go on.  You are using 8MHz RC with CLKDIV8 i.e. 1MHz

And then you select -b3 i.e. 3us SCK period (333kHz)

 

Select -b5 i.e. 5us SCK period (200kHz)

 

In theory -b4 i.e. 250kHz should be ok for 1MHz / 4 but 200kHz is "safer"

 

I am surprised that -b3 would have even connected.

 

Life is much simpler if you just copy-paste the avrdude command line.   And copy-paste the result.

I would not trust any avrdude "GUI".   They are designed to obfuscate anyone trying to help you.

 

David.

Last Edited: Mon. Sep 20, 2021 - 01:43 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:
I want to use AVRdude for production programming also. I can program alright with AVRstudio (ISP) but when I try with AVRdude I get the verification error.

Why not use atprogram.exe, its provided by MCS7, just for that purpose, and you already know it works.

 

 

FF = PI > S.E.T

 

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

David Prentice didn't write that quote?? Did the forum software actually tag that with the wrong ID during quoting?

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

clawson wrote:
Did the forum software actually tag that with the wrong ID during quoting?

Looks that way, I highlighted the text from #14 and clicked the quote button as usual.   Odd!

 

Let me try again:

Jimis wrote:
I want to use AVRdude for production programming also. I can program alright with AVRstudio (ISP) but when I try with AVRdude I get the verification error.

david.prentice wrote:
I want to use AVRdude for production programming also. I can program alright with AVRstudio (ISP) but when I try with AVRdude I get the verification error.

 

Ok, it seems I highlighted the text from #14, but hit the quote button from #15 to get the second one.....

I did not know the forum would let me do that....

 

FF = PI > S.E.T

 

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

There are lots of weird things about the Forum software.   I think that you just have to live with it !!

 

I still advise:

 

1.  copy-paste the actual avrdude command line

2.  think carefully about your clock fuses.

 

3.  the virgin chip from the factory comes as 8MHz div8 i.e. 1MHz

4.  if you want to run at 8MHz and program at a reasonable speed,  change clock fuses to 8MHz first.  Then program the flash

 

5.  there are several command line programming software programs e.g. atprogram.exe, avrdude.exe, ...

 

6.  using the correct command line arguments can speed up the programming job.  Return errors etc.

7.  GUI programs were invented by the Devil.   You can never trust them.   They don't return errors.

 

David.

Last Edited: Mon. Sep 20, 2021 - 03:29 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

david.prentice wrote:

Go on.  You are using 8MHz RC with CLKDIV8 i.e. 1MHz

And then you select -b3 i.e. 3us SCK period (333kHz)

 

Select -b5 i.e. 5us SCK period (200kHz)

 

In theory -b4 i.e. 250kHz should be ok for 1MHz / 4 but 200kHz is "safer"

 

I am surprised that -b3 would have even connected.

 

Life is much simpler if you just copy-paste the avrdude command line.   And copy-paste the result.

I would not trust any avrdude "GUI".   They are designed to obfuscate anyone trying to help you.

 

David.

Thanks for pointing that out David I actually didn't pay much attention to the frequencies but I have already used slower bit-clocks which I read in other threads which didn't work, but now I managed to get it working with -b 10 (100KHz) ! That's the minimum if you go higher it doesn't work so I guess it's the limitations from the circuit (breadboard) and voltages (4.9V). I attach the output file for anyone interested

 

I also managed to change the fuses in same command and this goes for the original poster firoz3321 . The command was this:

 

avrdude -c jtag2isp -p t85 -P usb -B 10 -v -U flash:w:"C:\a\ATtiny85_Reader_v1.0b.hex":a -U lfuse:w:0x62:m -U hfuse:w:0xD5:m -U efuse:w:0xFF:m

 

ki0bk wrote:

Why not use atprogram.exe, its provided by MCS7, just for that purpose, and you already know it works.

I was using the command line at start but GUI is quite helpful if you want to play around with the settings. Now that I have my final command I only need the command line tool for production a lot faster and I don't need to install MS7

 

Thanks a lot for helping :)

 

 

Attachment(s): 

Last Edited: Tue. Sep 21, 2021 - 07:34 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would expect -b4 to work fine.

Something is wrong if you require -b10

100kHz is unnecessarily slow.  Mind you the -b# argument only advises the shortest period.   The hardware programmer uses the nearest compliant SCK.

Regular AVRs will program at low voltages.   Only the brain-dead TPI devices require 5V.

 

Yes,  it is human nature to try random settings and clutch at straws.

But it is wise to copy-paste the actual command line with the actual result.

 

Yes,  a GUI might be an easy way to play.   Just remember that you have no confidence in the behaviour,  no record of your "setting",  no record of any result.

 

So always verify your "successful" GUI experiment with a proper recordable command line execution.

 

Oh,   AVRDUDESS is probably reliable.    I just would never bet my life on it.

 

David.