Bootloader address 0x0000 JMP instruction

Hello,

This is probably a stupid question, but when I look at the intel hex dumps of the compiled bootloaders, I was expecting to see a JMP instruction at address 0x0000. I see the following in optiboot:

":0400000300007E007B"

0x0000:0000 = NOP instruction

And this in ADAboot328:

":040000030000780081"

0x0000:0000 = NOP instruction

The bytes following the NOP do appear to be the starting code address.

A JMP opcode would have been 940C, how come this instruction is not in address location 0x0000?

Thanks, just trying to understand.

There is no instruction at location 0x0000 in the bootloader of an AVR - the BOOTRST fuse, when set, causes the processor to jump to the start of the bootloader (as defined by the BOOTSZ fuses) instead of 0x0000 when powered on, and then the bootloader jumps to 0x0000 to start the application.

You are misreading that line - it's a record of type 03, "Start segment address", not type 00 (data). I don't know what function, if any, that has on an AVR microcontroller (on some platforms, it's used to specify where program execution starts from - notice how the address there points to the start of the bootloader)

When burned to a virgin chip, if you then read it back, you see nothing (all 1's, ie, freshly erased) from 0x0000 to the start of the bootloader.

:0400000300007E007B

:04 0000 03 0000 7E00 7B byte count 4 address 0 (ignored) record type 3 (segment start address) data (segment:offset) 0:7e00 checksum 7B

Informational; not an instruction at all, or even something that ends up in the Flash memory. https://en.wikipedia.org/wiki/Intel_HEX

We now have the opportunity to share/review our understandings on Intel-hex Formatted File.

  1. Intel-hex formatted file indeed is a transmission file. It is made out of the object file for onward transmission of the 'Binary Codes/Data' of the application program into the target controller.

  2. The digits (every 4-bit) of the Source Object file are converted into ASCII codes which are included in the Intel-hex file. The Intel-hex file contains few pre-amble and post-amble bytes to make a successful transmission session.

  3. An Intel-hex file is composed of many frames. A frame is composed of many fields. The names and meanings of the fields of an Intel-hex frame:

   :042000008B477F482
   :       04    2000   00     8B 47 7F F4      82       ; mov    ax, WORD PTR ds:[bx+7Fh; hlt (8086)
   (a)    (b)   (c)      (d)    (e)                  (f)

   Field-(a) - Start Code: It indicates the beginning of the transmission of a frame. The receiver looks 
                  for this character in order to synchronise with the transmitter.

   Field-(b) - Byte Count: In indicates the number of data bytes contained in Filed-(e).
  
   Field-(c) - Address: In indicates the address of the memory location (for Real Mode 80x86 it is a 
                 byte organised RAM location with physical address 0000:20000) into which the 
                 1[sup]st[/sup] data byte (8B) will be stored.

                 For AVR, the interpretation is a bit different:
                 If the given frame would belong to an AVR, the value 2000 would be divided by two
                 by the receiver to get the address (1000) of the memory location of the word organised
                 flash into which the 16-bit data (478B not 8B47) would be stored. 

   Field-(d)- Record Type: It indicates, when 00, transmission of normal data bytes. There are still 
                frames to transmit. If the Record Type is found as 01, the receiver understands that
                there is the end of transmission session. 

   Field-(e) - Data: This field contains actual data.

   Filed-(f) - CHKSUM: All the bytes of the frame are added except Field-(a). The carry is discarded.
                 Two's compliment of the remaining byte is formed; it is transmitted as the last byte
                 of the frame. It can be used check the validity of the received frame and instruct the
                 transmitter to re-send the frame, if required.
  1. Let us now analyse the Intel-hex frame submitted by drdavros

:0400000300007E007B

: 04 0000 03 00007E00 7B

(a) Because Fuse Settings (EF = 0x05, HF=0xDE, LF=0xFF) of ATmega328 of ArduinoUNO, the control begins at location 0x3F00 of the Flash Memory. The Boot Loader program had been pre-stored starting from this location. The Boot Loader writes the incoming code/data into the application flash (0x0000 - 0x0040; 0x0041 - 0x3EFF).

(b) As westfw has indicated, this frame is ignored due to 'non-data' record field. There is evvidence in favor of it:

         .include 'mdef32.inc"            ; List Codes

         .org       0x0000                   
         rjmp      0x0040                   ; 0000 - C03E

          .org      0x0040                   ; 
          ldi        r17, 0x5F                ; 0040 - E51F
         ;----------------------
         :02 0000 02 0000 FC             ; Receiver either ignores it or it is over-written by the next frame 
         :02 0000 00 3FC0 FF              ; My receiver always checks if it is 00 or 01.
         
         :02 0080 00 1F E5 7A

(c) drdavros is being requested to post the next frame of the optiboot in order to enable us to see what information is there.

  1. Thanks to drdavros for the very uncommon but very interesting post.