Go Down

Topic: Mega 2560 R3, eXtreme Burner and AVR Programmer (Read 19815 times) previous topic - next topic

DaveO

Thanks CrossRoads

I have just done that, and set the Tools > Programmer to 'usbasp'

I did see lights flashing on the AVR Programmer.

Result on the Mega2560 is the same - LED remains on.

From this test, does it sound like something in a config file relating to the 'usbasp' programmer ?

the file : arduino-1.5.2\hardware\arduino\avr\programmers.txt contains :
Code: [Select]

usbasp.name=USBasp
usbasp.communication=usb
usbasp.protocol=usbasp
usbasp.program.protocol=usbasp
usbasp.program.tool=avrdude
usbasp.program.extra_params=-Pusb

CrossRoads

I didn't realize you were using arduino-1.5.2.
I was going under the assumption that you had IDE 1.0.3 or 1.0.4
I have not used 1.5.x for anything yet.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

DaveO

#17
Mar 30, 2013, 02:38 pm Last Edit: Mar 30, 2013, 02:42 pm by DaveO Reason: 1
Thanks CrossRoads

I have great progress / success, but not certain that it is correct, and don't know how to check it.

Did a search on the verification error that I was seeing after upload and verification of the bootloader :
Code: [Select]

avrdude: verification error, first mismatch at byte 0x1e000
        0xff != 0x0d


and found this page :
http://arduino.cc/forum/index.php?topic=126667.0

