Bootloader and Instant Interrupts Atn:_DT_

Hi.
Well i use the instant interrupts system (always thanks to DT), i am now trying to develop some code to update my device via serial port with a bootloader. I guess i will begin by using some writecode commands and some Serial control. I guess i can work it out.

But i have some questions about the location of this code, where is supposed a bootloader to be placed in code memory? i guess org 0h seems logical, but what would happen with my interrupts? where are they located? i really have no idea, this interrupt systems just works, period :D

The fact is that with Org 0h i get compile errors, "overwriting previous address contents", but Shouldn´t the bootloader be the first code to run?.

By the way, has someone done his own Bootloader? the reason i am doing mine is because i intend to add some tricks to avoid my code to be copied, i intend to place it as an internet resource, any ideas on what this tricks could be? I was thinking to do some math in every word before writing it, maybe a shift that only a microcontroller with my code can write correctly in the memory. If anyone has done this, why and when is the erasecode command needed for a 18f device? it doesn´t seem too clear for me from the pbp manual.

I hope you guys find this an interesting post, for me it is a must ;)

Salutes
____
DC

I've seen it done both ways, but I think putting the bootloader at the end of program space works the best. That's the way MC Loader does it.

The code at locations 0000-0003 are also part of the bootloader. It's usually a GOTO instruction that jumps to the bootloader code itself. And when the bootloader actually loads the program, it moves the instructions that would normally go there, to a location just before the bootloader code, so that it can know where to start execution of the main program.

Just recently Charles Linquis was working on a similar project
http://www.picbasic.co.uk/forum/showthread.php?t=6167

Last I heard, he was re-writing it again.
Maybe not as easy as it seems. :eek:
<br>

I have done a lot of bootloader work. Unfortunately, I can't make very much of it public for various reasons.

So, even though I can't post any real code, I *can* tell you how I did it.

As it stands, my modified code simply prevents READS or WRITES by MCLoader unless the bootloader is "unlocked" under program control (or by the user through the serial or a net port). Once unlocked, it can be programmed on the next power up - only. After programming, the code locks the bootloader again. If the user fails to program it during that one power up cycle, it locks itself.

If your chip has more than 64K bytes of FLASH, then you will either have to write an assembly routine to write to the upper half, or else modify PBPPIC18.LIB to give you that access since ERASECODE and WRITECODE do not work above 0xffff.

If any one is interested, I'll post the technique.

Well i read the link Darrel posted, although i havent done any work on it i guess i have an idea to begin with.

Question marks Previous to coding:

1. The writecode, readcode, erasecode, are a must for my project and i need them at the end of the program, can you explain better the procedure to make them work over the whole code memory?.

2. I will work with 18f452 so Darrels INIT jump seems ok, BUT i dont intend to use Microcode Loader, i just want to write the code of the bootloader, so i maybe can make my own writecode loop (no read, verify code here...mmm?). Does this mean that correct steps would be, 1st change init jump to my own bootloader function (How? can you specify library change needed?), if no connection stablished then jump to real INIT (which is it? is it the same for the same uC? does it changes depending on code and libraries added?, does DT-18 interferes with this at all?).

3. Can i make my Bootloader function, compile and measure in codespace and then make the space for it at the end of the program? add an org to this function an begin with a jump to it at the begining of the program? (same INIT change question here probably).

4. Can the Bootloader be writen in basic? (hope so).

5.My God!!.. an interrupted writing could damage it all? if I erase (Not Bootloader) and then the writing of the first 5 lines fails everything goes to hell?, Maybe at some point the pclath would reach the bootloader and i could verify the existence of the first 5 lines and if there is no jump write it?;)

6. i guess i am going way ahead:p, lest keep simpler.

There are probably simpler ways, but I have documented the procedure I used. Note that I started with Mechanique's MCLoader.



Disclaimer: This is a complicated process that requires some knowledge of assembly. It also works
better with chips that have some "space" above MCLoader. If you use this approach on chips that don't have
at least one erase block above MCLoader (such as an 18F452), if programming is interrupted before successful completion, the BOOTLOADER WILL CEASE TO FUNCTION. This is because PIC memory must be erased before being
written. All codespace below MCLoader (which resides in high memory) is erased before the new program is
loaded.

Proceed at your own risk!



The scheme is basically as follows: (assuming 18F8722 here).

Look at the chip's datasheet and find the "block size" in the section on writing to FLASH memory. Note the ERASE block size and the WRITE block size. On an 18F8722 those are both 64 bytes.

Import the appropriate MCLoader .HEX file into MPLAB. View PROGRAM MEMORY, which basically does a disassembly of the code. Leave this window open, you will be using it again.

#1. Note the jump address - found at address 2 & 3 (it is a WORD, so it takes two bytes). In an 18F8722, this address is 0x1fd04.

Now scroll down to the address pointed to in step #1.

#2. About 16 bytes before this, (1FCF0 in a 18F8722) you will find a series of bytes filled with "0000"'s (the surrounding bytes will be filled with "FFFF"'s). The first byte of these "0000" is the INIT jump vector address. Write that address down as the "INIT JUMP VECTOR LOCATION"

#3. Scroll to the end of MCLoader and check if there is at least one "erase block size" between the end of MCLoader and the end of memory. In an 18F8722 there is. In an 18F450 there is not - Skip to step #5.

