Pages: [1]   Go Down
Author Topic: Bootloader source versus hex discrepancy  (Read 623 times)
0 Members and 1 Guest are viewing this topic.
Underhill Center, Vermont, USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 71
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

On my MacBook Pro (under OS X 10.4.10) I went to the "bootloader168" subdirectory of 0009 and made a subdirectory called "temphold" and moved  the delivered NG and Diecimilia hex files there. I then opened a Terminal window to get a command line and CD-ed to that directory and typed "make ng" ... I used arduino-0009 to burn the resulting hexfile to a chip and used that chip to load a sketch, it all works fine ... butttttt ... I noticed a  16 byte discrepancy between  the produced (5181 bytes)  and the delivered (5165 bytes) hexfiles, so I did a file compare on the two hexfiles and beginning in line 8 there is some significant differences on  the hexfiles.

What gives?
 

Quote
Golem:/Applications/arduino-0009/bootloader168 brian$ make ng
avr-gcc -g -Wall -O2 -mmcu=atmega168 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=F_CPU>>1' '-DNUM_LED_FLASHES=3'   -c -o ATmegaBOOT_168.o ATmegaBOOT_168.c
avr-gcc -g -Wall -O2 -mmcu=atmega168 -DF_CPU=16000000L  '-DMAX_TIME_COUNT=F_CPU>>1' '-DNUM_LED_FLASHES=3' -Wl,--section-start=.text=0x3800 -o ATmegaBOOT_168_ng.elf ATmegaBOOT_168.o
avr-objcopy -j .text -j .data -O ihex ATmegaBOOT_168_ng.elf ATmegaBOOT_168_ng.hex
rm ATmegaBOOT_168_ng.elf ATmegaBOOT_168.o
Golem:/Applications/arduino-0009/bootloader168 brian$ ls -l
total 80
-rwxr-xr-x   1 brian  staff  27114 Aug  6 18:20 ATmegaBOOT_168.c
-rw-r--r--   1 brian  staff   5181 Aug 20 10:16 ATmegaBOOT_168_ng.hex
-rwxr-xr-x   1 brian  staff   2404 Aug 20 10:15 Makefile
drwxr-xr-x   4 brian  staff    136 Aug 20 10:09 temphold
Golem:/Applications/arduino-0009/bootloader168 brian$ cd temphold
Golem:/Applications/arduino-0009/bootloader168/temphold brian$ ls -l
total 32
-rw-r--r--   1 brian  staff  5165 Aug  6 18:20 ATmegaBOOT_168_diecimila.hex
-rw-r--r--   1 brian  staff  5165 Aug  6 18:20 ATmegaBOOT_168_ng.hex
Golem:/Applications/arduino-0009/bootloader168/temphold brian$

« Last Edit: August 20, 2007, 04:36:39 pm by brianbr » Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Maybe you've got a different version of avr-gcc than I do?  I'm not sure which one I used to build them, to honest.
Logged

Underhill Center, Vermont, USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 71
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
Maybe you've got a different version of avr-gcc than I do?  I'm not sure which one I used to build them, to honest.


 well I would assume, and I haven't looked at the  makefile in any detail, that your makefile invoked  the version of gcc that is in the arduino-0009 suite ....

 cheers ... BBR
Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

I wasn't that clever actually - it just grabs whichever one happens to be in your path (which doesn't include the one that comes with Arduino unless you've added it yourself).
Logged

Underhill Center, Vermont, USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 71
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
I wasn't that clever actually - it just grabs whichever one happens to be in your path (which doesn't include the one that comes with Arduino unless you've added it yourself).

OK ... I have the OSXAVR suite installed in /usr/local/bin and that is 4.1.1 .... the resultant bootloader seems quite viable ... so I guess its just a matter of academic  trivia at this point ... but for the sake of argument is there something I can do to shake down or 'proof' the bootloader beyond what I have already done.

 ... and once again, thanks Dave for all your efforts ....

 .... errrrr ... one thing ... the bootloader source code is a lttle hard to follow with all the conditionals can you give me a rough idea where to find the code that controls the length of the bootloader wait before it times out and executes.

   cheers ... BBR
Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

No problem.  The length of the bootloader wait is set by the MAX_TIME_COUNT constant which is defined in the Makefile (in the ng: or diecimila: targets).  In both cases it's based on the F_CPU constant that corresponds to the clock speed of the microcontroller (16 MHz in the case of Arduino).  The code that uses the MAX_TIME_COUNT constant is the getch() function, which waits for character input from the computer.  If it doesn't receive a character in the right amount of time, it calls app_start() which jumps to the beginning of the sketch on the chip.  There's also a "timeout" after receiving a certain number of errors, or data that doesn't fit the bootloader protocol (stk500).  The error count is incremented anywhere the bootloader receives a byte that doesn't conform to the protocol.
Logged

Underhill Center, Vermont, USA
Offline Offline
Jr. Member
**
Karma: 0
Posts: 71
Arduino rocks
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Quote
No problem.  The length of the bootloader wait is set by the MAX_TIME_COUNT constant which is defined in the Makefile (in the ng: or diecimila: targets).  In both cases it's based on the F_CPU constant that corresponds to the clock speed of the microcontroller (16 MHz in the case of Arduino).  The code that uses the MAX_TIME_COUNT constant is the getch() function, which waits for character input from the computer.  If it doesn't receive a character in the right amount of time, it calls app_start() which jumps to the beginning of the sketch on the chip.  There's also a "timeout" after receiving a certain number of errors, or data that doesn't fit the bootloader protocol (stk500).  The error count is incremented anywhere the bootloader receives a byte that doesn't conform to the protocol.

 So, if I understand correctly, and don't want to get too involved, I take the statetment

   F_CPU>>1

and vary the ">>1" so I have the option of altering it by powers of  2, so

  F_CPU>>0  - doubles the timeout

  F_CPU>>2  - cuts the timeout in half

 and so on ... I did actually try it and it does indeed seem to work that way, I used

  F_CPU>>3 - and the timeout did seem to be about a quarter of what it had been


 ... once again, thanks ... cheers ... BBR


Logged

Forum Administrator
Cambridge, MA
Offline Offline
Faraday Member
*****
Karma: 9
Posts: 3538
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

Exactly.  If you more more precise control, you can just divide F_CPU instead of shifting it.
Logged

Pages: [1]   Go Up
Jump to: