MCLoader & XPort

[Jumper]

Sure it would be nice if all PIC's could be using this loader but:

How do we address the memory above 65535 ($FFFF) in READCODE and
WRITECODE when PBP only have 16-bit variables. It seems to me that Microchip has outgrown PBP, 32-bit variables in PBP would be nice.

ICSP is probably the way to go, unless it is done in ASM.

Let's start with the 64K devices and see if we run into any mines. We are still far from finished.....

/me

[Joe Rocci]

Good morning all!
(well morning my time...where is everyone else from?)

An update on the project so far:

1) We have a custom PBP DEFINE to specify where our bootloader should be in memory (needs to be checked further per Jumper's previous)
2) I've written and compiled test code with the new DEFINE, and the resultant program truly does locate where it should be and run properly
3) I wrote a little program that resides in 'remote' loader memory (ORG'd at 60160d) and writes a block of data to 'low' memory space starting at 0. This data block consists of 256 incrementing values starting at 0h and ending in FFh.

I'm having a small problem with the last part. The data that I read back from memory is correct for the most part, but every 8th memory location has a "0" instead of the correct value. I don't have the code in front of me to attach, but I'll send it when I get back to my office later this morning. Basically though, the sequence of events is:

A) Dump the 256 byte memory block to Hyperterminal using READCODE
B) Do a 64-byte block erase using ERASECODE
C) Rewrite each byte in the block just erased using WRITECODE
D) Repeat for a total of 256 bytes
E) Dump the re-written memory values to Hyperterminal

If you want to cogitate on this for a while and speculate on what I might be doing wrong, I'll get you with some more details later. I think that once we get through this, we're on our way!

BTW, in regard to programming bigger (>64K) parts, maybe we can fall back to using a little bit of embedded assembly code. Check out the OshonSoft web site for an example of how simple it can be:

http://www.oshonsoft.com/pic18bootloader.html


Joe

[Joe Rocci]

Ok, as promised, here is the code and the result that I described earlier:

CODE:

INIT: HSEROUt [$0D,$0A,$0D,$0A] 'Make space between display dumps
FOR I = 0 TO 255 step 16 'Dump 512 memory locations to screen
hserout [hex4(i), ":: "]
for j = 0 to 15 '16 bytes per line
READCODE (i+J),X
hserout [":", HEX2(X)," "]
next j
hserout [$0A, $0D] 'Line break after each line
next i
HSERin [x] 'Start on "L" from keyboard
if x="L" then
Goto Loader
ENDIF
'************************************************* ******************************
Loader:
for j = 0 to 255 step 64 'Erasecode does 64 bytes per block
erasecode j 'Erase a block
for i = 0 to 63 'Write 64 bytes
writecode i+j,i+j 'Write the block that was just erased
next i
next j 'Keep going until done

goto INIT 'Print out the result and wait




and here is a partial of the screen dump:

0000:: :00 :01 :02 :03 :04 :05 :06 :00 :08 :09 :0A :0B :0C :0D :0E :00
0010:: :10 :11 :12 :13 :14 :15 :16 :00 :18 :19 :1A :1B :1C :1D :1E :00
0020:: :20 :21 :22 :23 :24 :25 :26 :00 :28 :29 :2A :2B :2C :2D :2E :00
0030:: :30 :31 :32 :33 :34 :35 :36 :00 :38 :39 :3A :3B :3C :3D :3E :00
0040:: :40 :41 :42 :43 :44 :45 :46 :00 :48 :49 :4A :4B :4C :4D :4E :00
0050:: :50 :51 :52 :53 :54 :55 :56 :00 :58 :59 :5A :5B :5C :5D :5E :00

[Jumper]

This is a BAD example because we Erase the first block and can never enter the loader again after RESETTING the PIC.

But atleast this code writes what it should.


for i=0 to 4 'erase first 5 blocks
Flash = n*64
ERASECODE Flash
next i

for n=0 to 255
FLASH=n
WRITECODE FLASH, n
next n


I didn't really look into why, but your software does not write correctly. As I have said a million times:

DO NOT USE FORMULAS INTO READCODE AND WRITECODE

It just doesn't seem to work (no arrays, no cute stuff, nothing except as below!)

use ONLY a WORD variable for the address and a BYTE or WORD variable for DATA


/me

[Joe Rocci]

As I have said a million times:
DO NOT USE FORMULAS INTO READCODE AND WRITECODE
-------------------------

Sorry Jumper,
I wasn't around the first 999,999 times you said this. However imlementing it only in the WRITECODE part did seem to fix the problem.

Joe

[Jumper]

Glad it worked out, PBP has is hidden features :-)

Have you tried to write an application software starting from 64 yet? It would be fun to know if that part works with the new DEFINE.


/me

[Joe Rocci]

After fooling around all day trying to figure out why WRITECODE sometimes works properly and sometimes doesn't (see my other WRITECODE thread), I think I'm finally getting somewhere.

Using Jumper's suggestion for using DEFINE RESET_ORG 'X', I built a tiny program that loads into memory location 64 (40h). I then copied the object code from the hex file that resulted from compiling this little program and I inserted it into DATA statements in my loader program.

Also per Jumper's idea, I modified the LOADER_USED define in the .lib file so that it located the loader program high up in memory - at 60160 to be precise. My loader program reads the program bytes out of the EEPROM where DATA put them, and WRITECODEs them into their intended executable Flash memory locatinos starting at 64 (40h). It then uses an "@ GOTO 64" to jump to the "downloaded" program.

Eureka - It works!

So now the basic mechanisms are working. What has to be done next is to work out a data transfer protocol and write a small VB application to send the .hex file contents to the PIC. This won't be trivial I think, because each line of the hex file has to be parsed and a 'padding' scheme will have to be developed because not all lines of the .hex file are equal in length.

Thanks for the help Jumper. My available time to work on this will decline after this week but I fully intend to pursue it until it's complete

Joe