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
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.
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?
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.
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 :(
you will not be able to read ANY code
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?
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.
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?
I told you that you have to remove some dross first. Then it should assemble with Studio4 assembler.
David.
when i copy and paste the hex file into studio 4 it doesnt allow me to assemble it.
oh right, sorry, ive never done that. Can it be done in studio 4?
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.
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.
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.
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?
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?
can you reccommend a good book that would help me do what i need?
are you saying that now i have to add parts to this program before it will assemble in studio 4?
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.
Hi,
there is also another one called DISAVR. Doesnt have a link at the moment, but Google should help.
Frank
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
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
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?
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
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.
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.
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
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
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)
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.
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!
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.
Removed the dross
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.
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
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
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.
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
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.
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...
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.
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.
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.
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
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?
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
Your comment wasn't there when I posted that - I was responding to Simonetta (who spouts drivel most of the time).
The OP ...
@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.
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
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.
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.
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!!!
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....
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%
It looks to me like it's only around 2%, only time will tell....
Which C compiler do you talk about? , for me this sound as nonsense.
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...
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.
No it was to #50 (look at the reply number)
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!!
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?
If I find a way to go from HEX to ASM I'll take this as good advice....
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.
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.
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...
If I find a way to go from HEX to ASM I'll take this as good advice....
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.
