Could you ask for inclusion of this bootloader in official Boards Manager?

[q2dg]

This would give a lot more of visibility to your fantastic project and, moreover, it should make installation of avr_boot a lot easier...as only selecting the target "board" in the menu, the menu option "Burn bootloader" should do the rest.

See: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.5-3rd-party-Hardware-specification

Thanks

[zevero]

Very good idea! I would love to see this.

Are you willing to do it?
Do you have some background on how this is done?
Unfortunately the Boot Loader part seems not to be documented in your link and I would need to invest some time ...

[q2dg]

Oooh, sorry, I haven't such technical skills. But I know this other project https://github.com/NicoHood/HoodLoader2 which has achieved this (it's a custom bootloader designed to be loaded in UNO's Atmega16U2 to convert it into a Leonardo-like board). Its author is @NicoHood
Thanks a lot

[NicoHood]

An example can be found here:
https://github.com/NicoHood/HoodLoader2

@per1234 helped me with the packaging of the files:
NicoHood/HoodLoader2#21

You can ask him for help too i guess.

[per1234]

Unfortunately the Boot Loader part seems not to be documented in your link and I would need to invest some time ...

Actually this is the specification for adding Boards Manager support: https://github.com/arduino/Arduino/wiki/Arduino-IDE-1.6.x-package_index.json-format-specification

This may also provide some useful information on potential locations for the necessary files: http://playground.arduino.cc/Main/BoardsManagerSupport

I have helped add Boards Manager installation support to 8 projects now and am willing to provide assistance for this one also. The bootloader files and boards.txt for all boards that you want to support will need to be made and tested before doing the Boards Manager work.

[zevero]

Oh hi @per1234 you helped me here maniacbug/mighty-1284p#14

I don't really understand the process of adding boards. Adding a board would more be like for example adding 1284p support like in
https://github.com/JChristensen/mighty-1284p/tree/v1.6.3
(which would be nice).

Ok, now for Bootloaders I assume we need a seperate Board for every Bootloader? Or can we have multiple Bootloaders for a given board?

I have only limited knowledge of Arduino packaging ... if you coulld tell me what exactly you need, it would be easier for me.

I guess we will need a hex file for every board.
I assume we will not have any options, so we will compile without LED or UART, therefore we dont need to configure anything really (FAT12, FAT16 and FAT32 - support ist default).
We therefore only need to set

• MCU_TARGET: Your AtmegaXXX
• BOOT_ADR: in bytes not words!
• F_CPU: CPU Frequency

+FUSES

Keep in mind that we need 4k and after the bootloader is installed flashing via Serial does not work anymore. (We still have 500 bytes left so serial support should be quite feasible however...)

[per1234]

I don't really understand the process of adding boards. Adding a board would more be like for example adding 1284p support like in

It's just adding a new entry to the Tools > Board menu in the Arduino IDE. That could mean adding support for a new MCU as the Mighty 1284P project did. A different configuration of hardware already supported by the Arduino IDE. Or a different bootloader such as your project. I have even used it to add a new programmer to the Tools > Programmers menu. Boards Manager makes it easy for people to install hardware files to the Arduino IDE and keep them updated simply by adding a URL to File > Preferences > Additional Boards Manager URLs. Arduino IDE 1.6.6 has added a notification when a new version of any package installed with Boards Manager is available so the users will be able to immediately update with just a click.

Ok, now for Bootloaders I assume we need a seperate Board for every Bootloader? Or can we have multiple Bootloaders for a given board?

You can have multiple bootloader for each board but there are some limitations. Each selection in the Tools > Board menu can have other custom menus. So for example the Board entry could be ATmega328P and then there could be a custom menu for USE_LED: Yes, No. Then the selection will determine which bootloader is used. Unfortunately we can't also have a menu for USE_UART: Yes, No so you would either need an "ATmega328P" and an "ATmega328P Debug" Board menu entry or the custom menu could be Configuration: USE_LED + USE_UART, USE_LED, USE_UART, no LED + no UART. There can be a separate menu for clock speeds and if you do the trick with using the 16MHz bootloader for the 8MHz board but setting the baud rate to half then those can all be on a single Board menu entry. You can see an example of this in the alternative boards.txt file I wrote for the Mighty 1284P project: https://github.com/JChristensen/mighty-1284p/blob/v1.6.3/avr/boards.txt.alt It offers the choice of 20MHz, 16MHz Low Power, 16MHZ Full Swing, and 8MHz internal clock