#4. Look for a byte on a segment boundary (evenly divisible by the erase segment size) that is just ABOVE the last address used by MCLoader. Write this address down as the "INTERCEPT ADDRESS". This address is 1FFC0 in an 18F8722. Go to step #6

#5. Look for a byte on a segment boundary (evenly divisible by the erase segment size) that is at least 1 erase block size BELOW the address you found in Step #2. Write this address down as the "INTERCEPT ADDRESS".


You will need to modify MCLoader. You can do this in at least two ways: Modify the appropriate MCLoader .HEX file (not for the timid). or you can write a "patcher" in PBP. I have done both.
If you choose to write a patcher, it needs to reside above the first block of memory (you will use the code itself to erase that block, so put an "@ ORG 0x40" at the beginning of your code to make sure it loads above that point. You need to modify the JUMP instruction at location 2 (&3) to point to your INTERCEPT ADDRESS. Before you can write to FLASH, you must erase it, so use the instruction "ERASECODE 0". This will erase the first block of FLASH.
Now use WRITECODE to write the ENTIRE first block of memory and put INTERCEPT ADDRESS in locations 2 & 3. For
an 18F8722 this would be:

WRITECODE $0,$0000
WRITECODE $2,$EFE0 ; Change the initial jump vector to 0x1FFC0
WRITECODE $4,$F0FF

FOR X = $6 TO $3E STEP 2 ; Finish writing the block
WRITECODE X,$FF
NEXT X


Next, you will have to add an instruction at 0x1FFC0 (or whatever INTERCEPT ADDRESS you are using) to add a JUMP to the address found in step #1 - the beginning of MCLoader (Don't forget to erase the block first).

1FFC0 = FFD6 EF82
1FFC2 = FFD8 F0FE

(This is for 0x1FD04)



What you have done is to cause the code to immediately jump to an address of YOUR choosing, and then jump to the
beginning of MCLoader. All this is necessary because you want the bootloader to be able to load your code the first time. So far, all will work normally.

;END OF BOOTLOADER PATCHING



Now, for the application code modification:

A. Add a block in your program to read the INTERCEPT ADDRESS to determine whether or not it is pointing to the beginning of MCLoader.

B. Go to a block that first ERASES the block starting at the INTERCEPT ADDRESS and changes the jump vector there to the INIT JUMP VECTOR LOCATION found in step #2.

C. Write another block that ERASES the block starting at the INTERCEPT ADDRESS and changes the jump vector there to the beginning of MCLoader.


When the program starts, it should perform "A" to see if the jump vector is pointing to MCLoader. If it is, it should call block "B". (Don't write to FLASH unless you really need to change it).

When you wish to unprotect the loader, call block "C"

Hi.

This seems like really complex to me, begining with the fact that almost everything is done to make it work with de MCloader, wich i don´t intend to use, if you can help me with this i would be grateful:

1. Change made to pbp 18f lib to make wirtecode usefull at the end of program memory.

2. The INIT position, is it always the same for same uC? how can i know it to go there if no sync with pc during bootloader is made.

3. 18f452 has 64 bytes blocks, can I use the last one for the bootloader and avoid erasing it?

Thanks for your help here.

Ok i don´t need writecode to work over FFFF because 452 doesn´t has that memory size.

I am trying something already, by the way, can you help me with some info about the hex format? i need now to open an HEX file and send it through the serial port of my PC. When i open an HEX with notepad i get:

:10000000126AA5EF00F0ABB2AB98AB880C50006E53
:100010000D50016E026A036A000000D004009EBA0F
:1000200013D0FF0E0226D8A00326D8A00026D8A001
:100030000126D8A0A2EF00F00248033CEDD7FA0E4B
:10004000026E000E036EEAD7AE50D880A2EF00F029
:1000500004009EA8FDD7AD6ED880A2EF00F0076E19
:100060008490809A809A9690929A929AF00E941622
:10007000075012B222D03A0E016E980E93EC00F0A7
:10008000330E066E30D8130E016E880E93EC00F01E
:100090002AD8640E92EC00F026D8640E92EC00F0A0
:1000A000220E066E20D8280E07D80C0E05D8060E94
:1000B00003D81282075001D01280066E12A00BD016
:1000C000809A03080EE30DD8070E016ED00E93EC54
:1000D00000F0D88012001280FE08D8B4A2EF00F021
:1000E000808A063A12A012908480F00E8216065082

this doesn´t look nice at all, and i dont find the match with for example

0000- 6a12 efa5 f000 b2ab 98ab 88ab 500c 6e00
0008- 500d 6e01 6a02 6a03 0000 d000 0004 ba9e
0010- d013 0eff 2602 a0d8 2603 a0d8 2600 a0d8
0018- 2601 a0d8 efa2 f000 4802 3c03 d7ed 0efa

presented by EPICWIN.

Is it correct for me to think that writing this last words to the appropiate addreses will get the uC correctly programmed?

:10 0000 00 126A A5EF 00F0 ABB2 AB98 AB88 0C50 006E 53
10 = record type
0000 = start address
00 = number of bytes in record, 00=16??? Not 100% sure on this
126A = data, look below at your 2nd chunk of data sent...look familiar?

0000- 6a12 efa5 f000 b2ab 98ab 88ab 500c 6e00


The 1st file you sent is an actual INTEL HEX file, which is a different format than...
The 2nd file chunk you sent...which is actual data.

Google 'INTEL HEX record', you should find all the info you need somewhere out there...

http://www.cs.net/lucid/intel.htm