hi i am using keil uVision3. i have written a simple code in assemply language which contains jump instructions like sjmp,jnz jb . when i generate the hex file from this asm file all the other values in the hex file are correct except for the jump addresses corresponding to these instructions
my asm file is as follows
reset: ljmp start nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop nop start: mov A,#00h -- mov P0,#0ffh -- mov P1,#0ffh -- jb p1.0,jump1 jump1: jnz jump2 -- mov a,P0 -- mov R0,a -- mov a,#00h -- inc a -- ret jump2: mov a,P0 -- mov R1,a -- sjmp jump3 -- ret jump3: mov A,R1 -- add A,R0 -- mov P0,A -- clr P1.2 -- setb P1.2 -- clr P1.2 -- ret -- end
(i have used "--" for formatting this msg its not part of actual .asm file ) and the hex file i get is like this
:1000000002001D00000000000000000000000000D1 :1000100000000000000000000000000000740075F7 :1000200080FF7590FF2090007007E580F874000451 :1000300022E580F9800122E928F580C292D292C29D :0200400092220A :00000001FF
here u can see that hex corresponding to jb is 20 (3rd line) after that address of port p1.0 which is 90 but the address that it should jump comes out to be 00 which is incorrect. the address should be 28(hex)
{you can calculate the address by writting one byte per line or generate a dua file from the hex file}
please tell me if i am missing out on something.......and tell me how to generate a correct hex file
when i generate the hex file from this asm file all the other values in the hex file are correct except for the jump addresses corresponding to these instructions
Actually the only thing incorrect here is your belief that you know what those jump addresses should look like in a hex file.
I suggest that next time you feel like blaming somebody else's work to be faulty, you make you sure you got your facts straight first.
first of all my apologies if my post looks offending or demeaning to anybody. I just want answers to my queries.
let me explain in detail what i am doin. i have made 8051 core in vhdl and am prototyping it to xilinx fpga. the hex file that we burn on to the microcontroller needs to be stored in a rom for fpga. for that i have to generate a .dua file which is nothing but 1byte per line (8bits) which will be written in a DRAM working as rom for the core.
i understand that when an instruction in assembly gets translated to hex . lets take the case of jb instruction that i have used in the code
instruction jb bit,raddr
jb is of 3 bytes first is opcode (1st byte) 20(hex) second is bit address p1.0 90(hex) third is the jump raddr 00(hex) this is what i have received from keil hex file and certainly cannot be the jump address as that is the position for reset.
i think the address here should be the position where the instruction next to the label jump1 is stored ie 28(hex) where the the byte corresponding to instruction jnz(70 in hex) is stored.
my .dua file is
00000010 00000000 00011101 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 01110100 00000000 01110101 10000000 11111111 01110101 10010000 11111111 00100000 10010000 00000000 01110000 00000111 11100101 10000000 11111000 01110100 00000000 00000100 00100010 11100101 10000000 11111001 10000000 00110111 00100010 11101001 00101000 11110101 10000000 11000010 10010010 11010010 10010010 11000010 10010010 00100010
ps: is there a way to add attachment or screenshots in the post
please tell me if my interpretation of hex file is correct or not
third is the jump raddr 00(hex) this is what i have received from keil hex file and certainly cannot be the jump address
It can, and it is, and you obviously haven't heeded the advice I gave you before.
You still believe you know what the third byte of that CPU instruction should be. And like I told you before, that belief of yours is wrong.
So stop assuming you know things and actually go look up the encoding of the instruction in the processor's data sheet.
sir,
i have checked the data sheets and found out that the 3rd byte should be the jump address of instruction stored in rom when condition is met.
sir are you an employee of arm or someone who is part a of uVision team ? if not then some seniors or experts please reply ..
the hex corresponding to the first jump LJMP works as after reset the program jumps to location start which is evident from the hex file . but for instructions JB and JNZ the correct addresses are not generated properly
i have checked the data sheets and found out that the 3rd byte should be the jump address of instruction stored in rom when condition is met. incorrect
WHY do you refuse to work with chapter 2 of "the bible" instead of making incorrect statementsin the forum.
Erik
found out that the 3rd byte should be the jump address of instruction stored in rom when condition is met.
You found out incorrectly, then. I'll give you a hint: you found something called 'raddr' in your description before. What do you think that spurious 'r' before 'addr' might be about?
but for instructions JB and JNZ the correct addresses are not generated properly
You're still every bit as incorrect about that as you've been days ago.
I'm not entirely sure why there's so much hostility in this thread.
The "bible" Erik is referring to can be found here (he was nice enough to point me that direction with a problem I had in another thread):
www.8052.com/.../120112
As he mentioned, it gives information regarding the jump commands in chapter 2. If you read that portion, it should give you some insight on what the problem could be. I hope this helps!
I'm not entirely sure why there's so much hostility in this thread. I would not know about that, butwhen soneone post i have made 8051 core in vhdl and am prototyping it to xilinx fpga and show that (s)he has not even taken the time to understand the instruction set of the processor (s)he is synthesizing, "politically correct" responses is not to be expected. Especially when the post is not "I do not understand", but "incorrect hex generation from keil"
It is a relative address, Not absolute.
I have realized my mistake. and the core is working fine
I do understand that the title of the post was a little offensive specially to those who have designed the compiler. i will be careful in choosing title in future.
i am a student so i am used to a little admonishing but i appreciate the fact that seniors came out to help me and that is what really matters.
for others go through the docs carefully
jb b,raddr
raddr is the relative address here its 00000000 which then gets added to the program counter plus 1 to generate the rom address.
that's YOUR job
heve you even downloaded chapter 2? much more explicit that any datasheet
I think what he's saying is to anyone else that might read through this post, his advice is to go through the documents carefully. I don't think he's directing that at anyone in particular. In fact, I think he's confirming what you've been telling him.
one could easily see that the so called seniors are very rude. this guy might be wrong with the title of his post but than this is what he probably thought. Just because you know something doesn't mean that you have to be rude to others as it must have taken long time for you guys to learn.i didn't see any straight answers or clear reference to anything that these guys have given.
be nice to newbies as once you were also one
one could easily see that the so called seniors are very rude. There is, today an expectation that every statement is wrapped in pink cotton.
e.g. I posted "WHY do you refuse to work with chapter 2 of "the bible" instead of making incorrect statementsin the forum" instead of posting "I will gladly read the manual for you, find the relavant paragraph and quote it here, please come back when you need me to read the manual for you again"
if thst is what is supposed to be posted to not be "rude" expect rudeness (as you define it).