So at a minimum we need a 16MHz bootloader file for each MCU that will be supported. If you want to have LED and UART options then there would need to be 4 bootloader files for each MCU to support all possible combinations of the 2 options. If you want to offer 20MHz clock option then that would require another bootloader(or 4) for each MCU. I'm willing to make the bootloaders but I may not be able to test all options so I might need help there.

Other than that you will need to decide:

• Location for the JSON file(this will be the URL that is added to Preferences to install avr_boot) - I'm partial to creating a gh-pages branch for it because that makes the URL short and keeps the file separate from the rest of the project.
• Location for the installation archive file. It makes sense to put this in the same location as the JSON file but that may require the installation archive file to be manually created for each release. Another option is to create a boards manager branch of the repo and then when you create release from that branch GitHub will automatically create the installation archive file. An example of this is https://github.com/SpenceKonde/ATTinyCore/tree/boardmanager. In that case you would create a standard release and a Boards Manager release for each version and clearly state the difference.
• Name of the JSON file. There is a specification:

package_YOURNAME_PACKAGENAME_index.json
The prefix package_ and the postfix _index.json are mandatory (otherwise the index file is not recognised by the IDE) while the choice of YOURNAME_PACKAGENAME is left to packager. We suggest to use a domain name owned by the packager for example:

So let me know if you have any questions. Once you have made the decision of how you want this implemented I'm happy to take over and submit pull requests or just provide assistance. I'm also willing to be in charge of adding new versions to the JSON file as they are released. Just let me know what you want me to do.

[zevero]

I think it is too complicated to provide options for LED (needs configuration of two pins) and UART (needs the divider for the baud rate).
For the latter it would be nice if I could autodetect the baud rate (and also have a serial bootloader as well). But for the time beeing I would not include any options as they are not really needed. (if someone needs to debug, he will be able to compile himself)

I pretty much would like to let you decide on all the other details. Avr_boot is not really "my work". I only adapted existing ideas to get my project up and running. I dont need credits and am happy already, if others can save some time.

So please fork and I am happy to pull all your requests. If you wish branches we can have branches.
Or you start your own rep from scratch. I really dont mind. The easier the better. Life is already complicated enough ;)

So just go ahead and use everything. If you want my help, tell me, what I should do.
I hope I can someday merge a serial bootloader in. So tell me how I would do that, after your work...
If I can see how everything works I could do it myself in the future, but for now it is better you take over.

[per1234]

I'd like to add support for:

• ATmega168
• ATmega328P
• ATmega32u4
• ATmega1284P
• ATmega2560

And clock options:

• 8MHz internal
• 16MHz Low Power
• 16MHz Full Swing
• 20 MHz Full Swing

Do you think the avr_boot will work for all of those without modification?

It sounds like you would like this functionality to be as low-maintenance as possible on your part so I think I will just put all the Boards Manager files in the gh-pages branch. That way you will only need to accept one pull request for each release.. So go ahead and create the gh-pages branch when you get a chance as I can't do that via pull request.

[zevero]

I know of no reason why it shouldn work.

Perfekt. gh-pages branch is set up!

[per1234]

I'm going to add instructions for installation and use with the Arduino IDE. Do you want me to add these to the README.md in the master branch or should I put it in the gh-pages branch?

[zevero]

What do you think about having the instructions on the gh-pages branch and I will add a prominent Link in top of my README.md ?
This would make it clear to the user that he can choose between compiling and flashing himself or installing via Arduino IDEs Board Manager.

[per1234]

I'm making the bootloader files and I ran into a couple of snags. The first is that the bootloader sizes are larger for me than you state in the documentation. Here's the avr-size output:

   text    data     bss     dec     hex filename
      0    4080       0    4080     ff0 atmega1284p_16mhz.hex
      0    4080       0    4080     ff0 atmega1284p_20mhz.hex
      0    4080       0    4080     ff0 atmega1284p_8mhz.hex
      0    4040       0    4040     fc8 atmega328p_16mhz.hex
      0    4040       0    4040     fc8 atmega328p_20mhz.hex
      0    4040       0    4040     fc8 atmega328p_8mhz.hex
      0    4108       0    4108    100c atmega32u4_16mhz.hex
      0    4108       0    4108    100c atmega32u4_20mhz.hex
      0    4108       0    4108    100c atmega32u4_8mhz.hex

