Bootloader source versus hex discrepancy

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?

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$

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.

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

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

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

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.

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

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