Add support for Standard Serial Programming

[SergeantSeven]

Currently not supported. I'm hoping to add this functionality myself here soon. Any Help is welcome. I'm going to Look at the Optiboot code and see what I can scavenge out of it to fill the gap. any issues I might want to know about before digging in? Will start a new fork soon and submit a pull request when i know it works. Thanks.

[SergeantSeven]

Ok, I think i may have bitten off more then i can chew here. I'm not sure where to start. Here is my outline to get things rolling; (any suggestions are appreciated)

• Locate code in Optiboot source codes that can be ported over. (not sure where to look on the git)
• Locate sections of avr_boot source codes where Optiboot serial loading can occur.
• Need to figure out how to do this: First wait for Serial host to transmit. (default optiboot wait time or speed it up? whats the standard approach?) if no host programmer is ready to transmit then look in SD and continue as planned.
• Need to make sure that if and when the serial host is connected and new binaries are saved to flash, that the boot loader skips the SD check and just runs the code. We don't want a firmware.bin in the SD to be loaded over what we just manually flashed via serial. in case the user forgets its there.

After I figure how to implement these things I can start porting things over and testing. another concern is cross platform compatibility. I need to verify if the 1284p can be loaded the same as the 328p and others on the same boot loader. I personally use the 1284p with the maniac bug port of optiboot so the first thing i wanna do is look there for code. but if we load the same boot loader on several devices and make sure it still loads from serial and the SD as planned, will the boot loader be too big? should i maybe look for another route?

[per1234]

I don't know much about how to do this but am willing to help with testing and documentation. About ATmega1284P serial upload support: Optiboot already supports ATmega1284P as is. See: https://github.com/Optiboot/optiboot/blob/master/optiboot/bootloaders/optiboot/Makefile.1284 I don't know if you're referring to the original maniacbug Mighty 1284P repository(way out of date) or the JChristensen fork but I know that the bootloader source of the JChristensen fork is not the actual source that was used to make the current bootloader files. So I don't think anything in Mighty 1284P will be useful to your project. Instead just use the Optiboot source as a reference. Of course then ATmega2560 support may be another issue as it doesn't look like Optiboot currently supports this(I seem to remember that one of the Optiboot forks has added support) but avr_boot SD upload on ATmega2560 doesn't work right either so maybe that isn't a concern.

[per1234]

Also you might find this source: https://github.com/thseiler/embedded/tree/master/avr/2boots a useful reference as it already fits SD and serial uploads in 2KB. If nothing else it's proof that this is possible.

[SergeantSeven]

I wasn't aware of the optiboot support for 1284, I'll have to do some more research in to that. does IDE 1.5.x still require the JChristensen"maniacbug" core files to support the 1284? that's what I'm using right now. At any rate, I will look at the source files for 2boots and see if i can pull anything useful. last i heard they were having issues with SD loading which is why i chose to start using AVR_boot, which works great. I'm even working on a way to export .BIN files directly from Arduino. but that's a project for a different day.

[per1234]

Arduino IDE 1.5+ doesn't support ATmega1284P out of the box but now the only things that need to be added are the bootloader file and the pins_arduino.h as opposed to the original maniacbug Mighty 1284P core which also needed to add patched core libs. The Optiboot boards.txt even uses the arduino:standard variant for ATmega1284P but after looking at that file I don't understand how it could work.

[SergeantSeven]

I'll have to look at the current code to see if maybe I can implement out of the box support. That would be wonderful. However if i remember correctly there were a couple built in libraries that they had to patch for it to work. I know that they added a couple of libraries that have "(1284 supported)" suffix added to the name. not sure what the issue is but they still have them as open in the repository.
I have started a new topic in the Arduino Forums looking for help in isolating the STK500 protocol and serial communication code from Optiboot, (Optiboot emulates the STK500 to flash the binary). Hopefully it proves helpful to have another eye on it.
http://forum.arduino.cc/index.php?topic=361041.0

[per1234]

Yes that's correct, some libraries have to be patched to support ATmega1284P. The Ethernet library needed the W5100 CS pin defined, Firmata sets some board specific defines, SD defines the SPI pins, GSM defines the software serial pins. I don't know what the patch is on Servo because that one still compiled when I updated Mighty 1284P to support Arduino 1.5+ so I just kept the previous patched version of that library.

