NEWER New Optiboot bootloader

Using Arduino Microcontrollers
#1

The thread at New optiboot; beta testers welcome has become rather stale; originally offered in 2011, the most important changes were integrated into the IDE and onto Uno in about the IDE 1.0 timeframe, and they fixed nearly all of the actual bugs that used to bother Arduino users.

However, development of the Optiboot bootloader has continued (rather slowly) in its own source repository, and may have features that are interesting to a small minority of users, so I'd like to continue discussion in this thread.

The Optiboot bootloader that is contained in the IDE, and that ships on Unos, is version 4.4. The current "Development" Optiboot is version 6.2, and includes the following changes. (Note that many of these are not relevant to the ATmega328 that ships with Uno.)

  • Support for additional chips. Notably ATmega1284p, but also ATmega32, Atmega88, and Atmega168p
  • Support for the additional uarts on chips with more than one.
  • Save reset cause in a way that the application can read it.
  • Adjust source and compilation options so that newer versions of gcc can be used to compile Optiboot.
  • (while making sure that the core stays less than 512 bytes!)
  • implement build infrastructure that makes it easier to build "custom" versions of Optiboot
  • increase range of available baudrates, but also check whether the specified baudrate is likely to work.
  • Move everything from Google code to Github
  • Write some documentation in Wiki formatting, and attach it to the repository.

The repository is here: https://github.com/Optiboot/optiboot/ And the wiki is here: https://github.com/Optiboot/optiboot/wiki

Many of the more recent and visible features were contributed by 3rd parties; the way open source is supposed to work. Yeah!

#2

What do you mean by “Save reset cause in a way that the application can read it.”?

#3

What do you mean by "Save reset cause in a way that the application can read it."?

Optiboot normally "eats" the initial contents of the MCUSR register (which contains the reset cause) as part of its normal operation. "dkinzer" came up with a patch that will pass most of the relevant bits to the application in the R2 register, and the sketch can save that. There are actually some additional improvements for this "in the queue".

See https://code.google.com/p/optiboot/issues/detail?id=66

#4

There are status bits that record whether the last reset was the result of a power on, external reset, or watchdog time-out. There is some concern that the bootloader might alter those status bits as it perform its check for synchronisation with the IDE, so a standardised way is provided to preserve them when it hands execution over to the loaded sketch.

#5

@Paul__B, I think you are saying right but these steps already performed by the problem raiser! According to me it is problem from long time and most of the time i have also deducted in my end…need permanent solutions for same…

#6

westfw: - Support for additional chips. Notably ATmega1284p, but also ATmega32, Atmega88, and Atmega1698p

What's a Atmega1698p? Typo?

#7

twice: What do you mean by "Save reset cause in a way that the application can read it."?

One example I use it for is to avoid a loud audio "pop" on my speakers when I power up the Arduino with an audio DAC card. Otherwise I would also get a audio "pop" when just pressing the reset button. So I want to ramp up the audio to mid level only during power up and not just a reset.

void setup() {
  // Get reset flags
  resetFlagsInit();
  // ramp up to mid audio level to avoid pop, unless from reset.
  mcpDacInit();
  if (resetFlags & _BV(PORF)) {
    for(int i=0; i<=2048; i++) {
      mcpDacSend(i);
    }
  }
}
#8

There is now a version of Optiboot that will install automatically using the new 1.6.4 Boards Manager. You can point the Preferences "additional url" field here: https://github.com/Optiboot/optiboot/releases/download/v6.2/package_optiboot_optiboot-additional_index.json (this is a sort of "interim" pre-release, mostly for use in testing the auto-install stuff.) And then use the Boards Manager to install (many of) the Optiboot .hex files and menus.

#9

I discovered that I have no clue about bootloaders and all the info I have found further confuses me. Mostly b/c it does not directly fit me. Hopefully, someone in this thread can educate me.

I have a mega 2560 R3 that has a CH340G. It is acting very strange and I would like to reload a bootloader. I have Arduino 1.6.4. The bd is used with Ramps V1.4 on a 3D printer. I have loaded sketches many times (TOO many). I have another mega bd due here today with (hopefully) a 16a2 instead of the 340.

I would like to know which bootloader to use on the old bd and how to load it with what I have?

If that doesn't work, what do I need? The bd is cheap so it is more a learning exercise, otherwise I would just toss it.

