Arduino Forum

Using Arduino => Microcontrollers => Topic started by: westfw on May 11, 2015, 11:32 pm

Title: NEWER New Optiboot bootloader
Post by: westfw on May 11, 2015, 11:32 pm
The thread at New optiboot; beta testers welcome (http://forum.arduino.cc/index.php?topic=64105.msg466703) 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.)



The repository is here: https://github.com/Optiboot/optiboot/ (https://github.com/Optiboot/optiboot/)
And the wiki is here: https://github.com/Optiboot/optiboot/wiki (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!
Title: Re: NEWER New Optiboot bootloader
Post by: twice on May 12, 2015, 12:21 am
What do you mean by "Save reset cause in a way that the application can read it."?
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on May 12, 2015, 04:07 am
Quote
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 (http://"https://code.google.com/p/optiboot/issues/detail?id=66")

Title: Re: NEWER New Optiboot bootloader
Post by: Paul__B on May 12, 2015, 04:47 am
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.
Title: Re: NEWER New Optiboot bootloader
Post by: jaidevraghu on May 14, 2015, 07:41 am
@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.. 
Title: Re: NEWER New Optiboot bootloader
Post by: hiduino on May 22, 2015, 11:54 pm
  • Support for additional chips.  Notably ATmega1284p, but also ATmega32, Atmega88, and Atmega1698p


What's a Atmega1698p?  Typo?
Title: Re: NEWER New Optiboot bootloader
Post by: hiduino on May 23, 2015, 02:05 am
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.

Code: [Select]

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);
    }
  }
}
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on May 30, 2015, 09:45 am
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 (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.

Title: Re: NEWER New Optiboot bootloader
Post by: ruggb on May 30, 2015, 06:21 pm
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
Title: Re: NEWER New Optiboot bootloader
Post by: jstampfl on May 31, 2015, 07:38 am
To burn a bootloader

http://www.arduino.cc/en/Tutorial/ArduinoISP
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on May 31, 2015, 10:08 am
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.
Title: Need an Opti Boot Loader for Atmega32
Post by: pradipkhare on Jun 22, 2015, 11:37 am
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

 
Title: Re: NEWER New Optiboot bootloader
Post by: hansibull on Jun 25, 2015, 09:59 am
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 (http://forum.arduino.cc/index.php?topic=322745.msg2232420#msg2232420)
Title: Re: NEWER New Optiboot bootloader
Post by: Isaac96 on Jun 25, 2015, 03:53 pm
Does the 1 MHZ option use the internal xtal?
Title: Re: NEWER New Optiboot bootloader
Post by: pito on Jul 23, 2015, 09:53 pm
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()
Code: [Select]
#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.
Title: Re: NEWER New Optiboot bootloader
Post by: otto001 on Aug 23, 2015, 07:29 pm
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
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Aug 26, 2015, 06:57 am
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.")
Title: Re: NEWER New Optiboot bootloader
Post by: john1993 on Aug 26, 2015, 05:12 pm
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.
Title: Re: NEWER New Optiboot bootloader
Post by: otto001 on Aug 26, 2015, 08:01 pm
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 ^^
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Aug 26, 2015, 08:48 pm
You can try changing the code at main, from:
Code: [Select]
  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF) | _BV(BORF) | _BV(PORF)))
      appStart(ch);


to

Code: [Select]
  ch = MCUSR;
  MCUSR = 0;
  if (ch & (_BV(WDRF)))
     appStart(ch);


That should remove the special treatment of power-on.
Title: Re: NEWER New Optiboot bootloader
Post by: otto001 on Aug 27, 2015, 07:41 pm
Hi,

thank you. I am experiencing a weird problem though...

I am running a Fedora 22 box and compiled optiboot using

Code: [Select]
make ENV=arduino LED_DATA_FLASH=1 LED_START_FLASHES=3 LED=B0 BAUD_RATE=115200 atmega328

I am getting optiboot_atmega328.hex and optiboot_atmega328.lst
Then I burn it using avrdude:
Code: [Select]
avrdude -c usbtiny -p m328p -U flash:w:optiboot_atmega328.hex -v

Everything works fine, but when I try to upload a sketch using the arduino environment I am getting:
Code: [Select]
avrdude: stk500_getsync() attempt 2 of 10: not in sync: resp=0x00

I think I am having a more basic problem when trying to build / burn optiboot....
The weird thing is, if I burn the optiboot-version which is delivered with the arduino environment everything works fine!?
Does anyone know this problem? Or is this the wanted behaviour?
(Sorry, if this should be too basic for this thread)
/edit: the command I am using (from arduino IDE) to upload the program is
Code: [Select]
/home/otto/Downloads/arduino-1.6.5/hardware/tools/avr/bin/avrdude -C/home/otto/Downloads/arduino-1.6.5/hardware/tools/avr/etc/avrdude.conf -v -patmega328p -carduino -P/dev/ttyUSB0 -b115200 -D -Uflash:w:/tmp/build2203132785643432015.tmp/sketch_aug28a.cpp.hex:i

And this is the entry in boards.txt:
Code: [Select]
uno.name=Arduino Uno

uno.vid.0=0x2341
uno.pid.0=0x0043
uno.vid.1=0x2341
uno.pid.1=0x0001
uno.vid.2=0x2A03
uno.pid.2=0x0043

uno.upload.tool=avrdude
uno.upload.protocol=arduino
uno.upload.maximum_size=32256
uno.upload.maximum_data_size=2048
uno.upload.speed=115200

uno.bootloader.tool=avrdude
uno.bootloader.low_fuses=0xFF
uno.bootloader.high_fuses=0xDE
uno.bootloader.extended_fuses=0x05
uno.bootloader.unlock_bits=0x3F
uno.bootloader.lock_bits=0x0F
uno.bootloader.file=optiboot/optiboot_atmega328.hex

