convert hex to assembly code

Go To Last Post
67 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi

ive finally got my avr studio speaking to my stk500. i can write programs in assembly code and read programs from the chip but as a hex file.
can i convert the hex code to assembly language or can i extract the program from the chip as assembly language?

justint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Go into Studio4 and start debugging. Then go View --> Disassembler.

You can copy and paste this to a text file. You will need to edit out the dross by hand or by passing through a stream editor.

The normal procedure is to write a program in a high level language like C (or even Assembler). I do not care about the actual machine-code that runs on the AVR. Just that it works as I intended.

It is far harder to follow a program logic from examining disassembled output than it is to write the program yourself in the first place.

HTH David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

if i read the code from an unknown chip how will i know if the chip has bee locked by a fuse programmed into the chip?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the chip has been locked, you will not be able to read ANY code.

An unlocked chip can be read by your programmer and written as a hex file. You can load this hex file into Studio4. You will get no C or ASM source window. But you can read the disassembly window.

If you are trying to steal someone's private code, you may get a knock on the door from a very big person.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ha, not its not like that, its a chip for a unit that we sell in work, the man that programmed it no longer works here.

ive got the hex file from the chip but now when i erase the chip and re-write the program to the device it doesnt work, as i was doing before i reprogrammed it :(

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

you will not be able to read ANY code

The above statement might be true in one sense, but as I understand it the chip will return data on a readout even if the chip is locked. Only difference is that it will be meaningless "mumbo-jumbo". Correct?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is a hex file that i cannot make any sense of yes but i have taken the program from 2 chips and they seam to be identical, this gives me some confidence that they are not locked.
could there be any other reason that when i take a program from a working chip, erase the chip and reprogram with the original program it does not work?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I would hope that your company retained the source code for its own product, even if the programmer has left.

If it is your company product AND you have no source code, at least you should know what your product should do. And just write it all again from scratch.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

when i copy and paste the hex file into studio 4 it doesnt allow me to assemble it. giving an error for the 1st line in the hex file (:1000000000....).
should i have something entered in before this line to configure the program before it reaches the hex file?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I told you that you have to remove some dross first. Then it should assemble with Studio4 assembler.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
when i copy and paste the hex file into studio 4 it doesnt allow me to assemble it.

Of course it doesn't since it has already been assembled. You need to disassemble it.

Regards,
Steve A.

The Board helps those that help themselves.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

oh right, sorry, ive never done that. Can it be done in studio 4?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Justin,

Yes, I think that Steve has misunderstood you.

I have copy / pasted the disassembler window to a file. I then passed it through a sed script to remove the dross. And re-assembled it in Studio4.

However when you write assembly language, you use symbolic labels and generally know what you are doing. The Studio4 disassembler makes no attempt to create branching labels, or determine whether it has an opcode or some data.

So although you can re-create a source file. One edited line, and all the branches can go wrong.

I have no intention of running my labelling disassembler on an AVR binary.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok. i read the hex file from the chip and saved it with the name and a .a90 as follows programname.a90
i then opened that file, copied the hex text and pasted into the studio 4.
the debug option is grayed out and so is the view-->assembler option.
i dont know what a sed script is or a stream editor.
im sure its something simple that im doing wrong but im still stuck.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Have you not noticed that the disassembly output has several fields:

location_counter hex_bytes opcode operands comment

+00000005:   9701        SBIW    R24,0x01         Subtract immediate from word
+00000006:   F7F1        BRNE    PC-0x01          Branch if not equal
+00000007:   919F        POP     R25              Pop register from stack

You need to extract the source statements from columns 20-50 and insert a semicolon at column 51.
You will also note that you get PC+offset branches and not labels.

If you do not understand any of these terms you need to do lots of homework first.

Google for "sed Unix stream editor". However I am sure that you could process this file yourself.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

000000 C130 RJMP 0x262
000002 9518 RETI
000004 9518 RETI
000006 9518 RETI
000008 9518 RETI
00000A 9518 RETI
00000C 9518 RETI
00000E 9518 RETI
000010 9518 RETI
000012 9518 RETI
000014 9518 RETI
000016 9518 RETI
000018 9518 RETI
00001A 9518 RETI
00001C 9518 RETI
00001E 9518 RETI
000020 9518 RETI
000022 001A RETI
000024 00A0 RETI
000026 0386 FMULS R16,R22
000028 D15A RCALL 0x2DE
00002A E080 LDI R24,0x00
00002C E108 LDI R16,0x18
00002E BD01 OUT 0x21,R16
000030 E100 LDI R16,0x10

put the hex file into IAR and debugged, this gave me a disassembled file, the start of which is shown above.
is this along the correct lines?

are you saying that now i have to add parts to this program before it will assemble in studio 4?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

000000 C130 RJMP 0x262
000002 9518 RETI
000004 9518 RETI
000006 9518 RETI
000008 9518 RETI
00000A 9518 RETI
00000C 9518 RETI
00000E 9518 RETI
000010 9518 RETI
000012 9518 RETI
000014 9518 RETI
000016 9518 RETI
000018 9518 RETI
00001A 9518 RETI
00001C 9518 RETI
00001E 9518 RETI
000020 9518 RETI
000022 001A RETI
000024 00A0 RETI
000026 0386 FMULS R16,R22
000028 D15A RCALL 0x2DE
00002A E080 LDI R24,0x00
00002C E108 LDI R16,0x18
00002E BD01 OUT 0x21,R16
000030 E100 LDI R16,0x10

put the hex file into IAR and debugged, this gave me a disassembled file, the start of which is shown above.
is this along the correct lines?

are you saying that now i have to add parts to this program before it will assemble in studio 4?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

can you reccommend a good book that would help me do what i need?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

are you saying that now i have to add parts to this program before it will assemble in studio 4?

Well, you at least eed to remove parts. In particular the two first numbers on every line (address and contents in hex notation).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

There is a free dissasembler tool called ReAVR, part of ja-tools. It will dissasemble (several syntaxes: Atmel, GCC, IAR,...) the hex file showing labels and assigning names to constants, IO registers, etc. It makes easier to follow the program sequence. It's here: ReAVR - Disassembler for AVR

Best regards,

Carlos.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

there is also another one called DISAVR. Doesnt have a link at the moment, but Google should help.

Frank

Programmers never die
they just GOSUB without RETURN

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi, thanks for that it seems to be sending me in the correct direction.

Ive opened the Hex file for the Atmel AVR assembler using the above mentioned software, the 1st few lines are as follows:

; reassembly of "gg2_chip.a90.hex"
; created by ReAVR V3.2.0
; at 2008/04/21 - 10:15:34
; for Atmel AVR assembler
;---------------------------------------
; AVR_TYPE=
; FLASH_SIZE=8KB
; SRAM_START=0x60
;---------------------------------------
.cseg
.org 0x0000
;---------------------------------------
; byte constants:
;
.equ k00 = 0x00 ;
.equ k11 = 0x11 ;
.equ k33 = 0x33 ; '3'
.equ k44 = 0x44 ; 'D'
.equ k77 = 0x77 ; 'w'
.equ k88 = 0x88 ;
.equ k99 = 0x99 ;
.equ kCC = 0xCC ; 'Ì'
.equ kFF = 0xFF ; 'ÿ'
;
; io register addresses:
;
.equ p13 = 0x13
;
; pointer offsets:
;
.equ o01 = 0x01
.equ o03 = 0x03

wheni try to compile for programming the atmel chip there are over 100 errors.
What do i no need to do to make the program ready fro assembly?

the errors are all as follows:
C:\Documents and Settings\justin\Desktop\AVR Tests\Copy of AVR_8515\monday21st\monday21st.asm(6253): error: Relative branch out of reach

this error relates to this line of instruction:

rjmp L04AB
; ----------- jump on last line

i know im kinda jumping in at the deep end here but i do think im making progress.

justint

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well the error message is pretty self explanatory. The instruction is an RJMP. That is a relative jump and the offset can only be within 2K words (4K bytes) before/after the instruction. The error is telling you that the "L04AB" label that this rhmp is trying to reach is more than 4K away.

If this really is an 8515 then that is VERY odd because the 8K code space "wraps" (if you rjmp before 0x0000 you get back round to 0x1xxx and if you rjmp after 0x1FFF you get back round to 0x0xxx) so ALL destinations should be reachable in 8K bytes of code with an opcode than can jump 4K either way.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The chip im working with is an Atmega162. Thats where i took the program from and am not trying to reprogram to.
could it be something to do with the jump addresses that are set by the disassemble software i used above?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well if this is extracted code and the disassembler has spotted an RJMP but it's labelleing of the code has the destination of the RJMP out of range of that opcode then it suggests the disassembler is at fault.

Is it possible to say at what byte address the RJMP opcode was located and at what byte address the L04AB label is positioned at?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You really should follow some assembly language tutorials. Do you have any experience with other processors?

The purpose of assembly language is to add some sort of sense to a series of strange machine operations. A disassembler can re-create a source code that will re-assemble. You have to add human comments and generally re-name various symbols and labels.

You need considerably more skill and experience to understand this disassembly than to write your own source code in the first place.

With time, you will recognise sequences and manage to make some sense of the disassembly.

Your particular error:
error: Relative branch out of reach
simply means that the label L04AB is too far away for this opcode. In assembly you would use LJMP as an alternative instruction to the "rjmp L04AB"

However, you should find that you should have no errors at all. You have probably done some editing.

I have written disassemblers, and re-created code. Most often it would have been my own code, and I had mislaid the source. I could resurrect binaries but generally with a great deal of work. It really helps if you know the author's style.

So start at the beginning with tutorials. Then ask for help on this forum. But leave the disassembly alone until you are familiar with the language and instruction set.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff,

I would guess that the label "L04AB" has value 0x04AB.

Any data or ascii messages just gets disassembled as machine instructions. So the source can be complete garbage unless Justin has split the code into sections.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Justin,

If the code really has come out of the 162 you may benefit from loading mega162.reas_ior into ReAvr before you disassemble the code. You'll find it in C:\Program Files\ja tools\ReAVR\ior and you load it using Disas settings-IO Registers-[load list from file]

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks i loaded that list into the ReAVR, opened the hex file in the ReAVR (for Atmel AVR assembler), copied and pasted the text into Studio4 and tried to build/compile. Im still getting 48 errors relating to the jump relative branch being out of reach. Could this be to do with the settings for my availible memory or where the program starts. As far as i know there is 16K flash memory for the ATmega162 and cant see how it was working in the chip but now wont allow me to build for debugging/programming.
The headder of the program looks like this:

; reassembly of "gg_chip.a90.hex"
; created by ReAVR V3.2.0
; at 2008/04/23 - 08:50:09
; for Atmel AVR assembler
;---------------------------------------
; AVR_TYPE=ATmega162
; FLASH_SIZE=16KB
; SRAM_START=0x100
;---------------------------------------
.cseg
.org 0x0000
;---------------------------------------
; byte constants:
;
.equ k00 = 0x00 ;
.equ k11 = 0x11 ;
.equ k33 = 0x33 ; '3'
.equ k44 = 0x44 ; 'D'
.equ k77 = 0x77 ; 'w'
.equ k88 = 0x88 ;
.equ k99 = 0x99 ;
.equ kCC = 0xCC ; 'Ì'
.equ kFF = 0xFF ; 'ÿ'
;
; io register addresses:
;

Any ideas?

BTW i have orderd a book for beginners to help me from the beginning but im going to persevere with this until it arrives.

Regards

Justin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The disassembler clearly is not working if it's labelleing the target of RJMPs beyond the +/-4K reachable range.Maybe Try a different disassembler? (such as the one in AVR Studio)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

How do i do that?
Ive tried pasting the text into avr studio but it has greyed out the disassembler option in the view menu.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Load the .hex file into the Studio simulator and then you can cut/paste the text from the code view window but ulike a program such as ReAVR it won't identify code/data areas so any data in the image will appear as "odd" disassembled code.

As was said above, what you are attempting here is something that makes even dyed-in-the-wool programmers cringe. If you are just a beginner then trying to work a .hex file back to some useable Asm source is a REAL struggle!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Earlier in this thread, I loaded a hex file into Studio4. Viewed as disassembly, and copy-pasted into a file. Removed the dross, and used as source code back into Studio4. So this works.

Downloaded Re-Avr. Loaded a hex file. You have to sort out your program / data sections. Disassembled into a source file. Loaded into Studio4.

So it can be done. It is a nightmare to decipher code. I may not know AVR very well, but I am familiar with other ASM code. The thought of a beginner making any sense of this is beyond me. I had difficulties with resurrecting a small ASM program that I had written myself !!

As Cliff suggested, learn to write the program from scratch. It is a lot easier.

Justin, if you really want to pursue this masochism, post a small section of code with the accompanying errors.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Removed the dross

When looking at the Disasm in Studio right click it - there are options to switch off the "dross" before you copy it (via the "Display>" sub-menu)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So I could have save myself some minutes writing a sed script !!

Edit: I have just tried it. I am a lot happier without the "instruction help". However I cannot turn off the location counter. So I still have a sed script.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok ive tried the same with an AT90S8515 chip from an earlier version of the board. Ive got as far as disassembling the hex using the Studio disassembler and the program starts off as in the following attachment. The error displayed is as follows:

C:\Documents and Settings\justin\Desktop\AVR Tests\Copy of AVR_8515\thursday24\thursday24.asm(69): error: syntax error, unexpected '+'

This is the furthest ive got but if as you say its a futile effort ill have to look into getting some outside help or even reprogram the chip from start.

2 questions before i knock this on the head.

1 - Even though ive extracted a hex file, is there still a posibility that this program could still be locked/encrypted, is there any indication of this from the attached code i.e. same commands repeatedly in a row.

2 - What is it i need to add/remove from each line in the program to make it useable?

Thanks for all your help so far, i am slowly getting the hang of this but am still looking forward to starting from scratch if i cant get it working

Justin

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt that anyone here is going to download a .doc file (and risk macro viruses in Word). Can't you just post this as .txt or, better yet, simply post the .hex file that's been extracted from the chip.

But there's something I don't understand. In this thread there's been mention of both AT90S8515 and a mega162. You do realise, don't you, that the binary image for a 90S8515 is NOT going to work in an m162?

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yeah i was using a Mega162 to begin with which was in a latest version of the board but today started looking at a version 1 board with a 8515 in the hope that i may not have been locked. the code ill post now as a hex file is what i extracted today.

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Bad news I'm afraid - that most definitely is NOT valid AVR code. Have a look at this picture. It's every byte value from 00 to FF each repeated twice and then that pattern continues on through the image. Now I've never checked what a "locked" AVR returns when you try to read it but I would well believe that it be the lower byte of the word address or something which is exactly what this looks like. So either the chip functions and it is locked or there really is a sea of repeating data programmed into that chip if it's unlocked.

Cliff

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1. You have obviously got a locked AVR.
2. You have been attempting to assemble lines with the location_counter and code_word still in the line.
3. Your first stage would be to recognise what an ASM source line looks like.
4. Then learn the AVR opcodes etc.

5. There is no harm in asking any question here, but it certainly would have helped if you had just posted two lines of "source code" and the accompanying "errors"

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ok thanks lads, at least i know now.
yeah youre probably right David but on the up side i did gain some experience of how things work and piece together.
back to the drawing board for now...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

David,

 

 

Being an old FORTRAN programmer I have never found C to be useful.  I have been using a third party BASIC AVR compiler because the syntax is more like FORTRAN.  I'm interested in developing some assembly skills and would like to convert the known to be working HEX files to assembly to improve the speed and file sizes to run on a tiny13a.  After seeing your post I loaded Studio4 and the VIEW pull down shows Disassembler OK but is dimmed out.  The info in HELP is not very helpful; if you have any idea of what is needed to gain access to the disassembler I would appreciate it if you straighten me out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to disassemble AVR .hex files then I guess there are many ways to do it but the one I would favour is using the tools that come with the avr-gcc C compiler. (they are known collectively as "binutils"). This doesn't mean you have to use C. Simply that when you get the C compiler you get a lot of useful tools with it. If you are using Windows perhaps get and install:

 

http://www.atmel.com/tools/ATMEL...

 

the 8bit link on that page. When installed one of the tools you have access to is avr-objdump. You can do this:

$ cat avr.hex
:100000000C942A000C9447000C9447000C94470071
:100010000C9447000C9447000C9447000C94470044
:100020000C9447000C9447000C9447000C94470034
:100030000C9447000C9447000C9447000C94470024
:100040000C9447000C9447000C9447000C94470014
:100050000C94470011241FBECFE5D4E0DEBFCDBF16
:1000600010E0A0E6B0E0ECEBF0E002C005900D92ED
:10007000A236B107D9F710E0A2E6B0E001C01D92A8
:10008000AA36B107E1F70E9449000C945C000C9479
:1000900000008091660090916700A0916800B09187
:1000A00069008F3E2EEB92072DEAA2072EEDB207D4
:0C00B00011F485E588BB0895F894FFCF9B
:0200BC004230D0
:00000001FF
$ avr-objdump -m avr:5 -D avr.hex

avr.hex:     file format ihex


Disassembly of section .sec1:

00000000 <.sec1>:
   0:	0c 94 2a 00 	jmp	0x54	;  0x54
   4:	0c 94 47 00 	jmp	0x8e	;  0x8e
   8:	0c 94 47 00 	jmp	0x8e	;  0x8e
   c:	0c 94 47 00 	jmp	0x8e	;  0x8e
  10:	0c 94 47 00 	jmp	0x8e	;  0x8e
  14:	0c 94 47 00 	jmp	0x8e	;  0x8e
  18:	0c 94 47 00 	jmp	0x8e	;  0x8e
  1c:	0c 94 47 00 	jmp	0x8e	;  0x8e
  20:	0c 94 47 00 	jmp	0x8e	;  0x8e
  24:	0c 94 47 00 	jmp	0x8e	;  0x8e
  28:	0c 94 47 00 	jmp	0x8e	;  0x8e
  2c:	0c 94 47 00 	jmp	0x8e	;  0x8e
  30:	0c 94 47 00 	jmp	0x8e	;  0x8e
  34:	0c 94 47 00 	jmp	0x8e	;  0x8e
  38:	0c 94 47 00 	jmp	0x8e	;  0x8e
  3c:	0c 94 47 00 	jmp	0x8e	;  0x8e
  40:	0c 94 47 00 	jmp	0x8e	;  0x8e
  44:	0c 94 47 00 	jmp	0x8e	;  0x8e
  48:	0c 94 47 00 	jmp	0x8e	;  0x8e
  4c:	0c 94 47 00 	jmp	0x8e	;  0x8e
  50:	0c 94 47 00 	jmp	0x8e	;  0x8e
  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63
  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d4 e0       	ldi	r29, 0x04	; 4
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	ec eb       	ldi	r30, 0xBC	; 188
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	;  0x70
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0
  70:	a2 36       	cpi	r26, 0x62	; 98
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	;  0x6c
  76:	10 e0       	ldi	r17, 0x00	; 0
  78:	a2 e6       	ldi	r26, 0x62	; 98
  7a:	b0 e0       	ldi	r27, 0x00	; 0
  7c:	01 c0       	rjmp	.+2      	;  0x80
  7e:	1d 92       	st	X+, r1
  80:	aa 36       	cpi	r26, 0x6A	; 106
  82:	b1 07       	cpc	r27, r17
  84:	e1 f7       	brne	.-8      	;  0x7e
  86:	0e 94 49 00 	call	0x92	;  0x92
  8a:	0c 94 5c 00 	jmp	0xb8	;  0xb8
  8e:	0c 94 00 00 	jmp	0	;  0x0
  92:	80 91 66 00 	lds	r24, 0x0066
  96:	90 91 67 00 	lds	r25, 0x0067
  9a:	a0 91 68 00 	lds	r26, 0x0068
  9e:	b0 91 69 00 	lds	r27, 0x0069
  a2:	8f 3e       	cpi	r24, 0xEF	; 239
  a4:	2e eb       	ldi	r18, 0xBE	; 190
  a6:	92 07       	cpc	r25, r18
  a8:	2d ea       	ldi	r18, 0xAD	; 173
  aa:	a2 07       	cpc	r26, r18
  ac:	2e ed       	ldi	r18, 0xDE	; 222
  ae:	b2 07       	cpc	r27, r18
  b0:	11 f4       	brne	.+4      	;  0xb6
  b2:	85 e5       	ldi	r24, 0x55	; 85
  b4:	88 bb       	out	0x18, r24	; 24
  b6:	08 95       	ret
  b8:	f8 94       	cli
  ba:	ff cf       	rjmp	.-2      	;  0xba
  bc:	42 30       	cpi	r20, 0x02	; 2

In this example I happened to use "-m avr:5". The architectures that can be disassembled are:

avr-objdump: supported architectures: avr avr:1 avr:2 avr:25 avr:3 avr:31 avr:35 avr:4 avr:5 avr:51 avr:6 avr:100 avr:101 avr:102 avr:103 avr:104 avr:105 avr:106 avr:107

Just use plain "avr" if you don't know.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wouldn't recommend trying to re-engineer source code from a  .hex file that has been created by dump of a flash program download.  It is possible to convert the .hex file to binary using the hex2bin.exe utility (usually executed from the PC command line).  This will show you where the code is located in the flash map.  And you COULD disassemble the binary code.  But you have to know where the library routines start/end and the main code resides. 

  It is possible when the original program was written in assembler AND the source is only about 30-50 instructions long.   Basically if the original ap was a state machine.   But to recreate C source from a binary listing or disassembly?  In the embedded systems industry, there are two correct answers to the question: Can I do this thing...???  One answer is "yes, it is ...possible..."  The other answer is "No, the effort isn't worth the return".  The respondents on AVRfreaks will always give the first answer because they are engineers.  But often the better correct answer is just "no, try something else".

 

* important *

   It is easier to rewrite the code from a written description of the application, through the algorithmic development process, to the code/compile/upload/test loop than it is to re-engineer code from code that is already inside a microcontroller.   Always.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The OP asked why he can not reload the hex file into another unit and have it run, well that could work IF the original unit was using the default fuse settings.

When pulling code from an AVR, you should also make note of the fuse settings as well.

Then when the hex is loaded into the new AVR, also program the fuse settings copied as well and it should now work the same as the original.

 

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Utter rubbish. The .hex file has address information. A .bin file does not. If the above hex had been based at a non-0 address my disassembly would have shown it. Also you can see where main/subroutine code is just by looking at that. You know (if it's 0 based) that the first instruction must be a valid opcode and you can trace everything else from there:

   0:	0c 94 2a 00 	jmp	0x54	;  0x54

is a valid jump to:

  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63
  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d4 e0       	ldi	r29, 0x04	; 4
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61
  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	ec eb       	ldi	r30, 0xBC	; 188
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	;  0x70
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0
  70:	a2 36       	cpi	r26, 0x62	; 98
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	;  0x6c
  76:	10 e0       	ldi	r17, 0x00	; 0
  78:	a2 e6       	ldi	r26, 0x62	; 98
  7a:	b0 e0       	ldi	r27, 0x00	; 0
  7c:	01 c0       	rjmp	.+2      	;  0x80
  7e:	1d 92       	st	X+, r1
  80:	aa 36       	cpi	r26, 0x6A	; 106
  82:	b1 07       	cpc	r27, r17
  84:	e1 f7       	brne	.-8      	;  0x7e
  86:	0e 94 49 00 	call	0x92	;  0x92
  8a:	0c 94 5c 00 	jmp	0xb8	;  0xb8

It should be pretty obvious to anyone with even a small familiarity with AVr code that it's clearing SREG:

  54:	11 24       	eor	r1, r1
  56:	1f be       	out	0x3f, r1	; 63

setting the stack:

  58:	cf e5       	ldi	r28, 0x5F	; 95
  5a:	d4 e0       	ldi	r29, 0x04	; 4
  5c:	de bf       	out	0x3e, r29	; 62
  5e:	cd bf       	out	0x3d, r28	; 61

copying data from flash to RAM:

  60:	10 e0       	ldi	r17, 0x00	; 0
  62:	a0 e6       	ldi	r26, 0x60	; 96
  64:	b0 e0       	ldi	r27, 0x00	; 0
  66:	ec eb       	ldi	r30, 0xBC	; 188
  68:	f0 e0       	ldi	r31, 0x00	; 0
  6a:	02 c0       	rjmp	.+4      	;  0x70
  6c:	05 90       	lpm	r0, Z+
  6e:	0d 92       	st	X+, r0
  70:	a2 36       	cpi	r26, 0x62	; 98
  72:	b1 07       	cpc	r27, r17
  74:	d9 f7       	brne	.-10     	;  0x6c

writing 0 to some RAM locations:

  76:	10 e0       	ldi	r17, 0x00	; 0
  78:	a2 e6       	ldi	r26, 0x62	; 98
  7a:	b0 e0       	ldi	r27, 0x00	; 0
  7c:	01 c0       	rjmp	.+2      	;  0x80
  7e:	1d 92       	st	X+, r1
  80:	aa 36       	cpi	r26, 0x6A	; 106
  82:	b1 07       	cpc	r27, r17
  84:	e1 f7       	brne	.-8      	;  0x7e

then calling into some code (it happens to be C's main() function in fact):

  86:	0e 94 49 00 	call	0x92	;  0x92
  8a:	0c 94 5c 00 	jmp	0xb8	;  0xb8

Should that function return it then goes to:

  b8:	f8 94       	cli
  ba:	ff cf       	rjmp	.-2      	;  0xba

which clears interrupts then enters an infinite loop. The main() code is:

  92:	80 91 66 00 	lds	r24, 0x0066
  96:	90 91 67 00 	lds	r25, 0x0067
  9a:	a0 91 68 00 	lds	r26, 0x0068
  9e:	b0 91 69 00 	lds	r27, 0x0069
  a2:	8f 3e       	cpi	r24, 0xEF	; 239
  a4:	2e eb       	ldi	r18, 0xBE	; 190
  a6:	92 07       	cpc	r25, r18
  a8:	2d ea       	ldi	r18, 0xAD	; 173
  aa:	a2 07       	cpc	r26, r18
  ac:	2e ed       	ldi	r18, 0xDE	; 222
  ae:	b2 07       	cpc	r27, r18
  b0:	11 f4       	brne	.+4      	;  0xb6
  b2:	85 e5       	ldi	r24, 0x55	; 85
  b4:	88 bb       	out	0x18, r24	; 24
  b6:	08 95       	ret

That code is loading a 4 byte variable from memory and checking to see if it contains the value (0xDEADBEEF). If it does then 0x55 is output to IO location 0x18 (that's PORTB in a mega16).

 

I don't remember the source of this yet I have a pretty clear idea of exactly what every byte there is doing. Where is there any mystery in this?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sorry Clawson,  I think you misunderstood my comment.

 

I was talking about pulling the hex dump from the working unit, assuming it was not locked.  This hex file along with the fuse settings can then be uploaded (burned) into another identical AVR and it should work like the first one. 

 

Nothing to do with disassembly, which is where the thread seems to be heading.

 

Jim

 

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your comment wasn't there when I posted that - I was responding to Simonetta (who spouts drivel most of the time).
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
The OP ...
probably lost his job due to sloppy management in his company.

 

@Simonetta: Why do you want to learn assembler?

Maybe get some pills to get over your allergy for C and then realize C is nothing but glorified (abstracted?) assembler which also happens to be cross platform.

Trying to learn assembly from a 10 year old hex file of unknown origin is well, very backward.

Doing magic with a USD 7 Logic Analyser: https://www.avrfreaks.net/comment/2421756#comment-2421756

Bunch of old projects with AVR's: http://www.hoevendesign.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can only confirm the previous notes about programming in C. The C compiler looks after saving/restoring registers in functions and ISRs automatically, the code optimiser produces code which is usually just as fast and compact as assembler, and you produce readable code at least ten times faster.

I've been through it all. Only a masochist would write assembler!

Jerry

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Folks try to remember this thread has lain dormant for years then was resurrected at #42 where he was asking if it were relevant to disassemble the output of a high level language to look for missed optimisations that would allow the code to be squeezed into a very small micro. Nothing about C specifically, BASIC in fact.

 

Of course it's a valid thing to do. I often advise people to sketch an idea in an HHL, have it built,  then use the resultant Asm as the starting point of an Asm project that can then be further optimised. It is quite possible to read the Asm of any HLL, after all it's all just Asm!

 

Sure HLL's may do "odd things" like creating frames of variables on a stack and indexing the data off an index register or shuffle function parameters around in registers to meet some ABI -  but any competent Asm programmer will understand such paradigms. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Maybe get some pills to get over your allergy for C and then realize C is nothing but glorified (abstracted?) assembler which also happens to be cross platform.

Trying to learn assembly from a 10 year old hex file of unknown origin is well, very backward.

In many situations especially on a small micro as the tiny13 C is very inefficient compared to C.   

I do know that there are many small examples where C is close, but with a micro with only 500 instructions C is clumsy.

And for many of those that get C close it's only because they know ASM to begin with.   

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the late 1960s I managed a computer controlled jet engine test stand project. The company was large enough that there were separate divisions for hardware and software development.  Both divisions were under the impression that they made the system and the other only provided support.  The task of getting both of them to talk to the other made me realize that I knew enough to be dangerous.  The one thing that I did learn was compilers produce workable executables BUT not the fastest or the smallest file sizes.  When the people that really had a handle on the instruction set could clean up the compiler generated executables by using assembly that was a valuable lesson.

 

I have to assume the same is true for the compiler I use for the AVRs.  My interest in assembly coding is one of our projects uses a tiny25 but the executable would run in a tiny23 if around 2% smaller.  In addition our product is battery powered so there is a small improvement in battery life with a tiny13.  So for 2% more room the cost of the micro is more that 50% higher.  If you are competing with the offshore manufacturers you must cut costs were ever possible.

 

Having said that; this may be a useless effort but no one can be sure of that if it’s not tried.  The other factor is doing something others say can’t be done.  If that can be accomplished it may be worth more than the cost savings.  Besides that it keeps me out of the bars and off the streets!!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which BASIC compiler are you talking about? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Being an old FORTRAN user I selected BASCOM-AVR because of the similar syntax and listing structure.  It looks like I should proof my posts,  the goal is to shrink the need for memory to fit a tiny13, it runs fine in a tiny25....

Last Edited: Sun. Oct 2, 2016 - 07:57 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I doubt Bascom is THAT inefficient to be able to half a code size. BASIC and C are not perfect but it'd be pretty unusual to be able to shave much more than 10..25%

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

It looks to me like it's only around 2%, only time will tell....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Which C compiler do you talk about? , for me this sound as nonsense.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your comment is directed to me all I can say is it may be nonsense.  If it is it is just a repeat of other nonsense and that will be a lesson learned...
 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is it you want to improve? (save 5% in size and same speed or ?)

 

Depending of the problem you solve the amount of RAM easy could be a bigger problem than flash size.

 

Hints to good ASM on a tiny13.

Don't use STS and LDS, but set Y to point to start of RAM, and then you can reach all RAM with instructions of 1/2 the size (LDD and STD). (and that way YH become your zero reg)

If you have 16 bit things that needs to be atomic store them in registers and use movw, that way they gets atomic by nature.

Have a good plan of the use of all the registers, and RAM , and if you don't use all the EEPROM perhaps put a small lookup table there.

add

and for thing where you need pointers try to keep them i 1 page, so they can be handled as 8 bit.

Last Edited: Sun. Oct 2, 2016 - 09:56 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

No it was to #50 (look at the reply number)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I thought you were talking about fitting the code of a 2K micro into a 1K micro.  If all you are saying is that in the 2K micro you are only using 1K+2% and need to shave off that 2% to make it fit in a 1K micro then why do you even need to mess with disassembly,  hand optimisation and reassembly? Surely there must be at least one statement in your BASIC code that can just be rearranged or something to get back 2%?

 

2% of 1K is just 21 bytes!! 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You make my point, I've tried playing around with the instructions and made a slight improvement but that is like pushing a train with a wet noodle.  As for the speed it's not important in fact even the 128KHz clock is faster than necessary in this application, the goal is to reduce the memory space required.  While I realize this may be a waste of time if I can't knock off the 2, maybe 3% I will learn what I can't do.  One thing I know for sure is if I don't try it will not ever know if it would.

 

All of this still misses the initial question, i.e., is there a way to convert the hex file to assembly? 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I find a way to go from HEX to ASM I'll take this as good advice....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If I find a way to go from HEX to ASM

What happens if you just open the hex file in Studio? You can open a hex file in AS4 (don't know about AS7) for debugging and it would generate an "asm" file.

 

This is what a get from a hex file for one of my test DS1307 project, and it's about as good as it gets. Compare it to what the original file contains.

Attachment(s): 

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Last Edited: Mon. Oct 3, 2016 - 01:21 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

charger wrote:

All of this still misses the initial question, i.e., is there a way to convert the hex file to assembly? 

 

Yes, there is. Often this is called DisAssembly. Most debuggers include a DisAssembly pane, which often has a little more smarts than plain-DisAsm, and will include Symbol names.

The examples in #65 show what you can expect from such a DisAsm step.

There are no names, so all information is in Hex.

You can make a smarter DisAsm, that tries to build Data space equates, and use those names in the Assembler, but you still need to manually add the better names.

 

A smarter way to learn ASM, is to look at the Assembler output from your compilers, and find ways to pack that smaller...

Often, you can recode things, to better pack the code, and often avoid certain designs.

 

charger wrote:
the goal is to shrink the need for memory to fit a tiny13, it runs fine in a tiny25....

Why bother ? Will you be making 100,000+ of these ?

If price really dominates, you probably would choose a MCU other than an AVR anyway.

Just go to Digikey, and sort 8 bit MCU by CodeSize and Price...

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

charger wrote:
If I find a way to go from HEX to ASM I'll take this as good advice....
I guess you did not read #43 then? As I say avr-objdump will give you a disassembly. True it is annotated with opcode addresses and opcode bytes but any editor with "column delete" can quickly remove those.

 

To be honest though, for 1K (+21 bytes) of code I would just take whatever algorithm you are implementing and recode it in plain Asm from scratch. You can't be doing much in 1K that is so complex that it is not easy to just rewrite as Asm. It will give you a "cleaner" solution than HLL->DisAsm->edit->Asm.

 

EDIT: having said that, unless it is uber secret, just attach the .hex file that comes out of your Basic compiler to a post here and I'm pretty sure one of us could quickly produce a slimmed and trimmed Asm source from it.

 

PPS: oh and the BASIC source if that is not too secret - it'll make it easier to follow what's going on in the Asm that way.

Last Edited: Mon. Oct 3, 2016 - 08:51 AM