Problems programing ATMEGA 64

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

HI
Ive been at this for hours and have decided to ask for help. I am using a USBASP, Ive tried various software to try and write the file but I am at a loss.

I am currently using AVRDUDESS and am using the following

-c usbasp -p m64 -B 0.5 -e -U flash:w:"C:\Users\Paul\Desktop\XProg 5.7.4\Firmware\Flash 5.5.5.bin":a -U eeprom:w:"C:\Users\Paul\Desktop\XProg 5.7.4\Firmware\EEPROM 5.5.5.bin":a -U lfuse:w:0x2F:m -U hfuse:w:0xCA:m -U efuse:w:0xFF:m -U lock:w:0x3C:m

This is the error I am getting every time

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0100
             0xff != 0x19
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

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

Are you by any chance one of the 1000s?? of people that has tried to use MISO and MOSI for programming pins? If so look at the datasheet carefully.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

Thanks for the reply. I only know the basics so am very noobish, What are the 1000s?

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

Read it as:

"Are you by any chance one of the thousands of people that has tried to use MISO and MOSI for programming pins?"

David (aka frog_jr)

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

I think he means, "thousands of people" - as in

Are you by any chance one of the thousands of people that has tried to use MISO and MOSI for programming pins? 

 

EDIT

 

frog_jr beat me to it!

Last Edited: Sun. Dec 31, 2017 - 02:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah yes. I am using the MISO MOSI pins. I am following the instructions I was given

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

*******

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

Last Edited: Sun. Dec 31, 2017 - 03:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Avinitlarge wrote:

Ah yes. I am using the MISO MOSI pins. I am following the instructions I was given

 

Except you're not. Or rather, you are.

 

If you follow the PCB trace from the pin you've labeled MOSI it connects to pin 2 on the mega64 which is PE0 which is the pin you use for programming by connecting it to MOSI on the programmer. But it's not MOSI on the mega64.

 

 

Confused?

 

 

 

 

So, the diagram you posted is correct (probably) for programming the mega64. It's just that the labeling is confusing.

'This forum helps those who help themselves.'

 

pragmatic  adjective dealing with things sensibly and realistically in a way that is based on practical rather than theoretical consideration.

Last Edited: Sun. Dec 31, 2017 - 03:55 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah, Ive just traced it, The USBAsp is actually connected to PE0 and PE1

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

Ok so the answer to my question is no. The ISP interface seems to be correct.

 

It looks like byte 0x0100 (and maybe the rest of the flash) is not being programmed, you need to wait for someone with experience with your programmer for additional help.

 

The fuses seem to be ok.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

Ok so the answer to my question is no. The ISP interface seems to be correct.

 

It looks like byte 0x0100 (and maybe the rest of the flash) is not being programmed, you need to wait for someone with experience with your programmer for additional help.

 

The fuses seem to be ok.

I think you are correct, I read the flash and it is a TINY file, Shows as 0k. When I opened it in HXD, It wasn't even a full line

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

Which file are we talking about? You are trying to program 2 files, Flash (Flash 5.5.5.bin) and EEPROM (EEPROM 5.5.5.bin).

 

Which program did you use to generate those 2 files? Usually the Atmel tools generate a .hex for flash and a .eep file for EEPROM or a combined .elf file.

 

I guess the error is in Flash as it would be programmed first.

I read the flash and it is a TINY file

Do you mean a very small file or a file meant to be programmed into a Tiny series chip?

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

js wrote:

Which file are we talking about? You are trying to program 2 files, Flash (Flash 5.5.5.bin) and EEPROM (EEPROM 5.5.5.bin).

 

Which program did you use to generate those 2 files? Usually the Atmel tools generate a .hex for flash and a .eep file for EEPROM or a combined .elf file.

 

I guess the error is in Flash as it would be programmed first.

I read the flash and it is a TINY file

Do you mean a very small file or a file meant to be programmed into a Tiny series chip?

 

 

I got the files from the suppliers website. The error is with the flash, the EEPROM verifies fine.

The file I read back was very small

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

Avinitlarge wrote:
I got the files from the suppliers website.

So have you contacted that "supplier"?

 

How about providing a link so that we can see what you're talking about?

 

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

js wrote:
It looks like byte 0x0100 (and maybe the rest of the flash) is not being programmed,

Did Santa Claus bring you a new crystal ball?  How does the snippet of "log" given earlier tell us that it was a flash address that does not compare?

 

Show the "log" of the full ISP sequence.  It should start with a successful Read Signature. 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude.exe: Device signature = 0x1e9602
avrdude.exe: erasing chip
avrdude.exe: set SCK frequency to 1500000 Hz
avrdude.exe: reading input file "C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX"
avrdude.exe: input file C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX auto detected as Intel Hex
avrdude.exe: writing flash (65526 bytes):

Writing | ################################################## | 100% 16.35s

avrdude.exe: 65526 bytes of flash written
avrdude.exe: verifying flash memory against C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX:
avrdude.exe: load data flash data from input file C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX:
avrdude.exe: input file C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX auto detected as Intel Hex
avrdude.exe: input file C:\Users\Paul\Desktop\xprog\Firmware\Flash 5.5.5.HEX contains 65526 bytes
avrdude.exe: reading on-chip flash data:

Reading | ################################################## | 100% 9.84s

avrdude.exe: verifying ...
avrdude.exe: verification error, first mismatch at byte 0x0100
             0xff != 0x19
avrdude.exe: verification error; content mismatch

avrdude.exe done.  Thank you.

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

Here are the files from the website https://www.dropbox.com/s/dl87b2...

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

Indeed an "interesting" situation.  The signature matches ATmega64.  Erase is done.  If a high address, I'd think about bootloader area.

 

It might be interesting to read back the "bad" flash image, and take a peek at it with an appropriate viewer/editor.  Just this byte?  Or more?  0xff is an "erased" value.

 

 

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Did Santa Claus bring you a new crystal ball?

Along with a new crystal eye.

 

May want to try and lower the clock speed from 1.5MHz, it should work but one never knows.

 

The size of the hex file looks interesting, only 9 bytes short of a full chip??

 

And I'm not going to sign into Dropbox to see the files even though I have an account.

 

 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

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

theusch wrote:

Indeed an "interesting" situation.  The signature matches ATmega64.  Erase is done.  If a high address, I'd think about bootloader area.

 

It might be interesting to read back the "bad" flash image, and take a peek at it with an appropriate viewer/editor.  Just this byte?  Or more?  0xff is an "erased" value.

 

 

 

 

I will post the dump tomorrow as its on my other computer. I was also thinking it could be a bootloader issue. Ive tried various other hex files I have and non of them are being written to the mega, It used an arduino and can write to that with no issues.

Now, the boot loader. In device manager, the Xprog shows as an Xprog, Is this because of the bootloader? Sorry for the noobish question

Ive tried to write at various speeds, no difference