thx for your help

#10

To burn a bootloader

http://www.arduino.cc/en/Tutorial/ArduinoISP

#11

Many of the "burn bootloader" instructions won't work on a MEGA2560. Optiboot doesn't work on it, for instance, and neither does Arduino as ISP. You should start another thread, and describe "acting very strange" in a lot more detail. From your description, it doesn't sound like a bootloader problem. The bootloader is ONLY used to load new sketches. If you can load a sketch, the bootloader is working fine, and shouldn't be having any effect on the sketch itself.

#12

Hello,

Request to share the (latest and working ) opti-boot-loader for Atmega32 in hex file format.

Currently I am working with Atmega32A mcu as well, but having problem in terms of serial communication. Tried different boot-loader for mega32 but giving problems. On net there are multiple version available not sure about which one to pick. Hence this request.

  • Pradip
#13

pradipkhare: Hello,

Request to share the (latest and working ) opti-boot-loader for Atmega32 in hex file format.

Currently I am working with Atmega32A mcu as well, but having problem in terms of serial communication. Tried different boot-loader for mega32 but giving problems. On net there are multiple version available not sure about which one to pick. Hence this request.

  • Pradip

I got the lastest Optiboot working with ATmega32 at 8MHz internal and 16MHz external oscillator :) You'll find all the files you need to get started! http://forum.arduino.cc/index.php?topic=322745.msg2232420#msg2232420

#14

Does the 1 MHZ option use the internal xtal?

#15

An idea for a next release: It might help to have OSCCAL as a parameter, I had it in the old bootloader, at the very beginning of main()

#ifdef OSC_CAL   
   // OSCCAL calibration for 8.000MHz internal OSC, Pito 29/4/2011
   OSCCAL = OSC_CAL;
#endif

Then, for example, -DOSC_CAL=134 in the Makefile set the proper clock frequency so the upload (and the uart communication within the sketch) worked fine. PS: to find the proper OSC_CAL is an another story, the values from 1-254 I tried in past did 5-15MHz OSC clock, nonlinear behavior, however.. :) P.

#16

Hi all,

first of all: thanks for this wonderful work!

I am just trying to get an UNO R3 together with a W5100 shield to work. However, in case of power loss (or first power up) the sketch does not properly load, but as soon as I press reset, everything works fine. As far as I could find out the arduino boots so fast, that the shield cannot properly initialize. So I tried to add a delay to optiboot for my special purpose - all I could achieve was that I could not burn a program any more, as avrdude ran into timeouts.

So my question: can anyone please tell me, WHERE exactly in the optiboot.c code a delay could be placed without interfering with the flashing routines?

/edit: the TIMEOUT_MS could point in that direction, but seems not to be supported (yet)?

Thanks in advance!

Otto

#17

While it is "interesting" that the normal Bootloader timeout is sufficient to allow the WS5100 shield to initialize, the proper place to insert a delay is surely in the sketch itself, rather than the bootloader. A "delay(1500)" at the beginning of setup() should be indistinguishable from a delay in the bootloader. (Ideally, there should be some way for the code to check whether the ws5100 is 'ready' for whatever is being done to it. But I don't know whether there is. The WS5100 has a lot of signals that are not connected to Arduino at all...)

(It DOES make sense that you're seeing insufficient delay on poweron, but not normal reset. The bootloader has a feature called "fast start" that starts the sketch code immediately after poweron, and only runs the bootloader (which delays for about 1500ms looking for new code) on an explicit "reset.")

#18

i always set opti timeout to half second regardless of reset type. just enough time for the "button pushers" and plenty snappy for auto-reset. instant run after flash.

btw if you are responsible for the alternate boards.txt in there mucho grassy-asss. it was a huge problem solver.

#19

Thanks for your hints. Interesting: Even a delay(5000) as first instruction of setup does not change anything. As soon as I power on the arduino, the RX led flashes approx. once a second. Thats it. Only if I press the reset button, the sketch loads and everything runs as it should. And I have tested this with different sketches on different arduinos and different shields (all the same w5100 thou...)

My last hope is to try the delay somewhere in the bootloader, but I cant find out where ^^

#20

You can try changing the code at main, from:

  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF) | _BV(BORF) | _BV(PORF)))
      appStart(ch);

to

  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF)))
     appStart(ch);

That should remove the special treatment of power-on.