I'm writing an app to run on a host MCU that allows it to flash a client MCU with a firmware update using optiboot.
I hooked up a logic analyzer to my UART to see what AVRdude outputs when programming an Arduino running optiboot. I then compared the UART transmissions against the STK500 protocol and against the hex file itself.
I have come upon a paradox and would like to reconcile it for my own peace of mind so I don't wake up in a cold sweat dreaming of 0Xes.
The paradox is that the addresses that are being sent by avrdude via STK500 protocol make sense according to the spec, however the addresses in the hex file appear to be out of spec.
Spec for the STK500 (from AVR061) says about the STK_LOAD_ADDRESS command:
Spec for Intel hex format (from Wikipedia page ) says:
Now, when I take a peek at the STK500 UART bytes I sniff with the logic analyzer, things appear to make sense: 16-bit address is set to 0x0080 (128) after first 256 bytes of flash have been written. 128= 256 bytes ÷ 2 bytes/address so all is right with the world.
However, when I look at the .hex file, I see the following:
So, it appears that the address in the hex file is 8-bit-byte-oriented address, because those were the 256th- 271st bytes that were flashed
Does that mean that the hex file that avr-gcc produces violates the intel hex specification? Shouldn't the address be encoded as 128?
Alternatively, are the two datasheets using the term "16-bit address" in different senses? I'm thinking that perhaps by "16-bit address", the STK-500 datasheet means "16-bit word address" whereas the intel hex specification is simply referring to the byte address and uses a 16-bit integer to represent it.