[SergeantSeven]

I wonder if that's something that can be easily merged with the current master for 1.5+ I may fork my own arduino and implement some of the changes, Thats another project for another time though. Thanks for your suggestions. I was able to add the needed STK500 protocol support files from 2boots but I'm still not sure where in avr_boot to implement the code. is it in main.c?

[SergeantSeven]

I've added some code and borrowed some stuff from 2boots in the hopes that i know what the heck I'm doing, I don't. Anyone wanna try and compile this and see if there are any errors? I added a variable to stk500v1.c that is either 0 if the UART loading is successful or 1 if it fails. in main.c the stk500v1 function sits before checkFile, check file is wrapped in an if statement that checks to see if stkFail is true. I haven't tested any of this yet as I don't have access to the right tools right at this moment.

https://github.com/SargentSeven/avr_boot

[per1234]

main.c: In function 'main':
main.c:221:7: error: 'stkFail' undeclared (first use in this function)
   if (stkFail = 1){

[SergeantSeven]

looks like I'm on track to cargo cult engineering this. How would I pass that variable through to main.c from stk500v1.c ?

EDIT: nevermind, I've got it. I'll fix that in a second. I'm a n00b.

Added the missing extern bool stkFail to stk500v1.h should clear that error.

[SergeantSeven]

Thanks for the pull requests per. I have merged those changes in to my master. I had read through online and found online the C did have built in bool. that's why i had used it. Apparently as of C99 standard bool is actually represented as _Bool and stdbool.h just translates bool to this standard as well as the macros true and false (to 1 or 0 respectively) so either way works. would using '_Bool' rather then loading the macros for 'bool' have any space benefits?
(assuming this is using the ISO C99 standard or newer.)

[per1234]

Sure, I'm just trying to work through the compile errors but am not 100% sure what I'm doing. Feel free to squash any of these eventually if you want to clean up the commit history. I don't know about the bool thing. I've always used C++ so I was surprised when using bool caused the compile error. I just got the information from: http://stackoverflow.com/questions/1921539/using-boolean-values-in-c

So now the compile error is:

stk500v1.o: In function `stk500v1':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:432: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:432: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:432: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:432: undefined reference to `pagebuffer'
stk500v1.o: In function `handle_programmerVER':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:287: undefined reference to `pagebuffer'
stk500v1.o:C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloade
rs\avr_boot-master/stk500v1.c:297: more undefined references to `pagebuffer' fol
low
stk500v1.o: In function `handle_addr':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:297: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:297: undefined reference to `address'
stk500v1.o: In function `handle_spi':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:301: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:302: undefined reference to `pagebuffer'
stk500v1.o: In function `handle_write':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:326: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:326: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:327: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:327: undefined reference to `pagebuffer'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:333: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:333: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:333: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:333: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:336: undefined reference to `write_flash_page'
stk500v1.o: In function `handle_read':
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:346: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:346: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:358: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:358: undefined reference to `address'
C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloaders\avr_boot
-master/stk500v1.c:360: undefined reference to `address'
stk500v1.o:C:\Program Files (x86)\arduino-nightly\hardware\arduino\avr\bootloade
rs\avr_boot-master/stk500v1.c:360: more undefined references to `address' follow

I'll check back tomorrow to see if you've made any progress and try compiling again.

[SergeantSeven]

Those are all calls to functions in the prog_flash.c file. I think it just needs to be included. I may have forgot to add it to the list. I'm doing this all from my tablet while waiting on family away from home. thanks for putting up with me. I'm just muddling through this myself at the moment. FWIW I think the prog_flash and boards files may need some code cleanup to remove any unneeded code from 2boots. but I'm not sure on exactly whats connected to what. guess we just keep fixing compile errors until it works then break it again.

[per1234]

I just tried it with prog_flash.c added to CSRC in Makefile and it compiled.

[SergeantSeven]

I added the necessary changes to my master. Try it with the _Bool instead of the bool macro, I'm not sure what C standard is being used. but I assume it will compile just fine.

[per1234]

_Bool works

[per1234]

ATmega328P compiles to 4434 bytes, larger than the max bootloader section size. Compiling for ATmega1284P gives the following errors:

stk500v1.c: In function 'setup_uart':
stk500v1.c:152:2: error: 'UBRRL' undeclared (first use in this function)
  UBRRL = (uint8_t)(F_CPU/(BAUD_RATE*16L)-1);
  ^
stk500v1.c:152:2: note: each undeclared identifier is reported only once for eac
h function it appears in
stk500v1.c:153:2: error: 'UBRRH' undeclared (first use in this function)
  UBRRH = (F_CPU/(BAUD_RATE*16L)-1) >> 8;
  ^
stk500v1.c:154:2: error: 'UCSRA' undeclared (first use in this function)
  UCSRA = 0x00;
  ^
stk500v1.c:155:2: error: 'UCSRC' undeclared (first use in this function)
  UCSRC = 0x06;
  ^
stk500v1.c:156:2: error: 'UCSRB' undeclared (first use in this function)
  UCSRB = _BV(TXEN)|_BV(RXEN);
  ^
In file included from c:\program files (x86)\arduino-nightly\hardware\tools\avr\
avr\include\avr\io.h:99:0,
                 from stk500v1.c:41:
stk500v1.c:156:14: error: 'TXEN' undeclared (first use in this function)
  UCSRB = _BV(TXEN)|_BV(RXEN);
              ^
stk500v1.c:156:24: error: 'RXEN' undeclared (first use in this function)
  UCSRB = _BV(TXEN)|_BV(RXEN);
                        ^
stk500v1.c: In function 'putch':
stk500v1.c:188:11: error: 'UCSRA' undeclared (first use in this function)
  while (!(UCSRA & _BV(UDRE)));
           ^
In file included from c:\program files (x86)\arduino-nightly\hardware\tools\avr\
avr\include\avr\io.h:99:0,
                 from stk500v1.c:41:
stk500v1.c:188:23: error: 'UDRE' undeclared (first use in this function)
  while (!(UCSRA & _BV(UDRE)));
                       ^
stk500v1.c:189:2: error: 'UDR' undeclared (first use in this function)
  UDR = ch;
  ^
stk500v1.c: In function 'getch':
stk500v1.c:253:10: error: 'UCSRA' undeclared (first use in this function)
  while(!(UCSRA & _BV(RXC))){
          ^
In file included from c:\program files (x86)\arduino-nightly\hardware\tools\avr\
avr\include\avr\io.h:99:0,
                 from stk500v1.c:41:
stk500v1.c:253:22: error: 'RXC' undeclared (first use in this function)
  while(!(UCSRA & _BV(RXC))){
                      ^
stk500v1.c:261:9: error: 'UDR' undeclared (first use in this function)
  return UDR;
         ^
stk500v1.c: In function 'handle_addr':
stk500v1.c:296:3: warning: dereferencing type-punned pointer will break strict-a
liasing rules [-Wstrict-aliasing]
   address = *((uint16_t*) &pagebuffer[0]);
   ^
stk500v1.c: In function 'getch':
stk500v1.c:263:1: warning: control reaches end of non-void function [-Wreturn-ty
pe]
 }
 ^
make: *** [stk500v1.o] Error 1

[SergeantSeven]

It appears (as i had noticed previously) there is no definitions for 1284p in 2boots code, I'll have to dig up the datasheets and add it in. as for the size, its close enough, if we trim all the unused code out of the files i borrowed we should be just within the max boot size. we are getting closer.

[per1234]

Also my compile sizes for avr_boot were larger than zevero's so maybe a different build system will also make it smaller. I'm using the tools included with Arduino 1.6.6 and make from WinAVR.

[zevero]

Thank you for your efforts!

• definitions are quite a mess in stk500. Maybe you can use the code for Debug_uart. Using just the divider
• instead of messing around with _Bool just dont let stk500v1() return if successful or let it return a bool instead of void
• size is quite limited... we may need some assembler code...

[zevero]

At least you will find the definitions for Atmega1284p which I was primarily using

[SergeantSeven]

I agree, the stk500v1 file could use some optimization and clean up. instead of doing something twice we can reuse your definitions for UART debugging. I'll start looking at how to do that. that should reduce a bit of space. as for returning a bool instead of void, thats probably the best way to do it, i may want to implement wiping any FIRMWARE.BIN files from the SD after a successful UART flash. not sure if after optimizations we will have enough headroom to work this in. One step at a time i guess. This is a steep learning curve for me. thanks for the suggestions!

[zevero]

The Bootloader, hence our code runs in the last 4kif the Rom. If flash was successful we tell the CPU to start at 0 with this code ((void(*)(void))0)();
So no need to delete Firmware.bin or to return any bool. Just throw in the above code if serial flash was successful.

[zevero]

I am sure stk500 will jump to 0 anyway starting the code it has flashed ;)

[zevero]

I was looking for the bootloader shipping with arduino. Is it stk500v2?https://github.com/arduino/Arduino/blob/master/hardware/arduino/avr/bootloaders/stk500v2/stk500boot.c
It seems to have nicer definitions and more assembler code.
It seems to run in 19200 baud.

[SergeantSeven]

It looks like stk500 from 2 boot doesn't start the code itself. I've added it the end of the function after it sends the quit commands to avrdude.
I think the CPU definitions is a bit over my head if you wouldn't mind helping me a little further with that and getting the code chopped down.
STK500v1 should still work. Yes it is now shipped with v2 but i think stk500v1.c has a define for minimalist commands. should be backwards compatible, not sure if there are any implications to using it.

[SergeantSeven]

Also, does AVR_BOOT not have watchdog timers?

[zevero]

? No just a rather useless 5s loop. It just jumps to 0 if the first byte is
not 0x00
Am 23.11.2015 06:30 schrieb "Nick Tracy" [email protected]:

Also, does AVR_BOOT not have watchdog timers?

—
Reply to this email directly or view it on GitHub
#6 (comment).

[SergeantSeven]

Looks like STK500v2 is only for the mega2560, which is why we can not support it here. they use two different bootloaders. stk500v1 optiboot for uno and others. then the STK500v2 bootloader for the mega2560.
Reason i asked about watch dog timers is that it is heavily used in most of the UART loaders.

[SergeantSeven]

Ok, i've tried but i think its a little above my abilities and I'm not getting much help anywhere else. I was able to get things to compile without error but I have no idea where to start on the board definitions for the UART. I'm sure once we clean that all up and merge it in to AVR_Boots Debug_Uart we can squeeze the total package in to the 328p. Also need to add the definitions for the 1284 in there to get that working, then we should be golden. I can try to help in any way i can. I have the whole 4 day weekend off from my day job.

[SergeantSeven]

Took some time to look at the code a bit harder. I removed the old UART baud settings and definitions from stk500v1.c and commented out the parts of the code that used the UART functions that were there. I made a backup of the file and added .old as the extension for reference. I think what we need is to add receive routines to uart/uart.c and then use those in place of the stk500v1.c functions such as getch(); and putch(); should be easy for someone to look at the old functions and determine what in uart.c we can make use of or if we need to write new routines. i wasn't sure what those routines were doing exactly. also, the receive pins on all board need to be pulled high to prevent noise from preventing the boot loader from timing out. so we will need to define that for each chip i guess. to reduce code I think we can optimize stk500v1.c by removing some version checking and response commands that aren't fully needed. kind of like a bare minimum stk500v1 protocol.

[la3pna]

Did you get this (serial upload) sorted out?

[zevero]

I am sorry no.
But if you have an ISP - Programmer it is really no effort to simply change the bootloader to the standard one.

[JadinAndrews]

Just a suggestion, I'm considering using this bootloader to deliver updates to micros running remotely, and for that purpose, there really is no need for a file system on the SD card at all. We could just write directly to the sectors, and get the code size down considerably. Possibly enough to get Serial back in comfortably?

[zevero]

Interesting idea ... and indeed much simpler .... but I prefer to be able
to share the SD with other devices.

2016-07-27 10:50 GMT+02:00 Jadin Roste Andrews [email protected]:

Just a suggestion, I'm considering using this bootloader to deliver
updates to micros running remotely, and for that purpose, there really is
no need for a file system on the SD card at all. We could just write
directly to the sectors, and get the code size down considerably. Possibly
enough to get Serial back in comfortably?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#6 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACIXHGlBYb7eL1Pt1MMLgKFzCvUMIbxFks5qZxvngaJpZM4GmNJN
.

[JadinAndrews]

I just managed to get optiboot compiled in with avr_boot at 3720 bytes, I used the compiler optimisations from 2boots, and disabled uart and led. Also, I disabled FAT32 in pff.conf. I think these are acceptable tradeoffs considering how nice it would be to have normal serial again. I still need to add some logic to main.c to get it working properly. For now, I just dropped the stk500 serial function before the checkfile function in main.c, which probably breaks mmc flashing, but it's a start.

[JadinAndrews]

Ok, so I got stk500 in there, as mentioned earlier, I just got it to compile. Today I tested it, and I couldn't get serial to work, the tx/rx leds flashed briefly when I tried to load a sketch from the Arduino IDE. So after spending a bit of time trying to make sure I had all the defines and includes right for the stk500 stuff, and trying different things. I eventually realised it was a baud-rate mismatch error. I looked through the stk500 source and saw it was set to 57600 for a 328p, so instead of recompiling and burning a new boot-loader, I just edited the boards.txt and set the upload rate to 57600, and VOILA! Serial worked after that!

But, for some reason the mmc flashing is now not working. I think I'm getting pretty close though. I will look at this again when I get more time in the week. The micro hangs after a watch dog reset, even though it's disabled first thing in the boot-loader, so it never gets to the checkfile call. Serial uploads fine, and the program starts fine after a hard reset, there's just some funny business going on that doesn't give the mmc code a chance to execute.

I'm thinking, maybe serial should be disabled after a watch dog reset, and just the mmc stuff should run?

[per1234]

@JadinAndrews any news on this? If fitting it in 4kB is giving you trouble I think it would still be useful to have the option(enabled via preprocessor conditionals) available for the boards with 8kB boot size.

[alexsartin]

Any success on this? If not I think I can help optimizing the code to add serial and fit on 4kB. I just don't have experience compiling the bootloader itself.

[per1234]

@alexsartin I can't give an update because I haven't heard anything since my last comment but you can look at the work @JadinAndrews did here:
https://github.com/JadinAndrews/avr_boot/commits/master
or even @SergeantSeven:
https://github.com/SergeantSeven/avr_boot/commits/master
As you can see, there has been no new activity in those repositories.

I just don't have experience compiling the bootloader itself.

Do you need instructions for how to compile? If so, which OS are you using?

As I said before, I think just getting serial programming working at all would be a huge step forward, even if it requires a larger boot section. This option can be turned on or off in the makefile so it will have no effect on people who don't need it and I can add a custom Tools menu option in the Arduino IDE for people using it that way. Once it's actually working it would be great to optimize it down to fit in the smaller boot section. I'm sure any help you can provide to reaching these goals would be much appreciated by everyone.

[JadinAndrews]

@per1234 Sorry it's been a while since I worked on this, I got busy with studies and work. As per my previous comment, I got everything compiled in at 3720 bytes, but it wasn't working properly. I actually have some free time for the next month or so, so I'll put in some time to see if I can get it working, I'm certain I can get serial working alongside mmc flashing.
I did get serial to work, but I also broke the mmc flashing, so if I recall, I just need to add some logic to choose between mmc, or serial flashing at boot.

By the way, we don't need 8kb, I don't think that is necessary.

[per1234]

Great! I know how it goes. I have more plans for the Arduino IDE support aspects of avr_boot on my "to do" list but it's taking me a while to get the free time for it.

[JadinAndrews]

Tell me about it, I can't believe it has been 8 months since my last comment. I have a renewed vigor to get this working, maybe then we can work on trimming it to 2kb MMC + Serial.. That's the holy grail.

[alexsartin]

Do you need instructions for how to compile? If so, which OS are you using?

Yes @per1234 , I would most appreciate instructions on Makefile, compiling and programming fuse bits. I'm currently using the latest Mac OS (Sierra).

Once I have those things figured out I will be able to start testing on Arduino Uno.

Have you guys tried out 2boots from Thseiler? He claims to produced a 2kB bootloader with serial and FAT16 sd card reading. I haven't the chance to test it yet, but as far as I know, people are having problems on the FAT16 library to recognize the SD card.

[per1234]

Unfortunately I can't provide Mac OS specific instructions because I'm using Windows so hopefully someone else can help with that. Here's a general overview:

To compile avr_boot you need to have AVR-GCC and make installed.

AVR-GCC is included with the Arduino IDE at hardware/tools/avr/bin. You could also install a newer version if you wanted and use that instead. It would be nice if we could set a standard version to use for development and releases to make sure we're all on the same page. Maybe the version included with the current release of the Arduino IDE at the time? The last time I compiled all the bootloader files to use for Arduino IDE support I used AVR-GCC 6.1.0, I think that was the newest version available at that time.

Make is not included with recent versions of the Arduino IDE. If you don't have it installed you can download it or get it from an old version of the Arduino IDE (~1.0.6).

You need to be able to run those applications from the avr_boot folder. On Windows I do this by adding the folders containing the AVR-GCC executables and make to my path, I don't know what the equivalent is on Mac.

You need to configure the build for your target. You can do that by editing lines 6-13 of Makefile. After that you just need to run the command make from the folder containing Makefile.

Editing Makefile all the time can be inconvenient, especially if you are building for many targets so it is also possible to set the configuration parameters via command line options, which will override the options set in Makefile. For example:

make MCU_TARGET=atmega328p BOOT_ADR=0x7000 F_CPU=16000000 SD_CS_PORT=PORTD SD_CS_DDR=DDRD SD_CS_BIT=4 USE_LED=0 USE_UART=0 ADDED_CFLAGS="-Wextra -Wno-strict-aliasing" TARGET=$(MCU_TARGET)_cs4_$(F_CPU)L

Will build for ATmega328P at 16 MHz with the SD CS pin set to PD4 (Arduino pin 4) with debug output off and output a file named atmega328p_cs4_16000000L.hex.

As for programming fuse bits and flashing the bootloader to your microcontroller, that will require AVRDUDE, which is included with the Arduino IDE at hardware/tools/avr/bin/avrdude.exe or can be downloaded from http://download.savannah.gnu.org/releases/avrdude/. The exact command required will depend on the target and programmer. If you're using the Arduino IDE you can very easily determine the correct command format:

1. File > Preferences > Show verbose output during: > upload
2. Tools > Burn Bootloader
3. Examine the contents of the black console window at the bottom of the Arduino IDE window. You will find two different AVRDUDE commands. The first sets the fuses, the second flashes the bootloader. You can copy and modify those commands according to your needs. For determining fuse settings I like to use: http://eleccelerator.com/fusecalc/fusecalc.php or you can just refer to the datasheet for your MCU.

I haven't tried any of the other SD bootloader options. To be honest I've never used avr_boot in a project, though I have used it extensively in testing my contributions, but I do believe that it's valuable to have this option available to the community. I think the big advantages of avr_boot are:

• Run by a project maintainer, Zevero, who is responsive to contributions and bug reports. The other ones have had a very abandoned feel to them, though I see there has been new activity on 2boots in the last day after years of none.
• The most friendly to "plug and play" use by the average Arduino user. You can download and install avr_boot via the Arduino IDE, choose from any common (and many uncommon) boards configurations supported by the bootloader code, burn the bootloader, and you're done. No compiling or writing custom hardware definitions is required.

If we could also provide the same level of features and efficiency as the other options that would be ideal.

[JadinAndrews]

Interesting point about using a standard version of avr-gcc, I have just used the latest available at the time, which at the moment is 6.3.0 (also, I'm using Manjaro Linux), and the version that ships with the Arduino ide for Windows is 4.9.2.
I think we should use the version that gives the smallest files, I will test later and see if there is much of a difference between the two.

[JadinAndrews]

Good news @per1234 , I got serial + mmc working at 3716 bytes.
I only have a 328p, but if you want to test it out I have built a bootloader at my branch (cable select 4), just flash and let me know if it works for you too.
https://github.com/JadinAndrews/avr_boot/tree/master/build

I foresee that there is a bug. Serial flashes first, but if there is a FIRMWARE.BIN on the SD card, that will be flashed as well. So to test, only use one or the other method of flashing.

EDIT: I fixed the bug mentioned above, made stk500v1 return something and added some code to main.c. Now mmc flashing is only attempted if serial was unsuccessful. I'm keen for one of you to test my bootloader, I will need help for mcu's other than 328p.
Also, for some reason, after adding these few tweaks, the bootloader size came down to 3696 bytes. Makes no sense to me, but I'll take the saving..

Happy flashing :)

[alexsartin]

Thank you for the advices. Next week I will start testing and tweaking.

thseiler in 2boots commented:

Newer avr-gcc versions do no longer support the intermodule optimisation framework (-combine), it was replaced by the more generic linktime optimisation framework (-lto)

Because of that, AVR-GCC versions smaller than 4.6 produces smaller hex file (at least 10% less).
The down side in earlier gcc versions is that common bugs haven't been crushed yet.

[per1234]

@JadinAndrews that's great news, thanks! As soon as I get some time I'll do some testing with all the boards I have on hand as well as a test build for every configuration supported by the Arduino IDE hardware definitions.

Because of that, AVR-GCC versions smaller than 4.6 produces smaller hex file (at least 10% less).

I'm no expert but I suspect there are features in the latest AVR-GCC versions that can make up for this, but might need to be enabled:

• LTO
• Bootloader hangs on Mega2560 codebndr/Ariadne-Bootloader#30 (comment)

[NicholasTracy]

Sorry to have been away for so long, I lost my previous git account (SergeantSeven) and created a new one recently. Any news on serial upload support on 1284p boards and others? I see @JadinAndrews managed to accomplish what I could not finish. I'll admit I was grasping for straws when I first started on this. I'm better equipped now to do this kind of work. let me know if anything needs testing or work.

[JadinAndrews]

@NicholasTracy Yeah I kind of come back to this project every few years.. :P I did manage to get serial uploads to work on an ATMega 1284p, but never got around to sorting out the board signature issue. After you flash my build, avrdude thinks the board is an ATMega 1284. IIRC, there is no difference between the two that matters, and the bootloader still works as expected.

I never got around to sourcing a 1284p, so if you could test then that would help a lot. I kind of lost interest after getting serial working on the 328p since that is the only board I had on hand, also work and studies went in a different direction for a while. Would be nice if someone could sort this out once and for all.

[NicholasTracy]

I will check it out, It would be nice to have this wrapped up and have a pull request so that the changes can be merged. looks like not a lot has been going on with development, any way you can update your fork with the most recent changes to the master?

[anatom74]

@JadinAndrews :
If I see it right, it should work with atmega1280 also (I managed to get it working with original avr-boot, so I modified makefile in https://github.com/JadinAndrews/avr_boot/tree/master/build), but when running avrdude on baudrate 19200 or even 57600, It doesn't sync (SD bootloader works).
Any idea what to check?

[JadinAndrews]

@JadinAndrews :
If I see it right, it should work with atmega1280 also (I managed to get it working with original avr-boot, so I modified makefile in https://github.com/JadinAndrews/avr_boot/tree/master/build), but when running avrdude on baudrate 19200 or even 57600, It doesn't sync (SD bootloader works).
Any idea what to check?

@anatom74 :
If you can't get it to flash over serial at all, then it may be the case that the cable select ports and bit is wrong in the make file? Or incorrect baudrate. You can also enable UART debugging, set USE_UART to 1 in the makefile, might help you nail down the problem. It spits out a few messages during boot, this lets you know if the serial port is working (correct pins).

Lastly, try build without sd support by setting: USE_SERIAL_FLASHING, USE_FAT16 and USE_FAT32 to 0 in the makefile. This essentially turns it into a standard bootloader without SD support. It could be that the sd card is being initialized and putting garbage on the uart lines. If you can get it to flash with serial only then it has to be something to do with the watchdog reset flag.

[anatom74]

I managed to get it working (atmega1280), but I see that it is flashing up to 65536 bytes long. Anything bigger will result in verify failure.
avrdude.exe: verification error, first mismatch at byte 0x0000 0xee != 0x0c avrdude.exe: verification error; content mismatch

[anatom74]

Hmm, I think I got it (though I don't know if this is the right place) by adding following into prog_flash.h:
#if defined (__AVR_ATmega1280__) || defined(__AVR_ATmega2560__) #define LARGE_ADDR_SPACE #endif

[fiskusmati]

@JadinAndrews Hi, I need serial + SD bootloader for my UNO.
I tried 2boot but it doesn't work.
I tried your git but also arduino IDE can't upload sketches (normal arduino bootloader works ok, SD card bootloading works fine, just serial is not working).
Can anybody help?