Go Down

Topic: NEWER New Optiboot bootloader (Read 50380 times) previous topic - next topic

westfw

Hmm.  You're right.  Let me check...

westfw

(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.)

Khuffman35

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

westfw

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.

Khuffman35

Thanks.  That makes perfect sense.

mprowe

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

westfw

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 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


mprowe

Thank you Bill,

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

Regards, Martin

westfw

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.


mprowe

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

majek

#40
Nov 21, 2015, 11:56 pm Last Edit: Nov 21, 2015, 11:57 pm by majek
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.

westfw

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                                 ..             

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?

> 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

chucktodd

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.
Currently building mega http server 90% done, the Last 10% is killing me.

westfw

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.")


Go Up