AVR Freaks

Surely you mean 940C 0034 ? The byes in the 16bit opcode words may be little endian but the opcode and operand aren't swapped. That to me, without looking it up, looks like a JMP 0x0034 or in GCC parlance JMP 0x0068

Then I'll take your money. The 0x0034 is half of the JMP opcode and it's all part of the reset vector which precedes the interrupt vectors. Clearly this is on one of the >8K AVRs which have 4 bytes for the reset and each vector entry, rather than the small AVRs that have just 2 bytes and hence only room for RJMPs.

Anyone using GCC already has that - it's called avr-objcopy. It's more than happy to take any form of binary (including text) as input and either output as linkable ELF object or straight to Intel .hex

LOL--now you got me curious enough to participate in this snipe hunt.

CodeVision has a nice set of functional tools to manipulate .HEX/.BIN. Load, edit, save [as].

But I never thought about loading a text file before. I found I could indeed load a text file, edit, and save as .HEX.

Lee

No it doesn't - it writes them in program address order. Which rather answers your follow up question doesn't it?

The is the second time to day I've explained this but:

is really:

which says write as follows:

those bytes in flash will hold those values - without a doubt. However, when you apply power to an AVR it makes a 16bit opcode fetch which is little-endian. It therefore reads:

as 0x940C and passes it to the instruction decoder which identifies it as a JMP opcode. This further triggers logic to make it make a second fetch as part of this same opcode and this time it picks up:

which again it reads as little endian and therefore treats as WORD address 0x0034 (which is BYTE address 0x0068). So after reading the first 4 bytes in two 16bit chunks it has determined it has "JMP 0x0068" and sets PC to be that address. (really 0x0034 in fact - it's just GCC that interprets things byte wise to be common across all architectures).

So the bytes are programmed in exactly the order they appear in the .hex at increasing byte addresses but when the AVR core makes fetches (two bytes, 16bits at a time) it treats them as little endian using the lower addressed of the two bytes as the lower part of each 16bit fetch. So it's not when programming hex that little endianness comes into play - it's when the data/code is later fetched back from the flash that the endianness issue applies - hence my reply above - sorry if it was confusing.

Cliff

PS today's other, similar thread:

https://www.avrfreaks.net/index.p...
(Apr 27th traffic only)

 

Just to say that there are few better descriptions of Intel Hex in 2019 than our good old friend Wikipedia:

 

https://en.wikipedia.org/wiki/Intel_HEX

 

BTW note that Atmel's AS7 (presumably inheriting this from MS VS2015 on which it is based) does a cracking job of displaying iHex too:

 

 

It does nice colour coding of each line so that the byte count, address, record type, data and checksum bytes are each shown in a different colour.

 

EDIT: actually I am quite wrong - the pretty display of iHex files in AS7 looks like an "Atmel only" feature. VS2017 shows the same .hex file rather boringly as:

 

 

which further highlights what a much better job AS7 does of displaying it.

 

(actually I'm beginning to wonder if I have an AS7 extension - maybe from Dean or Eivind - at work here)

Morten, apologies I thought was Dean and Eivind that did those "toys" not Dean and yourself. Sorry about wrong attribution.

 

Nice work by the way, I remember the first time I looked at a .hex file in AS7 and thought "hey, that's bloody clever stuff at work!!" :-)

Now you are going to make me deliberately corrupt a .hex file simply to see this in action !!

 

EDIT: OK so I didn't realise that Notepad++ also did this stuff:

 

 

and having corrupted it then AS7 follows suit:

 

 

Was this feature "borrowed" from Notepad++ by any chance? ;-)

What is "Record Type"?

pls Explain...

Thank you