So ATmega1284P and ATmega328P are still fine but the ATmega32U4 is too big to fit in the max section of 4096 bytes. I'm using make.exe from WinAVR-20100110 which is the most recent version I have found and everything else from the Arduino 1.6.6 installation. This is with USE_LED = 0 and USE_UART = 0. My makefile is here: https://github.com/per1234/avr_boot/blob/dev/Makefile I had to add some stuff to make it work with the Windows paths. So worst case scenario I just won't add ATmega32U4 but it's strange to me that the size is so different.

The second issue I'm running into is when I try to make the ATmega2560 bootloader files I get some errors:

rm -rf *.o avr_boot.elf *.eps *.bak *.a *.bin
rm -rf *.lst *.map
rm -rf avr_boot.hex
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega2560 -std=c99 -DBOOT_ADR=0x3F000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o main.o main.c
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega2560 -std=c99 -DBOOT_ADR=0x3F000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o diskio.o diskio.c
../../../../tools/avr/bin/avr-gcc -c -mmcu=atmega2560 -I. -x assembler-with-cpp-Wa,-adhlns=asmfunc.lst,-gstabs -DBOOT_ADR=0x3F000 -DF_CPU=16000000 -DUSE_LED=0-DUSE_UART=0 asmfunc.S -o asmfunc.o
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega2560 -std=c99 -DBOOT_ADR=0x3F000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0 -Wl,-Map,avr_boot.map -Wl,--gc-sections -Wl,--section-start,.text=0x3F000 -o avr_boot.elf main.o pff/src/pff.o diskio.o uart/uart.o asmfunc.o
c:/program files (x86)/arduino-nightly/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/bin/ld.exe: avr:51 architecture of input file `pff/src/pff.o' is incompatible with avr:6 output
c:/program files (x86)/arduino-nightly/hardware/tools/avr/bin/../lib/gcc/avr/4.8.1/../../../../avr/bin/ld.exe: avr:51 architecture of input file `uart/uart.o' is incompatible with avr:6 output
collect2.exe: error: ld returned 1 exit status
make: *** [avr_boot.elf] Error 1

Any ideas?

[NicoHood]

WinAVR is just OLD. Use a recent avr-gcc and the size will be probably a lot smaller.
With avr-gcc 5.1 and LTO you can get tons of bytes back.
https://github.com/NicoHood/HoodLoader2/wiki/Developer-Information

Edit: just downloaded the default master package and hit make without modifications. Got the following error:

avr_boot-master$ make
rm -rf *.o avr_boot.elf *.eps *.bak *.a *.bin
rm -rf *.lst *.map 
rm -rf avr_boot.hex
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega1284p  -std=c99 -DBOOT_ADR=0x1F000  -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1          -c -o main.o main.c
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega1284p  -std=c99 -DBOOT_ADR=0x1F000  -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1          -c -o pff/src/pff.o pff/src/pff.c
pff/src/pff.c: In function ‘get_fat’:
pff/src/pff.c:372:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   wc = LD_WORD(buf);
   ^
pff/src/pff.c:379:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   return LD_WORD(buf);
   ^
pff/src/pff.c:384:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   return LD_DWORD(buf) & 0x0FFFFFFF;
   ^
