Does it work on the Atmega1284 (non-P) as well ?
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.
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)...
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:
make atmega1284 AVR_FREQ=12000000
CircuitSerialKiller:
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:
C:\Program Files\Arduino\hardware\arduino\avr\bootloaders\optiboot>
I issue:
omake Makefile.2560
to which windows responds:
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:
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.
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
t.txt (15.1 KB)
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 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.
westfw: The arduino team has removed "make" from the arduino tools distribution. :-( 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.
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.
Hmm. You're right. Let me check...
(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.)
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
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.
Thanks. That makes perfect sense.
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
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 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
Thank you Bill,
So the current (latest?) versions at: https://github.com/Optiboot/optiboot are v6.6?
Regards, Martin
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.
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
optiboot_atmega328.hex is ascii file in intel hex format :-) Look inside:
:027FFE00020679
last two bytes of data are 02 06 just like Bill said.
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
:027FFE00[color=red]0206[/color]79
: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 [color=red]0206[/color] ..
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?
westfw: ```
avr-objdump -march=avr -s optiboot_atmega328.hex optiboot_atmega328.hex: file format ihex [color=blue]Contents of section .sec1:[/color] 7e00 1f92cdb7 deb71124 84b714be 982f9d70 .......$...../.p : 7fc0 f1cf282e 80e0e8df e0e0ff27 0994 ..(........'.. [color=blue]Contents of section .sec2:[/color] 7ffe [color=red]0206[/color] .. ```
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
mprowe: 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.