Hex file addresses different than STK500 addresses

Log in or register to post comments
Go To Last Post
6 posts / 0 new
Author
Message
jaza_tom
jaza_tom's picture
Level: Wannabe
Joined: Fri. Jun 1, 2018
Posts: 67 View posts
#1
Posted by jaza_tom: Tue. Sep 25, 2018 - 11:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey all,

 

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.

 

Hrm... cheeky

 

 

 

This topic has a solution.

I love the smell of burning silicon in the morning

Tags:

Tools, Compilers and General Programming, solved
Last Edited: Wed. Sep 26, 2018 - 01:50 AM
Top
Bronze Marktheusch
theusch's picture
Level: 10k+ Postman
Joined: Mon. Feb 19, 2001
Posts: 39865 View posts
Location: Wisconsin USA
Posted by theusch: Tue. Sep 25, 2018 - 11:32 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaza_tom wrote:
So, it appears that the address in the hex file is an 8-bit address,

???  Explain that.  Do you mean only 8 bits of address, or that 8-bit octets, bytes, are being counted?

jaza_tom wrote:
because those were the 256th- 271st bits that were flashed

Then explain what you mean by "bits" in there...

 

jaza_tom wrote:
Does that mean that the hex file that avr-gcc produces violates the intel hex specification?

So if you give me a sample source and I feed it to CodeVisionAVR and get a similar corresponding .HEX file, that CV "violates" as well?  And repeat with ImageCraft and IAR?  And they are all in violation?  Sounds like a conspiracy.

 

BTW, isn't your project well solved as an Arduino sketch?  Dunno; I thought it has been mentioned here.

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Top
El Tangas
El Tangas's picture
Level: Raving Lunatic
Joined: Thu. Jul 14, 2016
Posts: 3166 View posts
Posted by El Tangas: Tue. Sep 25, 2018 - 11:38 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jaza_tom wrote:
I hooked up a logic analyzer to my UART to see what AVRdude outputs when programming an Arduino running optiboot.

 

You don't have to, you know? Avrdude will report the data it transmits and receives at verbose level 4 (option -v -v -v -v). I think it's sent to stderr.

Last Edited: Tue. Sep 25, 2018 - 11:39 PM
Top
skeeve
skeeve's picture
Level: Raving Lunatic
Joined: Sun. Oct 29, 2006
Posts: 5291 View posts
Posted by skeeve: Wed. Sep 26, 2018 - 12:02 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

El Tangas wrote:
You don't have to, you know? Avrdude will report the data it transmits and receives at verbose level 4 (option -v -v -v -v). I think it's sent to stderr.
Fascinating.  I've never used more than two.

I wonder what one gets for five.

Iluvatar is the better part of Valar.

Last Edited: Wed. Sep 26, 2018 - 12:40 AM
Top
jaza_tom
jaza_tom's picture
Level: Wannabe
Joined: Fri. Jun 1, 2018
Posts: 67 View posts
Posted by jaza_tom: Wed. Sep 26, 2018 - 12:09 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:
jaza_tom wrote: So, it appears that the address in the hex file is an 8-bit address, ???  Explain that.  Do you mean only 8 bits of address, or that 8-bit octets, bytes, are being counted? jaza_tom wrote: because those were the 256th- 271st bits that were flashed Then explain what you mean by "bits" in there...

 

 

I have corrected my typos.

 

I think likely there is simply deficient wording in the STK500 app note, and when they say "16-bit address"  they really mean "16-bit integer that represents the word address"

 

This is making more sense to me now that I look at this table from the ATmega328PB, which is rife with references to "words" in the flash section.

 

 

 

El Tangas wrote:
jaza_tom wrote: I hooked up a logic analyzer to my UART to see what AVRdude outputs when programming an Arduino running optiboot.   You don't have to, you know? Avrdude will report the data it transmits and receives at verbose level 4 (option -v -v -v -v). I think it's sent to stderr.

 

Ah, cool.  Logic analyzer is more convenient in my case (only takes about 20 seconds to get the whole transaction into Excel) and it allows me to simply click "Upload" in Arduino IDE to see what and Arduino build with avrdude config file spits out over UART.

 

I love the smell of burning silicon in the morning

Top
westfw
westfw's picture
Level: Raving Lunatic
Joined: Wed. Jun 19, 2002
Posts: 4556 View posts
Location: SF Bay area
This reply has been marked as the solution. 
Posted by westfw: Wed. Sep 26, 2018 - 01:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think likely there is simply deficient wording in the STK500 app note, and when they say "16-bit address"  they really mean "16-bit integer that represents the word address"

 

Yes, and Atmel never reminds you that nearly all of their documentation uses "word addresses" , because that's their internal convention.

Except for LPM, all of the instructions that reference flash addresses (branch, jmp, rjmp, ijmp, call, rcall, icall) use word addresses (ijmp/icall are particularly "fraught"; it means that a C-style "pointer to function" points to a word, while a "pointer to data in flash" points to a byte.)

 

"Intel Hex format", on the other hand, dates back to the 8080 and is thus thoroughly byte-based.

 

Top