pff/src/pff.c: In function ‘pf_mount’:
pff/src/pff.c:775:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     bsect = LD_DWORD(&buf[8]); /* Partition offset in LBA */
     ^
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega1284p  -std=c99 -DBOOT_ADR=0x1F000  -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1          -c -o diskio.o diskio.c
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega1284p  -std=c99 -DBOOT_ADR=0x1F000  -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1          -c -o uart/uart.o uart/uart.c
avr-gcc -c -mmcu=atmega1284p  -I. -x assembler-with-cpp -Wa,-adhlns=asmfunc.lst,-gstabs -DBOOT_ADR=0x1F000   -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1        asmfunc.S -o asmfunc.o
avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega1284p  -std=c99 -DBOOT_ADR=0x1F000  -DF_CPU=16000000    -DUSE_LED=0         -DUSE_UART=1        -Wl,-Map,avr_boot.map -Wl,--gc-sections -Wl,--section-start,.text=0x1F000   -o avr_boot.elf main.o pff/src/pff.o diskio.o uart/uart.o asmfunc.o 
/usr/lib/gcc/avr/4.8.2/../../../avr/bin/ld: address 0x20062 of avr_boot.elf section `.text' is not within region `text'
/usr/lib/gcc/avr/4.8.2/../../../avr/bin/ld: address 0x20062 of avr_boot.elf section `.text' is not within region `text'
collect2: error: ld returned 1 exit status
make: *** [avr_boot.elf] Error 1

[per1234]

@NicoHood I'm only using make.exe from WinAVR. I installed avr-gcc 5.1.0 from that link and the sizes are the same as before and the same error on the ATmega2560 compile. I also tried using the make.exe from Arduino IDE 1.0.6 which I believe is the last one that came with that file and I get the same results on both issues.

[zevero]

I just compiled it as I am used to do it on linux debian (had to do sudo apt-get install avr-libc gcc-avr )
and atmega32u4 compiled with 3558 bytes without any problems.

I cloned your fork and I got the same error!

I saw that make clean is not deleting *.o in pff and uart dirs (wrong usage of rm -rf)

As I deleted them manually I get the same error as well. I will look into it this evening ...

[zevero]

ok - I don't know why we have issues compiling it... I made some changes