uno.build.mcu=atmega328p
uno.build.f_cpu=16000000L
uno.build.board=AVR_UNO
Title: Re: NEWER New Optiboot bootloader
Post by: otto001 on Aug 29, 2015, 11:02 pm
No one? :-(
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Aug 30, 2015, 01:24 am
Code: [Select]
make ENV=arduino LED_DATA_FLASH=1 LED_START_FLASHES=3 LED=B0 BAUD_RATE=115200 atmega328


So, where are you executing this command?  And what are the results?
For instance, you also say:
Code: [Select]
/home/otto/Downloads/arduino-1.6.5/



But I don't think that the ENV=arduino thing works with 1.6.5...

Code: [Select]
avrdude -c usbtiny -p m328p -U flash:w:optiboot_atmega328.hex -v


And what's the output from this?  It doesn't program the fuses, but if you started with an Uno and can use the stock bootloader, that should mean the fuses are OK.
Do you see the initial three blinks when you press reset or start an upload?


Quote
when I try to upload a sketch using the arduino environment I am getting
The "not in sync" error is pretty worthless error messages go. :-(  Can you turn on verbose uploading and report the output from that as well?

I haven't actually tested the patch I suggested, on a real Uno or otherwise.
(and yes, this should probably be a new thread.)

Title: Re: NEWER New Optiboot bootloader
Post by: otto001 on Aug 30, 2015, 04:48 pm
Thank you!
I opened a new thread for this here: http://forum.arduino.cc/index.php?topic=344873.0 (http://forum.arduino.cc/index.php?topic=344873.0)
Title: Re: NEWER New Optiboot bootloader
Post by: AlxDroidDev on Oct 01, 2015, 02:59 pm
Does it work on the Atmega1284 (non-P) as well ?
Title: Re: NEWER New Optiboot bootloader
Post by: CircuitSerialKiller on Oct 04, 2015, 06:31 am
Hi all, just for the sake of anyone interested doing a search, I had to compile Optiboot tonight for a 1284P running with a 12MHz crystal I just reworked onto my board. Although the 1284P @ 5v, 16MHzhas been stable for me and everyone else I've heard from, it does have issues if there's a voltage sag long before hitting the brownout voltage. The datasheet does show however that the 1284P is stable at 12MHz.

Everything worked great the first time - no problem with tons of serial data at 115200, or delay(), etc. Although I guess there's a few libraries out there that may need to be tweaked for 12MHz.

Anyhow, it was very easy to do as long as you've compiled bootloaders before. This was my first time compiling Optiboot, so I just had to read through the makefile a little bit, add in some lines for a 12MHz version, and of course add in a 12MHz version in boards.txt. If you want a 12MHz bootloader for the 1284P, PM me.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Oct 06, 2015, 01:35 am
Quote
Does it work on the Atmega1284 (non-P) as well ?
It should.  Like the 328 vs 328p, the differences are pretty subtle.  However, I don't have and haven't tested a 1284(non-P)...


Quote
I just had to read through the makefile a little bit, add in some lines for a 12MHz version
If all you are doing is changing the clockrate, you should have been able to do it all from the command line like:
Code: [Select]
make atmega1284 AVR_FREQ=12000000

Title: Re: NEWER New Optiboot bootloader
Post by: chucktodd on Oct 07, 2015, 12:35 am
Hi all, just for the sake of anyone interested doing a search, I had to compile Optiboot tonight for a 1284P running with a 12MHz crystal I just reworked onto my board. Although the 1284P @ 5v, 16MHzhas been stable for me and everyone else I've heard from, it does have issues if there's a voltage sag long before hitting the brownout voltage. The datasheet does show however that the 1284P is stable at 12MHz.
CircuitSerialKiller,
 How did you get optiboot to recompile?  
I am trying and failing.  I have a 'new, fresh' Arduino 1.6.5 environment. Under Windows 7 Profession.

the readme file says to open a cmd line in the optiboot directory:
in my case:
Code: [Select]

C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\optiboot>

I issue:
Code: [Select]

omake Makefile.2560

to which windows responds:

Code: [Select]

C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\optiboot>omake Makefil
e.2560

C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\optiboot>..\..\..\tools\a
vr\tools\bin\make OS=windows ENV=arduino Makefile.2560
The system cannot find the path specified.

C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\optiboot>

The only file make in my Program Files folder is:

Code: [Select]


C:\Program Files>dir make.* /s/p
 Volume in drive C is win7 boot
 Volume Serial Number is A449-8596

 Directory of C:\Program Files\Arduino\tools\Mangler

06/15/2015  03:20 AM               243 make.sh
               1 File(s)            243 bytes

     Total Files Listed:
               1 File(s)            243 bytes
               0 Dir(s)  1,443,716,280,320 bytes free

C:\Program Files>


Here is the directory structure of my Arduino folder.

Code: [Select]

hardware{
  arduino{
    avr{
      bootloaders{
        atmega
        atmega8
        bt
        caterina
        caterina-Arduino_Robot
        caterina-LilyPadUSB
        gemma
        lilypad{
          src}
        Old_optiboot
        optiboot
        stk500v2}
      cores{
        arduino}
      firmwares{
        arduinoISP
        atmegaxxu2{
          arduino-usbdfu{
            Board}
          arduino-usbserial{
            Board
            Lib}}
        wifishield{
          binary
          scripts
          wifiHD{
            Release
            src{
              CONFIG
              SOFTWARE_FRAMEWORK{
                ASM
                BOARDS{
                  ARDUINO
                  EVK1105}
                COMPONENTS{
                  MEMORY{
                    DATA_FLASH{
                      AT45DBX}}
                  WIFI{
                    HD{
                      v2.7.0{
                        UCR1{
                          GCC}
                        UCR2{
                          GCC}}}}}
                DRIVERS{
                  CPU{
                    CYCLE_COUNTER}
                  EBI{
                    SMC}
                  EIC
                  FLASHC
                  GPIO
                  INTC
                  PDCA
                  PM
                  RTC
                  SPI
                  TC
                  USART}
                SERVICES{
                  DELAY
                  LWIP{
                    lwip-1.3.2{
                      src{
                        core{
                          ipv4}
                        include{
                          ipv4{
                            lwip}
                          lwip
                          netif}
                        netif}}
                    lwip-port-1.3.2{
                      HD{
                        if{
                          include{
                            arch
                            netif}
                          netif}}}}
                  MEMORY{
                    CTRL_ACCESS}}
                UTILS{
                  DEBUG
                  LIBS{
                    NEWLIB_ADDONS{
                      INCLUDE}}
                  LINKER_SCRIPTS{
                    AT32UC3A{
                      0512{
                        GCC}
                      1256{
                        GCC}}}
                  PREPROCESSOR
                  STARTUP_FILES{
                    GCC}}}}}
          wifi_dnld{
            Release
            src{
              CONFIG
              Doc
              SOFTWARE_FRAMEWORK{
                ASM
                BOARDS{
                  ARDUINO
                  EVK1105}
                COMPONENTS{
                  MEMORY{
                    DATA_FLASH{
                      AT45DBX}}}
                DRIVERS{
                  FLASHC
                  GPIO
                  INTC
                  PM
                  SPI
                  USART}
                SERVICES{
                  MEMORY{
                    CTRL_ACCESS}}
                UTILS{
                  DEBUG
                  LIBS{
                    NEWLIB_ADDONS{
                      INCLUDE}}
                  LINKER_SCRIPTS{
                    AT32UC3A{
                      0512{
                        GCC}
                      1256{
                        GCC}}}
                  PREPROCESSOR
                  STARTUP_FILES{
                    GCC}}}}}}}
      libraries{
        EEPROM{
          examples{
            eeprom_clear
            eeprom_crc
            eeprom_get
            eeprom_iteration
            eeprom_put
            eeprom_read
            eeprom_update
            eeprom_write}}
        SoftwareSerial{
          examples{
            SoftwareSerialExample
            TwoPortReceive}}
        SPI{
          examples{
            BarometricPressureSensor
            DigitalPotControl}}
        Wire{
          examples{
            digital_potentiometer
            master_reader
            master_writer
            SFRRanger_reader
            slave_receiver
            slave_sender}
          utility}}
      variants{
        eightanaloginputs
        ethernet
        gemma
        leonardo
        mega
        micro
        robot_control
        robot_motor
        standard
        yun}}}
  tools{
    avr{
      avr{
        bin
        include{
          avr
          compat
          util}
        lib{
          avr25{
            tiny-stack}
          avr3
          avr31
          avr35
          avr4
          avr5
          avr51
          avr6
          avrtiny
          avrxmega2
          avrxmega4
          avrxmega5
          avrxmega6
          avrxmega7
          ldscripts
          tiny-stack}}
      bin
      etc
      i686-pc-mingw32{
        avr{
          include
          lib}}
      include{
        gdb}
      lib{
        gcc{
          avr{
            4.8.1{
              avr25{
                tiny-stack}
              avr3
              avr31
              avr35
              avr4
              avr5
              avr51
              avr6
              avrtiny
              avrxmega2
              avrxmega4
              avrxmega5
              avrxmega6
              avrxmega7
              include
              include-fixed
              install-tools{
                include}
              tiny-stack}}}}
      libexec{
        gcc{
          avr{
            4.8.1{
              install-tools}}}}}}}



 

Any Ideas on how to make optiboot?

Chuck.

Attached is a complete foldable directory tree of Program Files\Arduino
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Oct 07, 2015, 12:43 am
Quote
How did you get optiboot to recompile?  
  I have a 'new, fresh' Arduino 1.6.5 environment.
The arduino team has removed "make" from the arduino tools distribution. :-(
https://github.com/Optiboot/optiboot/issues/118 (https://github.com/Optiboot/optiboot/issues/118)
So the easiest solution now is to install the Arduino IDE 1.0.x;   a better (but more difficult) solution is to install the Atmel command-line tools, or add make and bash separately.

Title: Re: NEWER New Optiboot bootloader
Post by: chucktodd on Oct 07, 2015, 01:08 am
The arduino team has removed "make" from the arduino tools distribution. :-(
https://github.com/Optiboot/optiboot/issues/118 (https://github.com/Optiboot/optiboot/issues/118)
So the easiest solution now is to install the Arduino IDE 1.0.x;   a better (but more difficult) solution is to install the Atmel command-line tools, or add make and bash separately.


ATMEL Command Line Tool Chain (http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx)

Ok, I got the Atmel command-line tools, where do install it to?   It defaults to my Downloads folder.

but?  I just expanded it into a temp folder, and no make file anywhere?

Chuck.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Oct 07, 2015, 03:03 am
Hmm.  You're right.  Let me check...
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Oct 07, 2015, 10:54 am
(so far, avrfreaks is leaning toward "install the 2010 version of WinAVR, and replace the compiler bits with the new files from the Atmel Toolchain.)  (Actually, WINAVR alone is sufficient to compile Optiboot, even with the old compiler.)
Title: Re: NEWER New Optiboot bootloader
Post by: Khuffman35 on Oct 17, 2015, 03:52 am
How does Optiloader deal with an alternate clock frequency?  I have a custom designed board with the ATMega328 running an internal clock.  The bootloader must have an "awareness" of the clock frequency in order to set a known baud rate.  It is unclear to me how to do this.  The internal clock is set for 8 MHz.

Related, when creating a sketch to download to the bootloader, what should be selected for the board type in Sketch?  There doesn't appear to be a valid board configuration that matches the 328 (not 328P) with an 8MHz clock.

Thanks in advance.
Kevin
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Oct 17, 2015, 05:25 am
You need to either compile an optiboot for your changed clock rate, or adjust the baud rate in boards.txt (which is easier.)

For a 328 at 8MHz, the "semi-official" preferred method is to load the stock 328P 16MHz bootloader, and use a boards.txt entry that says "328p at 8MHz, 57600bps upload speed."  The sketch/compile step doesn't need to know about 328 vs 328p issues, and the bootloader will lie and say it's a 328p anyway.
Title: Re: NEWER New Optiboot bootloader
Post by: Khuffman35 on Oct 19, 2015, 01:38 am
Thanks.  That makes perfect sense.
Title: Re: NEWER New Optiboot bootloader
Post by: mprowe on Nov 19, 2015, 10:06 am
Hi,

On a sightly different theme, how do I read/test which version of Optiboot I am looking at?

It would be useful to be able to read what is on chip - maybe an AVRDude command?
And also the supplied binary that I may be considering loading to a chip - Hex Editor to look at a known location?

Or even, a PlugIn to the Arduino IDE!

Regards, Martin
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Nov 19, 2015, 06:14 pm
Quote
how do I read/test which version of Optiboot I am looking at?
The optiboot version number is stored in the last two bytes of the chip. or .hex file.
You can read this from the .hex file or with a programmer, but it is usually protected from the arduino sketches by the lock bits (sigh.  I tried to change the lockbits, but it "seemed too dangerous" to make official code.  If you're using the optiboot boards.txt or makefies to burn the new bootloader, you'll get a "readable" bootloader, and a program like FuseBytes (https://github.com/WestfW/fusebytes) will show the version number.  But not if you have a stock arduino.)

Note that the bytes show up "reversed" in the hex file, so ending with 0x02 0x06 is version 6.2

Title: Re: NEWER New Optiboot bootloader
Post by: mprowe on Nov 19, 2015, 10:48 pm
Thank you Bill,

So the current (latest?) versions at: https://github.com/Optiboot/optiboot are v6.6?

Regards, Martin
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Nov 20, 2015, 03:00 am
Still 6.2, actually.
The development plan is sort of:
  add additional platforms that do not change the code for existing chips (notably the "virtual boot partition tiny chips: tiny1634, tiny841)
  update version to 7.0
  work on features/bugs that DO affect the popular platforms.
(however, this has been the plan for several months now, without me making any progress on it. :-( )

Note that assorted "third parties" have been known to distribute slightly modified versions of Optiboot without changing the version number.  And various fourth party individuals who are compiling their own Optiboot almost certainly do not change the version number, so it's possible that some chip/hex with "6.2" in the version field may have code that doesn't actually match any "official" version.   Since one of the things that tends to break Optiboot is "new compiler does things differently", this can be a real problem.

Title: Re: NEWER New Optiboot bootloader
Post by: mprowe on Nov 20, 2015, 10:16 am
Sorry to keep bleeting on Bill... it is just that I am still not sure of my understanding.

I fully appreciate your points on variance, which is why I was confining myself to the bootloader images on GitHub.

In an earlier over you said that "The optiboot version number is stored in the last two bytes of the chip".  So, I went and looked. This is what I see:

~> hexdump -s 0x550 -C optiboot_atmega328.hex
00000550  30 30 30 30 37 45 30 30  37 42 0d 0a 3a 30 30 30  |00007E007B..:000|
00000560  30 30 30 30 31 46 46 0d  0a                       |00001FF..|
00000569
~>

What am I missing? I think I see 0x46 0x46 0x0d 0x0a as the last few bytes of the file. Ignoring the cr/lf, is that v6.6 I read.

This is no way a criticism or challenge, it is just that when the information doesn't reconcile, I'm not sure of my understanding!

Best regards, Martin
Title: Re: NEWER New Optiboot bootloader
Post by: majek on Nov 21, 2015, 11:56 pm
optiboot_atmega328.hex is ascii file in intel hex format :-)
Look inside:
Code: [Select]
:027FFE00020679

last two bytes of data are 02 06 just like Bill said.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Nov 22, 2015, 02:17 am
Quote
hexdump -s 0x550 -C optiboot_atmega328.hex
     :
What am I missing?
The .hex file is already an ascii-ized file of hex characters, so if you use "hexdump", you are dumping the ascii data rather than the binary content represented by the .hex file.   You either want "avr-objdump" or "tail":

tail -3l optiboot_atmega328.hex
:027FFE00020679
:0400000300007E007B
:00000001FF


> avr-objdump -march=avr -s optiboot_atmega328.hex
optiboot_atmega328.hex:     file format ihex
Contents of section .sec1:
 7e00 1f92cdb7 deb71124 84b714be 982f9d70  .......$...../.p
  :
 7fc0 f1cf282e 80e0e8df e0e0ff27 0994      ..(........'.. 
Contents of section .sec2:
 7ffe 0206                                 ..             
Title: Re: NEWER New Optiboot bootloader
Post by: mprowe on Nov 22, 2015, 09:22 pm
Ah.... That's explained that. I just needed a nudge in the right direction.

Now, why does the answer to one question lead to a whole bunch of suplimenty questions?

> avr-objdump -march=avr -s optiboot_atmega328.hex
optiboot_atmega328.hex:     file format ihex
Contents of section .sec1:
 7e00 1f92cdb7 deb71124 84b714be 982f9d70  .......$...../.p
  :
 7fc0 f1cf282e 80e0e8df e0e0ff27 0994      ..(........'.. 
Contents of section .sec2:
 7ffe 0206                                 ..             

Section? (blue highlighting)

I can't find any reference in the Intel Hex File Format or the avr_objdump documentation.
Is it a "compiler thing"? Writing to two sections of memory, which, in this case just happen to be contiguous?

Many, (many), thanks for your patience, Martin
Title: Re: NEWER New Optiboot bootloader
Post by: chucktodd on Nov 23, 2015, 12:44 am
Ah.... That's explained that. I just needed a nudge in the right direction.

Now, why does the answer to one question lead to a whole bunch of suplimenty questions?

Section? (blue highlighting)

I can't find any reference in the Intel Hex File Format or the avr_objdump documentation.
Is it a "compiler thing"? Writing to two sections of memory, which, in this case just happen to be contiguous?

Many, (many), thanks for your patience, Martin
They are not contiguous,  the .sec1 is actually section .TEXT, and .sec1 is the .version section.

.TEXT  ends at 0x7FCD
.version starts at 0x7FFE

So, there is about 31 bytes of FLASH unused between them.

Chuck.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Nov 23, 2015, 03:30 am
Quote
Section?
For a .hex file, I think it assumes that any discontinuity in the data starts a new "section."  (I can delete a line from the middle of the contiguous code space, and suddenly I have three sections instead of two.)

For .elf and .o files, sections are a "big deal", and too complicated to explain here.
The optiboot implementation uses a separate section for the version number, which is what permits it to be place "at the end of Flash" while the code itself is placed "at the beginning of the bootloader section."  (note that "bootloader section" is a hardware thing that is not particularly related to the .elf file "code sections.")

Title: Re: NEWER New Optiboot bootloader
Post by: somedude on Feb 01, 2016, 09:33 pm
Bill,


Would you mind clarifying one thing?

I tried compiling Optiboot for my 1284p and on github, your boards.txt has this comment and low fuse setting:

# Select full swing crystal oscillator (7F rather than FF)
optiboot1284.bootloader.low_fuses=0x7F

If I look at the fuse calculator here (http://www.engbedded.com/fusecalc/) it looks like:
0x7F has CKDIV8 enabled and 0xFF is External Crystal
Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?

Thank you very much.

Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Feb 02, 2016, 01:50 am
Quote
Now full swing appears to be 0xF7 without changing anything else, so is this a late-night typo?
Yes, it appears so.  I have the F7 value in the *_isp targets in the Makefile, but the wrong values in boards.txt.
Sigh.  I've created https://github.com/Optiboot/optiboot/issues/174

Title: Re: NEWER New Optiboot bootloader
Post by: somedude on Feb 02, 2016, 03:41 pm
I hate to bug you again, but I had trouble burning the bootloader to my 1284P, so I attempted some troubleshooting and read a bunch of other things.

Since lock bits are not clear in my mind, I will simply state my findings, without attempting to comment.
So here it is: maniacbug (https://github.com/maniacbug/mighty-1284p/blob/master/boards.txt) has the lock bits as 0x0F instead of 0x2F. I was getting a verification error when attempting to burn the bootloader with 0x2F for the lock bit, but I was successful with 0x0F.

I will do some reading in an attempt to understand the lock bits, but I thought I should mention this.
And I apologize for not specifying earlier that I am looking at boards.txt for 1.6



Edit: After spending some time reading the datasheet, I think this is what needs to happen:
Unprogramming (1) bootloader lock bits BLB11 and BLB12 (0x3F) removes any restrictions accessing the boot loader, necessary to be able to write it to the chip.
Programming (0) them both (0x0F) locks writing to the boot loader and reading from it as well.
Only programming BLB11 (0x2F) just locks the bootloader for writing.

So, if I understand this correctly, both 0x0F and 0x2F lock the bootloader for write, which makes sense so that it doesn't get wiped out, but 0x2F allows the program to read from it.

In my case, both lock bit settings should have worked, as both are valid.
I will go back to 0x2F and retry, maybe I messed something else up.


Edit (again - sorry): It worked with 0x2f, so it was me.

Sorry for wasting your time.
Title: Re: NEWER New Optiboot bootloader
Post by: somedude on Feb 03, 2016, 03:46 pm
Update - for the sake of closure, I wanted to explain how I got Optiboot compiled for my 1284p.

RTFM was the key here, but I was unable to upload a sketch until I overrode the baud rate.
I noticed that Arduino writes at 19200 through the programmer, so I used that baud rate as a compile option and it finally took the sketch.

Thank you very much for Optiboot, it is amazing.
Title: Re: NEWER New Optiboot bootloader
Post by: srinivardhan on Feb 10, 2016, 02:42 pm
Hi,

I thought I should write my own boot loader so that I could boot load through UART1 instead of UART0. I want to flash my hex file via  a bluetooth module HC 05. But then I found bootloader called optiboot. Will the 1284 optiboot compiled for UART1 instead of UART0 (EXPERIMENTAL!) present in the https://code.google.com/archive/... suffice my need ?

I was told by AVR clawson to sort it out with westfw :)
 
I want to run at 9600 baud rate. Do I need to make any changes to the source code and if so how ?
 
Looking forward to hear from you,
Title: Re: NEWER New Optiboot bootloader
Post by: Party_Waffel on Feb 18, 2016, 06:32 pm
Hi,

I've recently managed to install optiboot on an arduino nano with an ATmega328p. It works perfectly except when I power the board with my laptop via a usb cable. When I do so, the arduino flashes the led at pin 13 several times before executing the sketch. It executes the sketch instantly when powered vie the VIN pin though. I've no idea what's causing this.

Video (https://www.youtube.com/watch?v=RiN_BFwhU9Q) D13 led is the lowest one. The sketch is supposed to turn leds connected to a shift register on and off.

Thanks in advance

EDIT: the sketch loads instantly when powered by the laptop when laptop is in sleep mode. I guess it waits for serial communication before running the sketch.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Feb 19, 2016, 08:53 am
if there is something on your laptop that actually starts serial communication, it is normal for this to cause a reset and run the bootloader (causing the three flashes) (whereas a clean power-on with no serial involvement SHOULD go direct to the sketch.)  This is due to the auto-reset circuitry of the Arduino.  (which is somewhat sensitive; it wouldn't surprise me of certain power-up situations result in an "external reset" rather than a "power on" reset.  I'm not sure whether USB enumeration (without actually opening the serial port) will do anything.  But it's possible.)
Title: Re: NEWER New Optiboot bootloader
Post by: Party_Waffel on Feb 19, 2016, 10:19 pm
Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.
Title: Re: NEWER New Optiboot bootloader
Post by: DavidI on May 02, 2016, 05:11 pm
Thanks for the quick reply, I've tried turning DTR off and shorting the RST pin to the GND pin with a 10uF capacitor as stated in the serial auto reset disable guide but those didn't help either. What confuses me is that this doesn't happen at all with my uno v3 which also has optiboot installed.
From my experience using the UNO V3 as an ISP programmer, and from what I've read, the V3 doesn't need the 10uF nor does it seem to be needed with the Pro mini I'm actually using as an ISP programmer.  In both cases the DTR was left enabled.
Dave
Title: Re: NEWER New Optiboot bootloader
Post by: beic on Jun 06, 2016, 01:12 am
Hi there,

I'm searching HEX file for the ATmega8-16PU MCU named "optiboot_atmega8-16.hex", can someone please upload it?

I was unable to find on the internet!

I need it for this entry to be able to burn Bootloader to my fresh ATmega8-16PU's!

Code: [Select]

##############################################################
opti8.name=Arduino Optiboot-Atmega8-16
opti8.upload.protocol=arduino
opti8.upload.maximum_size=7680
opti8.upload.speed=115200
opti8.bootloader.low_fuses=0xbf
opti8.bootloader.high_fuses=0xcc
opti8.bootloader.path=optiboot
opti8.bootloader.file=optiboot_atmega8-16.hex
opti8.bootloader.unlock_bits=0x3F
opti8.bootloader.lock_bits=0x0F
opti8.build.mcu=atmega8
opti8.build.f_cpu=16000000L
opti8.build.core=arduino
opti8.build.variant=standard
##############################################################


Thank you!
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 06, 2016, 02:34 am
Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader (https://github.com/WestfW/OptiLoader) Or Nick's (enhanced!) Bootloader programmer (http://www.gammon.com.au/bootloader) would be easier...

Edit: it won't let be attach .hex files.  Zipped.

Title: Re: NEWER New Optiboot bootloader
Post by: beic on Jun 06, 2016, 11:32 am
Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader (https://github.com/WestfW/OptiLoader) Or Nick's (enhanced!) Bootloader programmer (http://www.gammon.com.au/bootloader) would be easier...

Edit: it won't let be attach .hex files.  Zipped.


Hi westfw,

I was Googling a few day now to find the easiest and the best solution and I came a cross to this page (http://www.instructables.com/id/Standalone-Atmega8-16pu-with-Arduino-Optiboot-Boot/) on Instructables.

And I got that boards.txt entry from that post, but it was strange to me also because of that suffix.

Thank you for your fast reply!  8)
Title: Re: NEWER New Optiboot bootloader
Post by: beic on Jun 06, 2016, 11:44 am
Here it is.  I'm not sure where you got that boards.txt file from; I'm pretty sure that the atmega8 hex file has never had the -16 suffix (somewhat irrelevant since the currently provided .hex files don't include any atmega8 binaries.)
You'll probably have trouble using the "burn bootloader" command with any modern IDE; atmega8 has been broken for a long time.  Using my OptiLoader (https://github.com/WestfW/OptiLoader) Or Nick's (enhanced!) Bootloader programmer (http://www.gammon.com.au/bootloader) would be easier...

Edit: it won't let be attach .hex files.  Zipped.


Me again and confused a little bit.

In the Arduino's "hardware\arduino\avr\bootloaders\optiboot\" there is a HEX file optiboot_atmega8.hex and it's 1.36Kb (CRC32: 6d4bc037), but what I got from your zip file is optiboot_atmega8-16.hex and it's 1.28Kb (CRC32: 1336439d), so what is basically the difference between those two HEX files?

Thank you!
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 06, 2016, 11:39 pm
The Optiboot from the IDE is version 4.4; the .hex file I posted is version 6.2 ...
There are probably not any changes that are particularly relevant to the m8 (ie no reason to use the newer one)
Most of the edits have added other chips, corrected for new compiler behavior, or enhanced the build system.
(You can view the edits at https://github.com/Optiboot/optiboot (https://github.com/Optiboot/optiboot)
Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 10, 2016, 08:04 pm
Hello,

I just saw You made support for the 328PB Chip.

I asked this some time ago, but did NOT got definitive answer.

Can be those boatloader used in commercial Products like Arduino UNO "clones"?
Which kind of bootloader those boards from China are using as bootloadeR?

Regards,
Maverick
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 11, 2016, 01:03 am

Quote
I asked this some time ago, but did NOT got definitive answer.
Can be those boatloader used in commercial Products like Arduino UNO "clones"?
Yes.
The original author licensed Optiboot under GPL2, and it would certainly be painful to change the license since he disappeared.  I'm not sure that it's clearly defined what GPL2 means WRT bootloaders, but I'd put them in the same class as Desktop Operating Systems - of course you can write commercial products that run on open source operating systems!  If you make changes to optiboot itself as part of your commercial product, you should be prepared to release those changes as open source as well.  Personally, I lean toward less viral licenses (MIT or BSD.)


Quote
Which kind of bootloader those boards from China are using as bootloadeR?
How could anyone possibly know that?  Reports have ranged from Optiboot (but I don't know what version) (especially for Uno clones), Atmegaboot (especially on Nano clones), Adaboot (on Pro Mini clones, as per Sparkfun?), and "doesn't seem to have any bootloader at all".


Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 11, 2016, 02:06 am
Thanks,

I would not going to change anything on the software.
But without the software the hardware is useless.

I want to use 328PB under the IDE, but have got some problems here.
I have changed the board file and placed the hex file to the correct directory.
I also changed the pins_arduino.h file.

Code: [Select]
optibootxmini328pb.name=Optiboot Xplained Mini 328pb

optibootxmini328pb.upload.tool=arduino:avrdude
optibootxmini328pb.upload.protocol=arduino
optibootxmini328pb.upload.speed=57600

optibootxmini328pb.bootloader.tool=arduino:avrdude
optibootxmini328pb.bootloader.unlock_bits=0x3F
optibootxmini328pb.bootloader.lock_bits=0x2F

optibootxmini328pb.build.f_cpu=16000000L

optibootxmini328pb.build.board=AVR_UNO
optibootxmini328pb.build.core=arduino:arduino
optibootxmini328pb.build.variant=arduino:standard

optibootxmini328pb.upload.maximum_size=32128
optibootxmini328pb.upload.maximum_data_size=1024

optibootxmini328pb.bootloader.low_fuses=0xBF
optibootxmini328pb.bootloader.high_fuses=0xCE
optibootxmini328pb.bootloader.extended_fuses=0xFF
optibootxmini328pb.bootloader.file=optiboot/optiboot_xplained328pb.hex

optibootxmini328pb.build.mcu=atmega328p


I'm still not able to upload anything over IDE.

Any Ideas why?

Regards,
Maverick
Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 11, 2016, 02:12 am
I get this error:


Code: [Select]
Warning: Board arduino:avr:atmega328bb doesn't define a 'build.board' preference.
Auto-set to: AVR_ATMEGA328BB

avr-g++: error: unrecognized argument in option '-mmcu=atmega328pb'

avr-g++: note: valid arguments to '-mmcu=' are: at43usb320 at43usb355 ... and so on



Do You know where can I add my board (mmcu) ?


Regards,
Maverick
Title: Re: NEWER New Optiboot bootloader
Post by: Coding Badly on Jun 11, 2016, 02:19 am

Supported processors are burned into the compiler.  You need a newer toolset.

Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 11, 2016, 02:44 am
Hello,

Newer toolset?

I made the hex file with atmel studio 7.
The IDE is package version 1.6.9

What exactly should I update?
Title: Re: NEWER New Optiboot bootloader
Post by: Coding Badly on Jun 11, 2016, 04:19 am

In the past, I have just copied the toolset from Atmel Studio to the correct location in the Arduino IDE directory.  I have also copied the entirety of... http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx (http://www.atmel.com/tools/ATMELAVRTOOLCHAINFORWINDOWS.aspx) ...to the correct location in the Arduino IDE directory.  I believe I have even posted detailed instructions on this forum.

Yup...
http://forum.arduino.cc/index.php?topic=168152.msg1252235#msg1252235 (http://forum.arduino.cc/index.php?topic=168152.msg1252235#msg1252235)
But that may be out-of-date.

Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 11, 2016, 05:46 am
The easiest way to get a PB working is to pretend that it's just a 328P.
After that is "working" (bootloader burnt, sketches uploading successfully) you can start to think about how to access the PB features...  (in fact, the current optiboot PB support pretends to be a mere P, because of the state of the Arduino IDE compiler/etc.)

(The AS7 (7.0.943) that I installed TODAY does seem to support the 328PB.)

Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 11, 2016, 01:26 pm
in fact, the current optiboot PB support pretends to be a mere P, because of the state of the Arduino IDE compiler/etc.
(The AS7 (7.0.943) that I installed TODAY does seem to support the 328PB.)
Yes, I saw that line in our code -> optibootxmini328pb.build.mcu=atmega328p

I try to get a solution to get it work under the Arduino IDE.

Regards,
Maverick
Title: Re: NEWER New Optiboot bootloader
Post by: hawkagent on Jun 12, 2016, 12:37 am
Hello

I have downloaded the newest Optiboot from github and placed it under 'Documents/Arduino/hardware/'. However whenever I try to burn the bootloader (Optiboot 28pins, 8Mhz) to an atmega328p with an USBasp I get the following error:
Code: [Select]
java.lang.NullPointerException
at cc.arduino.packages.uploaders.SerialUploader.burnBootloader(SerialUploader.java:363)
at processing.app.Editor.lambda$handleBurnBootloader$42(Editor.java:2752)
at java.lang.Thread.run(Thread.java:745)
Error while burning bootloader.

Also when I try to compile Blink, I get:
Code: [Select]

panic: runtime error: invalid memory address or nil pointer dereference
[signal 0xc0000005 code=0x1 addr=0x0 pc=0x4b39ba]

goroutine 1 [running]:
arduino.cc/builder.(*SetupBuildProperties).Run(0x692034, 0x12054000, 0x0, 0x0)
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/builder/setup_build_properties.go:86 +0x10ba
arduino.cc/builder.(*ContainerSetupHardwareToolsLibsSketchAndProps).Run(0x692034, 0x12054000, 0x0, 0x0)
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/builder/container_setup.go:59 +0x4e6
arduino.cc/builder.runCommands(0x12054000, 0x12025dc4, 0x3, 0x3, 0x1, 0x0, 0x0)
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/builder/builder.go:181 +0xe2
arduino.cc/builder.(*ParseHardwareAndDumpBuildProperties).Run(0x12025df0, 0x12054000, 0x0, 0x0)
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/builder/builder.go:170 +0x157
arduino.cc/builder.RunParseHardwareAndDumpBuildProperties(0x12054000, 0x0, 0x0)
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/builder/builder.go:217 +0x35
main.main()
c:/jenkins/workspace/arduino-builder-windows/src/arduino.cc/arduino-builder/main.go:307 +0xfd7
arduino-builder returned 2

Error compiling for board Optiboot on 28-pin cpus.

Obviously the paths are wrong (There is no C:\jenkins\workspace\). I'm sure I've missed a huge step during install, how can I fix this?
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 12, 2016, 10:09 pm
Did it work for normal platform builds before you tried to add the ne optiboot?
What ide version are you using?
Title: Re: NEWER New Optiboot bootloader
Post by: hawkagent on Jun 13, 2016, 01:02 pm
Did it work for normal platform builds before you tried to add the ne optiboot?
What ide version are you using?

When "Atmega328 on a breadboard 8Mhz" (from tutorial (https://www.arduino.cc/en/Tutorial/ArduinoToBreadboard)) is selected I can burn the bootloader and upload sketches without problems, is that what you mean?

I'm using Arduino IDE 1.6.9
Title: Re: NEWER New Optiboot bootloader
Post by: Maverick71 on Jun 13, 2016, 05:45 pm
@westfw Could You complete optiboot for the 328PB?
Title: Re: NEWER New Optiboot bootloader
Post by: nebula83 on Jul 26, 2016, 11:27 am
@westfw I am using WinAVR-20100110 to compile optiboot. I am now sanity checking my output by comparing the original hex file with my compiled version. They match up except for this line:

Original
   :087FD000E7DFEE27FF2709940B

Fresh compile
   087FD000E7DFE0E0FF27099460


The most important bit being E7DFEE27FF270994 versus E7DFE0E0FF270994 (E27 or 0E0)
Is this a relevant difference? And what does it mean?
Title: Re: NEWER New Optiboot bootloader
Post by: Isaac96 on Aug 01, 2016, 01:17 am
Does anyone know if there is a version of optiboot for the ATTiny 4313? I went through the old optiboot thread searching for it. No luck. Incidentally, I have 1Kbyte of flash remaining.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Aug 01, 2016, 09:40 am
Quote
The most important bit being E7DF EE27 FF27 0994 versus E7DF E0E0 FF27 0994 (E27 or 0E0)
The original has an instruction:
Code: [Select]
    7fd0:       e7 df           rcall   .-50            ; 0x7fa0 <watchdogConfi\
g>                                                                             
  __asm__ __volatile__ (                                                       
    7fd2:       ee 27           eor     r30, r30                               
    7fd4:       ff 27           eor     r31, r31                               
    7fd6:       09 94           ijmp             


With the EE27 instruction being the "eor r30, r30" - an exclusive or with yourself is one way to clear the register.
The new version has "e0e0" instead, which is "ldi r30, 0" - which does the same thing (zero the register.)  So you should be fine...

Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Aug 01, 2016, 09:46 am
Quote
version of optiboot for the ATTiny 4313?
Not that I know of.  You might check the version mentioned in https://github.com/Optiboot/optiboot/issues/177 (https://github.com/Optiboot/optiboot/issues/177); it apparently supports 110 chips (but I haven't gotten a chance to look at it at all.)

Title: Re: NEWER New Optiboot bootloader
Post by: nebula83 on Aug 01, 2016, 10:00 am
@westfw Ah, that's why the version wasn't updated: the behavior is the same. Thanks!
Title: Re: NEWER New Optiboot bootloader
Post by: Isaac96 on Aug 01, 2016, 10:12 pm
@westFW
Thanks!
326 bytes... That is tiny.
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 05, 2016, 01:05 pm
After some long period on Arduino IDE v1.0.6 with replaced toolchain to v3.4.2  (avr-gcc v4.7.2), I've decided to move to the Atmel AVR Toolchain v3.5.3.1700 with avr-gcc v4.9.2. I had to resolve two simple problems:
1. avr-gcc v4.9.2 doesn't support optimizing option -mshort-calls; there is -mrelax instead
2. problem with eeprom_write_byte and eeprom_read_byte (undefined reference); LIBS = -l$(MCU_TARGER) solves it.
As  I'm writting this I found in response #75 the same solution for my 2nd problem and also (partially - I'm not satisfied with) for my question.
The question is: "How to achieve at least the same size of image without modifying source code?"
I have modified optiboot and its size with 4.7.2 is 706B, with 4.9.2 it is 738B. Is there any option for another optimizing step (any switch) or the 4.9.2 simply produces bigger code and this possibility is closed?

EDIT: I tried BareMinimum sketch and the size is the same.

EDIT2: I'm currently working with ATmega1284P but as I see the optiboot for ATmega328P does not fit into 512B. It is 525B now.
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 06, 2016, 09:12 am
First partial success or nearly full success! Going throughout the ASM code I realised that the main harms are caused by optimizing the watchdogConfig(). So the attribute noinline produces smaller code, now it's 708B which is very close to 706B, but for the UNO it is 494B to previous 488B.
And as I see the original optiboot code on the GitHub it already has defined as noinline. :( :smiley-confuse: :) :D  8)
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Sep 06, 2016, 09:21 am
Quote
I've decided to move to the Atmel AVR Toolchain v3.5.3.1700 with avr-gcc v4.9.2.
 I see the optiboot for ATmega328P does not fit into 512B.
I'm using Atmel 3.5.2_444 (which is also gcc 4.9.2), and the stock optiboot for 328 compiles to 464 bytes.
Are you using the latest source from the github repository at https://github.com/Optiboot/optiboot (https://github.com/Optiboot/optiboot), the source from the IDE distribution, or something else?  (The change to -mrelax was made over two years ago.  The version distributed with the IDE hasn't been updated in forever, and isn't particularly expected to be updated...)

Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 06, 2016, 11:45 am
No, not latest source. I think, I started with 4.6 version and did several modifications. My version is probably little bit far from actual official optiboot. I missed the switch -mrelax because I'm using gcc 4.7.2 for the years, since Arduino IDE 1.0.6 was released. This version of IDE uses gcc 4.3.2 which was very old at this time. So, I replaced the whole AVR toolchain with gcc 4.7.2 to be same as Atmel Studio 6.1 has.
I don't want to critize the Arduino 1.6.x versions but the reason why I'm not using it is that there is a lot of bugs and the changes in SW don't offer me a benefit concerning to ATmega. I have modified core for my needs focused mainly to a size.
I know about the difference in size of UNO bootloader: official 464 vs mine 488. I cannot say why at now. I have a dozen genuine UNOs but never changed the bootloader and I would use original in case. Mainly I am interesting in 1284P. I have my own variant. My bootloader allows to upload into EEPROM and reads the fuses and lock etc. to utilize 1kB of boot space.

Here is a snippet for a fuses and lock.
Code: [Select]
/* STK500 Universal Command */
} else if(ch == STK_UNIVERSAL) { // universal command - fuse & lock bits
#if defined(BIGBOOT)
/* read fuse and lock bits; it takes additional 80 bytes */
uint8_t ucb1 = getch(); // universal command byte 1
uint8_t ucb2 = getch(); // universal command byte 2
getNch(2); // discard universal command byte 3-4
uint8_t ucr  = 0; // response

/* mapping algorithm for function parameter, optimized to save a space:
ucb1(0x50), ucb2(0x00) -> GET_LOW_FUSE_BITS     (0x0000)
ucb1(0x58), ucb2(0x00) -> GET_LOCK_BITS         (0x0001)
ucb1(0x50), ucb2(0x08) -> GET_EXTENDED_FUSE_BITS(0x0002)
ucb1(0x58), ucb2(0x08) -> GET_HIGH_FUSE_BITS    (0x0003)
*/
if((ucb1 & ~(0x08)) == 0x50 && (ucb2 & ~(0x08)) == 0x00) {
ucb1  = ((ucb1 & 0x08) ? 1 : 0) | (ucb2 >> 2);
ucr   = boot_lock_fuse_bits_get((uint16_t)ucb1);
}
putch(ucr);
#else // universal command is ignored
getNch(4); // 4 bytes of data/command
putch(0x00); // response
#endif


It should produce this:
Code: [Select]

/* STK500 Universal Command */
} else if(ch == STK_UNIVERSAL) { // universal command - fuse & lock bits
   1fcb8: 86 35       cpi r24, 0x56 ; 86
   1fcba: d1 f4       brne .+52     ; 0x1fcf0 <main+0xf0>
#if defined(BIGBOOT)
/* read fuse and lock bits; it takes additional 82 bytes */
uint8_t ucb1 = getch(); // universal command byte 1
   1fcbc: c5 d0       rcall .+394     ; 0x1fe48 <getch>
   1fcbe: c8 2e       mov r12, r24
uint8_t ucb2 = getch(); // universal command byte 2
   1fcc0: c3 d0       rcall .+390     ; 0x1fe48 <getch>
   1fcc2: d8 2e       mov r13, r24
getNch(2); // discard universal command byte 3-4
   1fcc4: 82 e0       ldi r24, 0x02 ; 2
   1fcc6: da d0       rcall .+436     ; 0x1fe7c <getNch>
ucb1(0x50), ucb2(0x00) -> GET_LOW_FUSE_BITS     (0x0000)
ucb1(0x58), ucb2(0x00) -> GET_LOCK_BITS         (0x0001)
ucb1(0x50), ucb2(0x08) -> GET_EXTENDED_FUSE_BITS(0x0002)
ucb1(0x58), ucb2(0x08) -> GET_HIGH_FUSE_BITS    (0x0003)
*/
if((ucb1 & ~(0x08)) == 0x50 && (ucb2 & ~(0x08)) == 0x00) {
   1fcc8: 8c 2d       mov r24, r12
   1fcca: 87 7f       andi r24, 0xF7 ; 247
   1fccc: 80 35       cpi r24, 0x50 ; 80
   1fcce: 71 f4       brne .+28     ; 0x1fcec <main+0xec>
   1fcd0: 8d 2d       mov r24, r13
   1fcd2: 87 7f       andi r24, 0xF7 ; 247
   1fcd4: 59 f4       brne .+22     ; 0x1fcec <main+0xec>
ucb1  = ((ucb1 & 0x08) ? 1 : 0) | (ucb2 >> 2);
   1fcd6: c3 fa       bst r12, 3
   1fcd8: ee 27       eor r30, r30
   1fcda: e0 f9       bld r30, 0
   1fcdc: d6 94       lsr r13
   1fcde: d6 94       lsr r13
   1fce0: ed 29       or r30, r13
ucr   = boot_lock_fuse_bits_get((uint16_t)ucb1);
   1fce2: f0 e0       ldi r31, 0x00 ; 0
   1fce4: 40 92 57 00 sts 0x0057, r4
   1fce8: 84 91       lpm r24, Z
   1fcea: cd cf       rjmp .-102     ; 0x1fc86 <main+0x86>
#if defined(BIGBOOT)
/* read fuse and lock bits; it takes additional 82 bytes */
uint8_t ucb1 = getch(); // universal command byte 1
uint8_t ucb2 = getch(); // universal command byte 2
getNch(2); // discard universal command byte 3-4
uint8_t ucr  = 0; // response
   1fcec: 80 e0       ldi r24, 0x00 ; 0
   1fcee: cb cf       rjmp .-106     ; 0x1fc86 <main+0x86>
getNch(4); // 4 bytes of data/command
putch(0x00); // response
#endif

 Feel free to use it.

Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 06, 2016, 11:55 am
...forgot to mention the boot_lock_fuse_bits_get() have to be used the original one from avr/boot.h.

Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Sep 06, 2016, 10:38 pm
Quote
My version is probably little bit far from actual official optiboot.
Keeping the optiboot code base "up-to-date" with respect to various avr-gcc "improvements" has been a pretty constant battle.  You might look at https://github.com/Optiboot/optiboot/issues/101 (https://github.com/Optiboot/optiboot/issues/101) in particular
Also, the support for overlapping serial com with page erase (NRWWSTART/etc) was removed after measurements showed it to not be very useful, and that saved a relatively large amount of space.  https://github.com/Optiboot/optiboot/commit/6c06686902a04e4d4defe73a2f2981b299373844 (https://github.com/Optiboot/optiboot/commit/6c06686902a04e4d4defe73a2f2981b299373844)
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 07, 2016, 09:53 am
Quote
My version is probably little bit far from actual official optiboot.
Just to clarify, I don't want to say my is better but it differs. I know it is hard work to keep the code up to date.
You have a K+ from me for that.

I remember, I'd read this https://github.com/Optiboot/optiboot/commit/6c06686902a04e4d4defe73a2f2981b299373844 but I was not paying attention to it up to now. Thank you.
Yes, it save the space. As I know, optiboot for UNO did not use it to fit into 512B.



Title: Re: NEWER New Optiboot bootloader
Post by: scrumfled on Sep 14, 2016, 01:22 pm
Silly question alert...

I've just grabbed a 1284 with optiboot on it, which seems to have a somewhat messy pin layout. I understand this is mapped from the base AVR ports (probably wrong terminology).

Anyway, Im trying to understand where things like the external interrupts are mapped, is this anything I could read myself to see where they are(eg from a config file somewhere)?

PS. pinout from top left:

D4--------A7/D21
D5--------A6/D20
D2--------A5/D19
D3--------A4/D18
D10-------A3/D17
D11-------A2/D16
D12-------A1/D15
D13-------A0/D14
RST--------Aref
Vcc--------GND
GND-------AVcc
XTAL2-----D29
XTAL1-----D28
D0/Rx0----D27
D1/Tx0----D26
D6/Rx1----D25
D7/Tx1----D24
D30-------D23
D8--------D22
D9--------D31
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Sep 16, 2016, 08:56 am
ATmega pins have several functions and they are hardwired to ATmega's pins. The external interrupts are alternative functions of I/O. The datasheet of ATmega describes the mapping. If you have known pin mapping to Arduino it is not a problem to find out where the ext. interrupt is. For an example: INT0 is on the PD2 of ATmega1284P (pin 16 on DIL package) . There are also RXD1 and PCINT26 functionality and according your map it is D6 on Arduino.
Title: Re: NEWER New Optiboot bootloader
Post by: RodSchmidt on Sep 22, 2016, 08:10 am
I've had a mega2560 for a couple of years and reverse engineered an avrdude subset to upload sketches to it as part of a larger software project. It used stk500v2 programming. Just got a new UNO R3, which programs fine with Arduino 1.6.9. IT uses stk500/optiboot programming sequences. But my old uploader also sort of works, and there is no code in optiboot to recognize v2 sequences! I've added timing measurement to my own v2 uploader, and the first  packet (v2 logon) doesn't get picked up for about 100 ms. Then it loads fine, but every 8 packets (1024 bytes) there is a 6 sec delay before the next packet is accepted.

One of my goals in this is to be able to power on/off the board while debugging hardware w/o having to deal with the IDE and its concept of serial ports (moving USB target on Linux)..My own uploader pokes around and finds the new /dev/ttyACMx port without my intervention. So 2 issues:

1) why does my loader work at all? The IDE generates 2 hex files, one with bootloader(?) and one without. This is new - could the "bootloader" stuck in the sketch be a v2 loader that runs as an application after a timeout???  Or what?

2) I'm prepared to add stk500 (v1) code to my uploader - it's simpler than the v2. But is there a way to detect WHICH format to send - without the tables of magic numbers for each board/mcu/etc that seems to be how the current software is designed.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Sep 22, 2016, 11:59 am
If there's a 6-second delay, that almost certainly means that the Uno is resetting and starting over.  What makes you think that it's "working" ?   Have you uploaded and successfully run a sketch larger than 1024 bytes?  (IMO, it SHOULDN'T work at all.  v2 wraps everything into "packets" so that the receiver can check CRC/etc.  v1 doesn't understand those...)

I think v2 sends a startup string at poweron, while v1 is quiet until the PC sends it commands...
Title: Re: NEWER New Optiboot bootloader
Post by: janmiddelink on Mar 22, 2017, 10:07 pm
I am trying to load the optiboot bootloader to a arduino nano. when building the project with AtmelStudio 7
it reports:

Error      recipe for target 'baudcheck' failed   xplained328pb   C:\Users\Jan\Documents\Arduino\optiboot-master\optiboot\AtmelStudio\Makefile   519

Any idea how to correct this ?
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Mar 22, 2017, 11:16 pm
Ignore it.   The baudcheck feature needs BASH, which probably isn't on your as7 system.
It would be clearer without as7 in there...
Title: Re: NEWER New Optiboot bootloader
Post by: zvipesh on Apr 14, 2017, 10:50 am
I am in urgent need for a proven bootloader files for two uP
The uP are working on 12MHz clock - !!!

1) ATmega 2560AU

2) ATmega 1284P

I need these files to be uploaded via ICSP connectors on a custom board.


help will be greatly appreciated.
Title: Re: NEWER New Optiboot bootloader
Post by: subhajitdas298 on May 01, 2017, 07:21 am
Please someone give me compiled bootloader for Atmega8A-PU (16MHz external clock), which I can upload directly.
Title: Re: NEWER New Optiboot bootloader
Post by: pert on May 01, 2017, 09:59 am
Please someone give me compiled bootloader for Atmega8A-PU (16MHz external clock), which I can upload directly.
https://github.com/MCUdude/MiniCore (https://github.com/MCUdude/MiniCore)
Title: Re: NEWER New Optiboot bootloader
Post by: BodyGearable on May 14, 2017, 08:47 pm
Nice post, really its helpfull
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Jun 15, 2017, 12:33 pm
Stack Pointer init value

I tested something with Atmel Studio 6.1. I realized that the SP in debugging is set to 4101h (ATmega1284P) at start with no prologue code like the optiboot has - without .initN sections.
The optiboot says that it is done by hardware reset (SP = RAMEND) except of ATmega8,16,32. However for the ATmega1284P, the RAMEND is 40FFh, not 4101h.
* Is it bug in AS6.1?
* How about real MCU, is it true that hardware reset initialize the SP to 40FFh? I cannot find info in the datasheet.
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Jun 16, 2017, 09:53 am
Interesting finding about SP.
The bootloader starts with this:
Code: [Select]
Disassembly of section .text:
0001fc00 <main>:
int main(void)
{
   1fc00: 00 d0       rcall .+0       ; 0x1fc02 <main+0x2>
   1fc02: 1f 92       push r1
   1fc04: cd b7       in r28, 0x3d ; 61
   1fc06: de b7       in r29, 0x3e ; 62
   ...

The first command executed is RCALL (jump to the next instruction). It decrements SP about 2 and even the SP is 0x4101
at start, after the first instruction it has a value 0x40FF - RAMEND of ATmega1284P.
:)
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 16, 2017, 10:53 am
Quote
I realized that the SP in debugging is set to 4101h
Really?  The datasheet I have says pretty clearly that it should be initialized by hardwre to 0x40FF.  Section 7.5.1: "SPH and SPL - Stack Pointer High and Stack pointer Low"   I dunno what debugging is doing...


Quote
The first command executed is RCALL (jump to the next instruction).
This is the compiler setting up a stack frame to briefly save one of the local variables (when it could easily have saved it in other ways.)  the "call .+0" is equivalent to the "sub sp, #stackFrameSize" you'd probably see on an ARM, but it's much smaller on the AVR (where SP is off in IO address space, instead of being a register, and can't easily have arithmetic on it.)

This is actually regarded as a bug in optiboot (https://github.com/Optiboot/optiboot/issues/160) although perhaps it would be more reasonably considered a compiler bug - it showed up in avr-gcc 4.8, got worse in 4.9, and has disappeared in the latest release from Atmel (5.4?)

Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Jun 16, 2017, 11:52 am
Quote
Section 7.5.1: "SPH and SPL - Stack Pointer High and Stack pointer Low"   I dunno what debugging is doing...
My eyes, I am blind... :o  Now, I remember I had read it years ago. Sometimes happen to me it is hard to remember things after some time.

I am accustomed that AS has exact behaviour as real MCU. Yesterday, I had no HW available, I want test it today.

Thank you WestfW for an explanation. I used avr-gcc 4.7.2 for years and now I'm using 4.9.2 long time.
As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
GCC: 4.9.2
binutils: 2.26.20160125
avr-libc: "2.0.0"
gdb: 7.8
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Jun 16, 2017, 01:48 pm
I tested it. SP is initialized with 0x40FF on real ATmega1284P. AtmelStudio has some bug.
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on Jun 16, 2017, 09:58 pm
Quote
As I see on Atmel web, there is 3.5.4 latest toolchain and still it uses avr-gcc 4.9.2.
You wrote avr-gcc (AVR_8_bit_GNU_Toolchain_3.6.0_487) 5.4.0. Where is?
I was a bit surprised at the jump from 4.9 to 5.4 as well.
huh.  The latest Atmel Studio 7 includes the new toolchain (http://studio.download.atmel.com/7.0.1417/as-installer-7.0.1417-readme.pdf) (3.6.0.1734):
Quote
Atmel Studio 7.0.1416
The following changes are done in Atmel Studio 7.0.1416:
  • Changed driver to WinUSB for AVR DragonTM, AVRISP mkII, JTAGICE mkII, JTAGICE3, AVR ONE!, STKĀ®600, and QT600
     :
  • Installer improvements
  • Improved support for installing older device family packs
  • AVR 8-bit GCC Toolchain 3.6.0 with upstream versions:
    • -  gcc 5.4.0
    • -  Binutils 2.26.20160125
    • -  avr-libc 2.0.0
    • -  gdb 7.8
And I was able to download the macos version 3.6.0.487 binaries from what I guess is Atmel's Source code distribution site (http://distribute.atmel.no/tools/opensource/Atmel-AVR-GNU-Toolchain/), but I don't see the windows or linux "toolchain" downloads for 3.6.0 in the usual places...
Title: Re: NEWER New Optiboot bootloader
Post by: Budvar10 on Jun 19, 2017, 08:06 am
Hm, it looks like MAC is little bit ahead. Win & Lnx still refer to older toolchain. I've downloaded AS 7.0.1417 a week ago but have no time to use yet.
Title: Re: NEWER New Optiboot bootloader
Post by: kkchandi on May 09, 2018, 10:27 pm
good luck!
Title: Re: NEWER New Optiboot bootloader
Post by: GoForSmoke on Jan 27, 2019, 09:34 am
I guess that I'll find out what's stable over on Github.
Title: Re: NEWER New Optiboot bootloader
Post by: alexblade on May 30, 2019, 02:35 pm
hi
is *A-PU supported by optiboot?
Title: Re: NEWER New Optiboot bootloader
Post by: westfw on May 31, 2019, 09:24 am
Quote
is *A-PU supported by optiboot?
"Probably."
If you're asking about the "A" versions (atmega168-PU vs atmega168a-PU), those are normally indistinguishable (same behavior, same signature, etc - the bootloader and Arduino core SW can't even tell.)  (Alas, not true of many "B" versions ("Atmel, you fool!"))
If you're asking about the part after the dash, that usually indicates package type, and the software doesn't care...