burning bootloader to mega and some questions

[d0ughb0y]

I was able to burn the bootloader to mega using usbisp/usbasp programmer using avrdude command.

avrdude -c usbasp -p m2560 -P usb -b 115200 -e -u -U lock:w:0x3F:m -U efuse:w:0xFD:m -U hfuse:w:0xD8:m -U efuse:w:0xFF:m
avrdude -c usbasp -p m2560 -P usb -b 115200 -V -U flash:w:ariadne_atmega2560.hex
avrdude -c usbasp -p m2560 -P usb -b 115200 -U lock:w:0x0F:m

Questions:
How do I change the location/address in eeprom where network info is stored. Most programs will store data starting at address 0, I think it will be better if the bootloader stores at the end of the eeprom.

I am running a webserver in my arduino program. I just need to add a uri that will make my code execute these lines of code to reboot the arduino right? Then I start tftp program to upload the new firmware?

#include <avr/wdt.h>
....
wdt_disable();
wdt_enable(WDTO_2S);
while(1);

thanks for sharing the program.

[loathingKernel]

Hi

first of all, this is not a support forum, this is a place to report actual or perceived problems with the bootloader.

To change the location the settings are stored, take a look at https://github.com/codebendercc/Ariadne-Bootloader/blob/master/hardware/ariadne/bootloaders/ariadne/w5100.c#L50 and also at the sketch that writes them. I do not think it is a good idea to move the settings to the end because different MCUs have different sizes of EEPROM. This adds complication without any gain, because in either way the user has to be aware of what is being stored in the EEPROM and handle it in his code. Programs will store where you tell them to store, so you can start from address 64 instead of 0 and do not overlap with the settings.

Yes, those lines of code are pretty much correct and they will reboot the Arduino.

[d0ughb0y]

Thanks for the reply.

You can consider this an issue since this statement in readme needs to be corrected. As avrdude can be used with usbisp to burn bootloader to mega.

In the case of Arduino Mega the previous ISPs do not reliably work because of design differences. To install the bootloader in these boards you will need one of the more expensive models, like Atmel's AVRISP mkII, Olimex's AVR-ISP-MK2 or another similar programmer

I'll just move my program data up by 64 bytes on the eeprom address space for now. I can see how moving it to the end can be a problem to some who uses the end address space (my program actually uses both). How about detecting the location using marker signatures, so users can place the 64 byte eeprom data anywhere they want? And perhaps define it as a struct.

Thanks.

[loathingKernel]

It hasn't work for me with my USBasp-like ISP so I cannot consider it reliable. I feel better if a warning is there even if it works for some people, rather than not at all.

I have made a patched version of the EEPROM library that handles that problem transparently to the user. You should check out https://github.com/codebendercc/Ariadne-Bootloader/tree/master/libraries/NewEEPROM. I prefer to keep the settings in an array rather than a struct to avoid possible alignment issues.

[d0ughb0y]

Using Arduino IDE with USBasp programmer works with UNO, and I agree it does not work for the mega (verification error at the end). Have you tried using the avrdude commands yet? I tested multiple times and it worked every time burning the default mega bootloader and the ariadne bootloader to mega.

Ok, now I see what the newEEPROM class is for. It is meant as replacement to original eeprom functions by adding 0x40 offset to the read/write address. I use eeprom_read_block and eeprom_write_block functions which calls eeprom_read_byte and eeprom_write_byte in the original avr/eeprom.h. Do you need to implement those functions in newEEPROM? as they probably won't use the newEEPROM version of read and write byte that adjusts the offset. I was just going to add 0x40 to the address I pass to block read and write functions.

Thanks.

[loathingKernel]

Yes, I have tried those commands. Similar commands to those are being used in my Makefile.

EEPROM and NewEEPROM libraries both use the avr/eeprom.h functions to access the EEPROM memory. Since you are using the AVR functions directly, you can just add the 0x40 offset and adjust your application logic. It is smarter to do that in the sketch and not the bootloader because of the more flash memory available to the sketch.

[d0ughb0y]

Regarding

I do not think it is a good idea to move the settings to the end because different MCUs have different sizes of EEPROM.

Can the bootloader source use these define values?

#define EEPROM_END       (EEPROM_START + EEPROM_SIZE - 1)
#define E2END        EEPROM_END

I compared your makefile command and the avrdude options I used, and notice I had

-U efuse:w:0xFF:m

instead of lfuse. Maybe that setting by accident caused it to work.

[loathingKernel]

If the proper header is included, yes.

[d0ughb0y]

I think maybe its my command line option not changing the lfuse caused it to work.
it may just be a matter of setting the proper fuse value to make usbasp work on mega.

as far as I can tell, your makefile fuse values for mega is the default fuse value.
My avrdude option did not set lfuse, and may be setting efuse to 0xFF instead of 0xFD.
This is the only difference, and perhaps is the setting that will allow usbasp to program the mega.

I will try to correct my avrdude option to set lfuse to 0xFF and efuse to 0xFD and see if it still burns the bootloader or not.

efuse 0xFD sets brownout detection voltage to 2.7v, while 0xFF means no brownout detection. I don't think this setting should have an effect on bootloader upload. I'll know when I test this later.

[loathingKernel]

This is slowly becoming a support thread, please contact me on my email to further the discussion.

I am closing this bug report now.

[d0ughb0y]

I tested on two mega boards, one clone and one original made in italy mega board. I am actually able to burn the bootloader via Arduino IDE on both despite the verify error at the end. All booloader functionality works as far as I can tell. I am able to burn the bootloader using avrdude command line. So if you only had limited testing, I don't think you can conclude that usbasp cannot be used on mega.

I'll probably just fork this project and enhance it, as I see a lot of things I would do differently. Good luck with your project.

[loathingKernel]

My guess is that your testing has been by far more limited than mine, given the amount of people that have contacted me with various support issues and questions, hence I concluded that it is not reliable. I do not know why you keep on insisting on this but I will keep a warning as long as I am not sure it works for everyone because that is the rational thing to do.