• deactivated FAT12 support (who has a 16Mb SD CARD anyway?
• deactivated allow lower case names
• only use pgm_read_byte_far for >64k

@NicoHood the error only indicates, that the build is too large
@per1234 Please try again. At least my build compiles now.

[per1234]

Ok, I have realized my attempt at a makefile is causing problems so I've gone back to as close to the original as will work with windows. All except the ATmega32U4 is working for me now with the new version of avr_boot. @zevero have you tried the making it for ATmega32U4?

MCU_TARGET  = atmega32u4
BOOT_ADR    = 0x7000

I get:

making avr_boot bootloader files...
rm -rf *.o avr_boot.elf *.eps *.bak *.a *.bin
rm -rf *.lst *.map
rm -rf avr_boot.hex
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega32u4 -std=c99 -DBOOT_ADR=0x7000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o main.o main.c
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega32u4 -std=c99 -DBOOT_ADR=0x7000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o pff/src/pff.o pff/src/pff.c
pff/src/pff.c: In function 'get_fat':
pff/src/pff.c:379:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   return LD_WORD(buf);
   ^
pff/src/pff.c:384:3: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
   return LD_DWORD(buf) & 0x0FFFFFFF;
   ^
pff/src/pff.c: In function 'pf_mount':
pff/src/pff.c:775:5: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
     bsect = LD_DWORD(&buf[8]); /* Partition offset in LBA */
     ^
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega32u4 -std=c99 -DBOOT_ADR=0x7000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o diskio.o diskio.c
../../../../tools/avr/bin/avr-gcc -gdwarf-2 -Wall -Os -mcall-prologues -ffunction-sections -fdata-sections -mmcu=atmega32u4 -std=c99 -DBOOT_ADR=0x7000 -DF_CPU=16000000 -DUSE_LED=0 -DUSE_UART=0   -c -o uart/uart.o uart/uart.c
uart/uart.c: In function 'UART_init':
uart/uart.c:8:17: error: 'UCSR0B' undeclared (first use in this function)
 #define  UCSRB  UCSR0B
                 ^
uart/uart.c:25:5: note: in expansion of macro 'UCSRB'
     UCSRB = (1 << TXEN0);
     ^
uart/uart.c:8:17: note: each undeclared identifier is reported only once for each function it appears in
 #define  UCSRB  UCSR0B
                 ^
uart/uart.c:25:5: note: in expansion of macro 'UCSRB'
     UCSRB = (1 << TXEN0);
     ^
uart/uart.c:25:19: error: 'TXEN0' undeclared (first use in this function)
     UCSRB = (1 << TXEN0);
                   ^
uart/uart.c:11:17: error: 'UBRR0L' undeclared (first use in this function)
 #define  UBRRL  UBRR0L
                 ^
uart/uart.c:26:5: note: in expansion of macro 'UBRRL'
     UBRRL = USE_UART; // SEE HERE: http://wormfood.net/avrbaudcalc.php
     ^
uart/uart.c: In function 'UART_put':
uart/uart.c:7:17: error: 'UCSR0A' undeclared (first use in this function)
 #define  UCSRA  UCSR0A
                 ^
uart/uart.c:31:14: note: in expansion of macro 'UCSRA'
     while (!(UCSRA & (1 << UDRE)));
              ^
uart/uart.c:12:16: error: 'UDRE0' undeclared (first use in this function)
 #define  UDRE  UDRE0
                ^
uart/uart.c:31:28: note: in expansion of macro 'UDRE'
     while (!(UCSRA & (1 << UDRE)));
                            ^
uart/uart.c:13:15: error: 'UDR0' undeclared (first use in this function)
 #define  UDR  UDR0
               ^
uart/uart.c:32:5: note: in expansion of macro 'UDR'
     UDR = c;
     ^
make: *** [uart/uart.o] Error 1

Sizes are now:
326P:

• w/avr-gcc 4.8.1: 3630
• w/ avr-gcc 5.1.0: 3658

1284p:

• w/ 4.8.1: 3680
• w/ 5.1.0: 3706

2560:

• w/ 4.8.1: 3802
• w/ 5.1.0: 3824

That's right they are all larger with the newer version of avr-gcc

[zevero]

As a quickfix, you can just comment out uart.c in Makefile line 12.

On atmega32u4 Serial is on 1 instead of 0 in uart.c from line 7 to 17
But I can not do #if MCE_TARGET=atmega32u4

But maybe you know some switch, that I can just can leave out uart.c in Makefile line 12 if USE_UART = 0 ?
I tried earlier to reduce filesize. I did not know how I can do conditions in Makefile, but I found that with --gc,sections unneeded bytes are reclaimed.

[per1234]

If I do:

ifeq ($(MCU_TARGET), atmega32u4)
CSRC        = main.c pff/src/pff.c diskio.c
else
CSRC        = main.c pff/src/pff.c diskio.c uart/uart.c #uart/uart.c is taken out by --gc,sections is USE_UART = 0
endif

It works but for some reason if I do:

ifeq ($(USE_UART), 0)
CSRC        = main.c pff/src/pff.c diskio.c #uart/uart.c is taken out by --gc,sections is USE_UART = 0
else
CSRC        = main.c pff/src/pff.c diskio.c uart/uart.c #uart/uart.c is taken out by --gc,sections is USE_UART = 0
endif

It doesn't work. Do you think the first one is a good solution to the issue?

[zevero]

it works without the # Comment
or we can do

ifeq ($(strip $(USE_UART)),0)

I pushed a new commit

[per1234]

Does asmfunc.S have to be modified for each different MCU? It looks like it's only set up for ATmega1284P right now.

[zevero]

oh you are right!
Well its not so difficult to find the port numbers, but how are we going to do

#if MCU_TARGET == 'atmega1284p'

it does not work with strings... do you have an idea? Can we use some standard ATMEGA_1284p ?

Else I would convert the MCU_TARGET to a number and we need to use the number in the Makefile?

[per1234]

You can do:

#if defineddefined(__AVR_ATmega2560__) || defined(__AVR_ATmega1280__)
//set up ports for ATmega2560
#elif defined(__AVR_ATmega1284__) || defined(__AVR_ATmega1284P__) || defined(__AVR_ATmega644__)  || defined(__AVR_ATmega644A__) || defined(__AVR_ATmega644P__)  || defined(__AVR_ATmega644PA__)
//set up ports
#elif defined(__AVR_ATmega32U4__)
//set up ports
#elif defined(__AVR_ATmega328__) || defined(__AVR_ATmega328P__)
//set up ports
#else
#error avr_boot has not been configured for your processor. You must modify asmfunc.S.
#endif

[zevero]

Thanks!
... the new commit has the pins configured in asmfunc.S

[per1234]

Progress report: I've added support for using the SD on the Ethernet Shield and Arduino Ethernet(which uses pin 4 for CS instead of SS as on the SD Shield). Pin 4 is different depending on which ATmega1284P board is being used which I have also accounted for. I just need to test a bunch of different board configurations now and then I'll submit the pull request for that change to master and the pull request for Boards Manager support also.

[per1234]

Everything is working well for me except for ATmega2560. @zevero if you have one would you please try it out and see if it works for you? My boards.txt file, etc. is here: https://github.com/per1234/avr_boot/tree/boards-manager-install.

The CS pin situation with the SD shields is really a mess:
Ethernet Shield and Arduino Ethernet: Pin 4
Seeed SD card shield: Pin 4
Adafruit Data Logger Shield: Pin 10
Sparkfun MicroSD Shield: Pin 8
Of course some people are going to be using a module so they can wire it up as they like and if they aren't already using it for something else the SS pin makes the most sense but on the Leonardo/Micro the SS pin isn't even broken out and I doubt any shields use pin 53 on the Mega. Right now I have it set up so they only have the choice between SS and pin 4. On the Leonardo/Micro that means the only option is pin 4. For the widest compatibility range I guess I need to give the option of all 3 or 4 possible pins.

I'm wondering if using a pin other than SS for SD CS will cause reliability problems. Does SS still need to be set in the bootloader code so the MCU won't go into slave mode? I haven't had any problems in my testing. What do you think?

[zevero]

I am impressed and looking forward to pull!

I happen to have a MEGA2560 board and I can test it ... what doesnt work for you?

Unfortunately I do not have answers to the other questions. I have only experience with Atmega328p, Atmega644 and Atmega1284p. And I always used standard pins for sd cards.

[per1234]

With the ATmega2560 the bootloader compiles fine. Burn Bootloader is successful. But the code from the SD card never runs. I haven't been able to make USE_UART or USE_LED work properly with ATmega328P which works fine without those options enabled. When I enable either of those options AVR_BOOT is shown in the serial monitor or the LEDs blink but the file on the SD card is never uploaded so they aren't providing me any useful diagnostics as to why the ATmega2560 isn't working. I think bootloaders have to handle ATmega2560 differently because of the larger memory size.

[per1234]

I should add that I am using your makefile with only the optiboot build environment code added, SD CS connected to SS, and your current asmfunc.S when troubleshooting to eliminate as many possible complications as I can.

[zevero]

hm ... debug options are not working on Atmega328p? Atmega2560 has 256 kbytes and Atmega1284p 128kB there should not be any difference ... (only when passing 64kBytes we need to take the far pgm_space variants)
I will have to check that out, but I am quite busy this week. I may only do it next weekend ... Sorry

[per1234]

I managed to get the ATmega2560 to load a program from the SD card but it's far from ideal. I discovered the program will run under these circumstances:

• Set high fuse to DB instead of DA to disable the Boot Reset vector(BOOTRST=1).
  • The standard Arduino boards.txt enables the Boot Reset vector(BOOTRST=0) as does your hfuse setting in README.md.
• Use Atmel AVRISP mkII to Burn Bootloader instead of USPasp.
  • I normally use my USBasp due to the mkII not working correctly for Burn Bootloader with current versions of Arduino IDE for me without some ugly workarounds.
• Press the reset button after powering the board with the SD card attached.
  • The program has been loaded into the MCU flash but doesn't run until the reset button is pressed. With the other boards the program begins to run immediately after it has been loaded from the SD card.

After the program has been loaded from the SD no other programs will load from the SD card until the bootloader is burned again. If I change any of the above conditions it doesn't work. With all of these conditions it works consistently. I have no idea what this means, it's a bit more advanced than my current skill level. Worst case scenario I can just not add support for ATmega2560 as all the other MCUs work fine in all my tests without having to jump through any of these hoops.

[zevero]

I think, its better to postpone support for ATmega2560. Momentarily my schedules are too tight for me to contribute. Perhaps later or maybe somebody will help us.

[per1234]

Ok, understood. @q2dg can you test avr_boot with ATmega2560 and see if it works for you?

[q2dg]

Oooh, sorry! I haven't any board of this kind :-/

[per1234]

I'll go ahead with just the other 3 MCUs then.

[q2dg]

Thumbs up!

[per1234]

I noticed that F_CPU is only used for the dly_100us function so I tested all supported configurations with F_CPU=20000000 with no problems. This will cause the delay to be longer than expected for clock speeds less than 20MHz(especially 8MHz) but even with a 64KB program at 8MHz I don't find a measurable difference in the time it takes for the program to load from the SD card. Using a single F_CPU setting for all boards will make the avr_boot section of the Board menu much smaller which is a real advantage for people who have lots of 3rd party boards installed as well as making the boards.txt file simpler and therefor less prone to errors. So unless anyone has a compelling reason not to do this I will use F_CPU=20000000 for all clock speeds of the avr_boot boards installed via Boards Manager.

[zevero]

What a coincidence! Today I wondered, that my 16 Mhz Bootloader works with an 8Mhz Board without issues ;)
So you think it is save to remove F_CPU ?
I dont need it for DEBUG_SERIAL, since I use the dividor diretly...

