Printable View
I'm pondering several projects that require at least slight modifications to MCLoader. Most of them need to know the address of the PBP "INIT" location, so I can jump to it when I'm done doing my "stuff".
I'm really curious as to how MCLoader figures out this location, since it loads BEFORE the PBP program. Can anyone enlighten me as to how this all works?
Hi,
Charles I am not sure if I understood your question actually ? Here is a portion from the PBP library.
Rather than having a reset vector at 0x0000 PBP/MCS offsets this. Interesting to know this coincides with the int vector which is followed by NOP inserted by PBP. So when you are actually using interrupts this is replaced by a goto to your interrupt routine. I think that all this is according to how your code is laid out. The microcode loader on startup from the reset vector tries to handshake and if found just starts programming your PIC without ever touching the first 4 locations. So I think it may be location 0x0005 where you need to jump. Better decompile your hex and take a peek.Code:ifdef LOADER_USED
LIST
ORG RESET_ORG + 8 ; Make sure no library code in first 4 locs
NOLIST
endif
I'll check, but I don't thank that is it.
Hi,
Charles could you give an example as to what your exact requirements are ? Seems interesting. I have been pondering on issues of update-able protected firmwire. I need that the client may update a firmwire themselve but cannot effectively use it to dupe chips. Seems I need some sort of licensing firmware inside the PIC and a custom bootloader at the PC side.
Charles,
I thought we already figured that out?
Still not working?
<br>
Yes, I used your technique of creating the variable 'INIT' inside an ASM block that was at the end of my PBP code. That worked fine.
If you remember, the goal was to make a "hardware write protected bootloader" - one that could (hopefully) be loaded in the field without a PIC programmer. I put MCLoader in all chips. You also have to understand that a LOT of my stuff goes to the military, and they have some strange requirements, hence the demand for this "write protect" feature.
I wrote a program (in PBP) that "field-patches" MCLoader. I got to the upper half of the 18F8722's program space by modifying PBPP18.LIB with a new system variable ('UPMEM') that loads into TBLPTRU. By setting this to "1" I can use READCODE, ERASECODE and WRITECODE in upper half of FLASH. If UPMEM is "0" these commands work in the lower half.
My PBP program changes the MCStudio jump vector at 0x00 from 0x1fd04 to 0x1fcd0, and adds a statement at 0x1fcd0 to jump to 0x1fd04 (the start of MCLoader).
That takes care of the first-time load using the bootloader - we load ALL our code, including the first time, using MCLoader.
Next, my actual PBP application contained an ASM block at the end with an ORG at 0x1fcd0. It checked whether a pin was high or low, and decided either to jump to 0x1fd04 or INIT. The bootloader was invoked when the pin was low (it is pulled up) or else it jumps to the program start, bypassing the autoloader. This gave the "write protect" feature I was looking for.
So far, so good - except for one thing... The FLASH is automatically erased before programming. Since my new jump vector at 0x00 pointed to a normally unused address in the codespace, if programming was interrupted before MCLoader could get the application all the way "in", the chip could no longer be programmed in the field - it is back to the factory time. This can be a real pain if the board is deeply embedded in some submarine, tank or airplane.
I really wanted to locate the "new addition" to the bootloader (the test for pin high or low) to an address ABOVE MCLoader. There are a few more than 64 bytes above the top of that program in an '8720 or '8722. This is handy, since the block size of the ERASE in both chips is 64 bytes.
So, I re-wrote my "bootloader patcher" to change the 0x00 vector to 0x1ffc0 (which is a few bytes above the top of MCLoader). I also wrote my "test for pin state" (and a few other things) in assembly and put its start address at
0x1fc0. I found, by inspecting a lot of code, that PBP was always setting the INIT address to 0x59a, so I test for my pin state and jump to either 0x59a or 0x1fd04, the start of MCLoader.
So far, it has been working perfectly, and the good thing is that I can pull the power plug halfway through programming, and later restart the programming cycle. My only concern is that I have my INIT vector hard-coded at 0x59a, and I'm worried that it won't always work.
WHEW!
And Sougata,
One other thing:
I have already modified the approach slightly to make this "bootloader write
protect" software selectable. If you have access to the program, and give it an "unlock code", it puts itself in the "OK to run bootloader" mode. On the next power-up, the bootloader will run. If the bootloader isn't used during that power-up cycle OR the program is updated using the bootloader, the program then "locks" the bootloader again. In other words, you give the unlock code, then you have ONE chance to use the bootloader on the next power-up cycle.
Hi Charles,
Thats a nice work around and might be very useful to me. Thanks.
It's a good reason for concern, because INIT is always located after the system library code. Some day you'll use a statement that hasn't been used yet in the program and the library size will increase. Then INIT will be moved along with it, and it won't work anymore.Quote:
Originally Posted by Charles Linquis
When you compile a program, the first instruction at location 0000 is a GOTO INIT.
But when MC Loader loads the program, it relocates that instruction to an address just before the bootloader code.
I don't have an 18F8722 to look at, but on an 18F452 the bootloader code starts at 0x7D84, and the GOTO gets relocated to 0x7D70.
You can see from the disassembly here, the highlighted line is where the GOTO instruction was moved to.
0x4a is the address of INIT for this test program.
http://www.pbpgroup.com/files/LoaderHex.jpg
So all you need to do is figure out where it gets relocated with that chip, then jump to that address, which in turn jumps to INIT.
HTH,
Darrel,
This is just the information I was looking for.
After I make my first million, I'll buy the rights to PBP from MELabs, and I'll be at your doorstep begging you to work for the company.
Thanks for the hundredth time.
If anyone else cares, the "magic address" Darrel is referring to for an 8720/8722 is 0x1fcf0 using MCLoader. Jump there, sit back and smile.
Sweet!
+confirmation :)
Well, you get the rights to PBP, and have the ability to pay a modest salary... and I'll take that job. :D
Knock off some of those wish list items from 4-5 years ago. :eek:
<br>
Just curious,Quote:
Originally Posted by Charles Linquis
Does that mean the PIN is no longer used?
Was just thinking about how easy it would be, if all you had to do was lift a pin to enable the bootloader.
But if the PIN's gone, and it requires an "unlock code", it sounds pretty cool.
Any chance of sharing the modified bootloader.
or would you need approval from the pentagon? :)
<br>
I'll see what I can do...
Forgot to answer the first question -
Yes, it now doesn't check the state of a pin. It is pure software.
My earlier version that uses the pin was written to satisfy a customer requirement.
I want to play with the whole thing a bit before I consider releasing it to the public.