In the third post ( reply # 2 ) Andre_1949 mentions using different fuses.

Changed my avrdude batch file to use the fuses mentioned in the above linked post, to:
Code: [Select]

cd\
cd\ArduinoBuilder\code\Blink
avrdude -v -p atmega2560 -c usbasp -U lfuse:w:0xc2:m -U hfuse:w:0x99:m  -U efuse:w:0xff:m -U lock:w:0x3f:m -U flash:w:Blink.hex


and it uploads and works - LED flashes as expected.


I think that avrdude, as used by the Arduino IDE for 'Upload using Programmer', first reads the fuses, erases the chip, writes the hex file, and then writes the fuses back again. So if the fuses were incorrect before the upload, they will still be incorrect after the upload.

I think that I have confirmed this as follows :

This does not affect an upload of the Bootloader hex file using avrdude from the command line, as the fuses are contained in the hex file.

Any other command line upload fails because I was writing the wrong fuse values, as in :
Code: [Select]

avrdude -v -p atmega2560 -c USBasp -U lfuse:w:0xFF:m -U hfuse:w:0xD8:m  -U efuse:w:0xFD:m -U lock:w:0x0F:m -U flash:w:Blink.hex


Arduino IDE upload over USB was fine, because it utilised the bootloader and does not affect the fuses ( fuses that were in the bootloader hex file ).

Arduino IDE 'Upload using Programmer' fails, because the wrong fuses are being read from, and re-written to the board.

Also, after uploading from command line ( and changing the fuses, I can now upload from IDE 'using Programmer' and that also now works ( because it is now reading valid fuses, and re-writing those same valid fuses back at the end of the process ).

So the question now stands : am I using the correct fuse settings for the Mega 2560 R3 board ?


CrossRoads

If you have the fuses that are in the boards.txt file, you have the correct fuses.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

DaveO

well that's the bit I just can't understand.

The boards.txt file shows :
Code: [Select]

mega2560.bootloader.low_fuses=0xFF
mega2560.bootloader.high_fuses=0xD8
mega2560.bootloader.extended_fuses=0xFD
mega2560.bootloader.file=stk500v2/stk500boot_v2_mega2560.hex
mega2560.bootloader.unlock_bits=0x3F
mega2560.bootloader.lock_bits=0x0F


but those did not work. I was banging my head against a brick wall trying to find the cause of the problem : suspect USB cable, usbavr drivers, pin settings, hex file creator, bootloader, AVR Programmer board, etc, etc.

And all the time, I was assuming that the fuse settings used in avrdude were correct.

The upload ( or more specifically the running of the uploaded sketch ) only worked using :
-U hfuse:w:0x99:m  -U efuse:w:0xff:m -U lock:w:0x3f:m

Now I just need to figure out if these settings will damage the board in any way.

CrossRoads

Run those settings thru a fuse calculator, see what they do for you:

http://www.gammon.com.au/forum/?id=11653
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

DaveO

Hi CrossRoads

Totally SOLVED !!

And my sincere thanks for your input and very valuable comments and contribution.

I posted on av AVR related forum, about the different fuses - the Mega2560 ones that everyone says should work, and the very different ones that I found in a single post ( that did work ).

Part of the reply that I got was :
Quote

The differences between the two sets of fuses are:
- The first one assumes there is an external clock source in form of a crystal on your board, the second uses the internal RC oscillator for clocking the AVR.
- The first one sets the AVR to start executing a so called bootloader (a program stored in a special part of the AVR, that in turn will communicate over some arbitrary media and program the application proper into the rest of the flash). The second one does not have this bootloader set.
-The second one had disable "brown-out detection", a way for the AVR to detect low voltage conditions and to do a reset if one has occurred.


I also received a link to http://www.frank-zhao.com/fusecalc

I applied the fuses that the Arduino forum experts said should be used :
-U lfuse:w:0xFF:m
-U hfuse:w:0xD8:m
-U efuse:w:0xFD:m
-U lock:w:0x0F:m

I then looked for the bootloader that was mentioned.

Found it in the Lockbit section :
-- Boot Loader Protection Mode 3 : LPM and SPM prohibited in Boot Loader Section.

not certain exactly what that means, but since I an using avrdude to erase the chip and then upload the hex file, I assumed that the bootloader ( or protection of the bootloader section ) is not required, and changed it to :
-- Boot Loader Protection Mode 1 : No Lock on LPM and SPM in Boot Loader Section.

This changed the lock fuse to:
-U lock:w:0xFF:m

Used AVRdude to upload the hex file with these fuses via the AVR Programmer to the ICSP pins, and working perfectly.

I am so pleased to have learnt something ( with help, of course ) that I thought I would never understand.

Thanks again for your input - you certainly helped steer me in the right direction.

CrossRoads

Glad you got it worked out.

Here's the details of the bits from the data sheet.  More reading is required to interpret the bits for making changes.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

BillO

#23
Jun 06, 2013, 10:14 pm Last Edit: Jun 06, 2013, 10:17 pm by BillO Reason: 1
Did you actually get rid of the error when when you burn the bootloader?

We are able to reproduce the error:

Code: [Select]
avrdude: verification error, first mismatch at byte 0x1e000
        0xff != 0x0d
avrdude: verification error; content mismatch



Using either the IDE (1.0.1 - 1.0.5) or avrdude.  So it's not the IDE, it's avrdude that is creating the error.  We were also able to verify that the bootloader is indeed being burned correctly at 0x3E000.  What we can't figure out is why is avrdude looking for it at 0x1E000 on the verify cycle!!?  Does anyone have any insight into that?

It seems others have had this problem also:
http://forum.arduino.cc/index.php?topic=169831.0
http://forum.arduino.cc/index.php?topic=115531.0

I know that Mr. Gammon's approach might work well, but shouldn't this be fixable?

DaveO

From what I can recall, I understand ( and I only have limited mental free space, so trust nothing I say ) that the AVRdude, when used, wiped out the bootloader section on the chip.

Then it uploaded the hex file, and I think that AVRdude read the existing fuses from the board ( which told it to start at position 'x3' because positions before x3 were protected for the bootloader ), wrote the hex file to the chip starting at position 'x3', re-wrote the fuses, and then tried to verify starting at position 'x1'  ( x1 and x3 are just variables, as I don't know the correct terms to use - they are just different addresses on the chip ). As it could not find the data in x1 that it had written to x3, it gave the error of a mismatch.

My solution was to first replace the fuses ( see reply posted just above ) and change :
-U lock:w:0xFF:m

so that it disabled the protection of the bootloader area.

This allowed AVRdude to write the hex file ( which was the hex of the bootloader ) starting at position x1 ( instead of x3 ), verification passed, and I was then able to connect the board to the IDE again because the bootloader now existed in the correct / expected space on the chip.

Sorry that I can't be more technical or accurate than that, but I am sure that some of the experts will appear soon and most likely shoot down my post and provide a better / more accurate / completely different explanation.


DaveO

to add to your statement of :

it's avrdude that is creating the error.  We were also able to verify that the bootloader is indeed being burned correctly at 0x3E000.  What we can't figure out is why is avrdude looking for it at 0x1E000 on the verify cycle!!?  Does anyone have any insight into that?

I think that when AVRdude writes, it starts at the first non-protected address - in this case 0x3E000

When it verifies, it does not expect, or take into account, that there is a bootloader on the chip in a protected area, and assumes that the data was written starting at the first address 0x1E000.

The only way to make / force AVRdude to burn the bootloader to the correct / expected bootloader location, is to disable the protection of that area.

AVRdude seems to be used often if the user wants to use the max space on the chip for the sketch, and is prepared to sacrafice the bootloader to free up space. Removing the bootloader means you can't access it with the IDE, so maybe AVRdude expects the bootloader to not be there. The fact that it wrote the data starting at 0x3E000, but is looking to verify at 0x1E000 seems to indicate that it does not remember the exact starting address, but rather uses two different methods : when writing the data, start at the first non-protected address. But when verifying, start at the first address.

BillO

I think it's actually worse.  I think it's a coding error.  avrdude is not taking the extended addressing into account when it verifies.  I wonder if the same thing would happen on an Atmega2561, or is it limited to the 2560, which is just a extended addressing version of the 1260.  0x1E000 is where the bootloader goes on the Atmega1260.  Anyway, it's something they should fix, but if they did it may be a while until it gets into the Arduino release which is always quite far behind on its version of avrdude.

DaveO


I think it's actually worse.  I think it's a coding error.  avrdude is not taking the extended addressing into account when it verifies.  I wonder if the same thing would happen on an Atmega2561, or is it limited to the 2560, which is just a extended addressing version of the 1260.  0x1E000 is where the bootloader goes on the Atmega1260.  Anyway, it's something they should fix, but if they did it may be a while until it gets into the Arduino release which is always quite far behind on its version of avrdude.


I don't see it as a coding error.  The flags on the chip tell AVRdude that the bootloader area is protected, so AVRdude used the first available address after that protected space to upload the hex file.

To make AVRdude write in the protected area, you need to un-protect the reserved bootloader area.

Under normal conditions of just wanting to upload a normal sketch, the existing way it is working should be fine. But the fact that you are wanting to upload a bootloader, you need to unlock that protected area.  Maybe this is a positive feature of AVRdude in that it will not simply overwrite the flag settings for the protected area.  Having said that, it does seem to have a bug in the starting point when doing the verification.

I think that you only need a bootloader if using the IDE to load sketches, but if you are going to use AVRdude to upload the hex, you can disable the protection and use the full chip space.

BillO

I think you'd get the same error if you loaded a program of over 131072 bytes in length without the bootloader.

DaveO


I think you'd get the same error if you loaded a program of over 131072 bytes in length without the bootloader.


Sorry, but I am a bit lost.

I thought we were discussing how to load and verify the Bootloader ( I think size around 23,000 bytes ).

I think that as long as the bootloader area is protected, AVRdude will ( and correctly so, imho ) not write into that area. Unfortunately it tries to verify from the first address, not taking into account the protected area.

Unlock the area, write the bootloader, lock it back up again. Then upload sketches using the IDE.

If you don't need the IDE and intend uploading with AVRdude every time, just unlock the area and use it, and leave it unlocked. No point in protecting a bootloader area when there is no bootloader.


Go Up