[per1234]

Well I don't understand fully the inner working of this bootloader but F_CPU is used only in this line of asmfunc.S:
ldi r24, lo8(F_CPU / 100000) /* Loop counter */
So if F_CPU is set to 8000000 then that value will be 80, if F_CPU is 20000000 then the value will be 200 so the idea I think is to use a different number of loops depending on the clock speed to achieve a 100us delay. So if F_CPU is set to 20000000 and the clock speed is 8MHz then the delay will be 250us instead of 100us. Now I don't know how important the length of the delay is. My theory is that it just needs to be a minimum of 100us and 250us will also work fine but will slow down the data transfer from the SD card. So I think it's reasonable to leave it in for the people who want to make their own custom hex file but unless it will increase reliability to make a separate hex file for each clock speed for the Boards Manager install I think it's better to just use 20000000 for all of them even if the data transfer will be slightly slower. My tests show no problems but that's all i have to go on. If there was more advanced logic available in boards.txt then it wouldn't be a problem but as is I will have to make a separate Board menu entry for each MCU x each clock speed so it increases the number of entries from 3(4 with ATmega2560) to 8(11 with ATmega2560). This would probably force me to drop some of the less likely to be used clock settings to reduce the number of entries.

[zevero]

ok. I add a comment in makefile! Thanks for your hint! It makes my situation easier as well!

