| View previous topic :: View next topic |
| Author |
Message |
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| reset vector question self modifying code for bootloader |
 Posted: Mon Sep 17, 2007 2:22 am |
 |
|
The first two lines of the hex file looks like this
:020000040000FA
:0400000011EFF9F013
The reset vector in the LST file looks like this
00000: GOTO 1F222
How does 11EFF9F0 translate to 1F222 ?
In theByteFactory boot loader the reset vector for the loaded code is programmed into the boot loader space as self modifying code. so when the loader reaches that location it will branch jump or goto to the location for the loaded code.
Just how does 11EFF9F0 translate to a 20 bit address ?
// Self-modifying code
Downloaded_Reset_Vector:
#asm
NOP // The downloaded reset vector will be written here on success
NOP // place holder for 21 bit address !
NOP // End of reset vector
NOP // Valid/Invalid vector flag (NOTE: Will never execute because the vector is a jump)
#endasm |
|
 |
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Sep 17, 2007 2:58 am |
|
|
| Quote: | | How does 11EFF9F0 translate to 1F222 ? |
Change the byte sequence to match the endianness of the PIC:
11EFF9F0 -> EF11F0F9
From Chapter 26 of the PIC18F8722 family datasheet (assuming you are still using the PIC18LF6720):
0xEF + F of the second word = GOTO
Address is always 16 bit alligned, lower bit not encoded cause always 0:
0x0F911 * 2 = 0x01F222 |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
| Confused about actual ROM |
| Posted: Mon Sep 17, 2007 8:59 am |
|
|
| ckielstra wrote: | | Quote: | | How does 11EFF9F0 translate to 1F222 ? |
Change the byte sequence to match the endianness of the PIC:
11EFF9F0 -> EF11F0F9
From Chapter 26 of the PIC18F8722 family datasheet (assuming you are still using the PIC18LF6720):
0xEF + F of the second word = GOTO
Address is always 16 bit alligned, lower bit not encoded cause always 0:
0x0F911 * 2 = 0x01F222 |
Thanks for the reply.
I'm still not clear on how the order of the bytes should be in memory to produce a "goto address" statement !
Another example:
:0400020057EF0AF0BA
57EF0AF0
EF57F00A
becomes EFF0 0A57
I did some practical test and concluded that the order in program ROM
will be
Lowest program address ----------Highest program address
57 EF 0A F0
However that does not work. So There appears to be something wrong
with the "self modifying code" !
The loader programmed the application code and put the Application reset vector at the location where is should execute the got address statement.
I did a read of the chip and confirmed the application reset vector is where it should be at
:10F4200017EFFAF057EF0AF00100000000005A6AE7
-----------------------||||||||||
The rest of the file compares with the application hex file, all except the
reset vector at 0000 which of course the the boot loader vector.
Any thoughts on this would be appreciated. |
|
|
ckielstra
Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands
|
|
| Posted: Mon Sep 17, 2007 4:46 pm |
|
|
You say it is not working, but you don't say what you want to achieve. A byte sequence of 57EFF0AF is the command 'GOTO 0x14ae' is that what you wanted?
I got this by playing with MPLAB. In the Program Memory window you can edit the opcode and see the resulting assembly instructions directly. Use the import and export functions to write a small memory area to a hex file. |
|
|
Hans Wedemeyer
Joined: 15 Sep 2003
Posts: 226
|
|
| Posted: Mon Sep 17, 2007 5:22 pm |
|
|
| ckielstra wrote: | You say it is not working, but you don't say what you want to achieve. A byte sequence of 57EFF0AF is the command 'GOTO 0x14ae' is that what you wanted?
I got this by playing with MPLAB. In the Program Memory window you can edit the opcode and see the resulting assembly instructions directly. Use the import and export functions to write a small memory area to a hex file. |
I need it to be goto 0x14ae .
This is part of a bootloader and is the reset vector of the loaded application.
The bootloader is based upon theByteFactory loader, although much modified I now have the code working to the point where it can receive the intel HEX file and reliably write it to program memory.
It appears to me that everything is in place. The interrupt vectors and code all compare byte for byte with the original application HEX file when I read the chip.
What the bootloader is failing to do is vector to the application starting point from the bootloader main().
This is my first venture into bootloaders and I'm doing something wrong !
So close yet so far... |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