[per1234]

@zevero everything is finished and ready for me to submit the pull request except I need to know what the version number should be. There have been some significant changes since v1.0. Boards Manager uses the semver versioning specification.

[zevero]

I released avr_boot to be v1.1.0 just now. Is that ok for you?

[per1234]

Thanks, my PR is coming soon.

[per1234]

@zevero should I move the information on adding ATmega2560 support to a new issue and then we can close this issue? Maybe you could add a "help wanted" tag to it and hopefully some bootloader wizard will come along to figure it out.

@q2dg the Boards Manager URL for avr_boot is: https://zevero.github.io/avr_boot/package_zevero_avr_boot_index.json please let me know if you find any problems or have any suggestions. If you find others who need help with adding Boards Manager support to their projects feel free to give me a mention and I'll see what I can do.

[per1234]

@q2dg I forgot to mention if you're using Arduino IDE 1.6.6 then you may need to open Boards Manager twice after adding the Boards Manager URL before the avr_boot entry will show because of this issue: arduino/Arduino#3795.

[zevero]

Updated Readme with a link to Boards Manager installation instructions.

I thank you so much for all the time and effort that you put into my little project!

[per1234]

You're welcome. I hope it is slightly improved and more accessible as a result. If you want me to continue to update the installation files on each release I'm happy to do so.

[zevero]

Yes please. It is a pleasure working with you!

[per1234]

Ok will do. I'm following this repository so I should be automatically notified of any new release but feel free to give me a mention here if I miss one.

[q2dg]

@per1234 It's perfect!! Thanks a lot!!!

Only a silly thing: in Readme instructions it is said: "...and then reopen it before the Ariadne Bootloader entry will appear." Copy/paste is the new evil :-)

[per1234]

Glad to hear and thanks for spotting the typo. I'll fix that.