MCLoader & XPort

[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

[Jumper]

I downloaded VB 2005 Express and it is way better than any other VB i have used. Support for COM port is back again and it is really easy to read HEX files either into byte arrays or to read the lines into a string array.

ReadAllText and ReadAllLines are really usefull functions

Since each line after the colon has the number of data bytes we can easily get the data bytes from the string. Just remember that they are stored LB, HB in the HEXFILE. Rearrange that part and send them out as a string to the comport.

In the pic collect them with HSERIN [HEX4 x] and they are ready to be written to the FLASH.

Do this for all lines until the next line in the HEX file has an address that is different from 16+last line's address, then we know we have gotten all data.

It can be done in any VB but in 6.0 and 2005 there is a comport object, 2003 does not have that.

and it is free

/me

[Joe Rocci]

Jumper,

Thanks for the insights.

I'm a VB6 sorta guy and I have the complete MS Visual Studio, so that's what I'll do the application in.

My previous comments about parsing the .hex file lines and padding the short ones might have been premature. I was thinking about how you'd implement this if the PIC was coded in assembler, in which case I believe you generally write 64 byte blocks. In that case, the file lines would have to be read, buffered, parsed, and disassembled & reassembled into the 64 byte chunks the PIC likes to work with before transmitting to the PIC. I still haven't figured out all the limitations of WRITECODE, but it seems to me that, assuming the intended write block has been ERASECODE'd, you can write one byte at a time? In this case, it's quite simple as you said, and data can be fed to the loader in chunks as small or big as it can buffer in RAM. Do you agree??

Joe

[Jumper]

Now here is where the 128 (in the beginning of the thread came in)

I get a string from the PC, erase the blocks and write the data. When this is ok I send a command to the PC to show we are ready for the next data chunk.

Then we can fiddle around in the PIC without missing any data.

So I just gathered the start address for the HEX file (in our case allways 0040) and the collected the data from the hex file and arranged it so it will fit the HSERIN HEX4. Then I feed out the characters from the string in as big pieces I want to have.

At the same time you can calculate a checksum for each chunk that the PIC will report back before sending next data. It is also possible to encode the string so only your loader will understand the data. With the code protection turned on the application software can not be copied (unless they break the code of your encrypted file, just pick any algorithm from the internet and it would't be easy to do)

Or invent you own "super safe" algorithm as the DVD people did :-) (not that good idea)

But at least we have solved the basics of how to trick PBP into making some kind of loader. Too bad we had to hijack the old define but, with our new loader who needs that define anyway. Then we can hope the really clever people in this forum might figure out a way to include our own defines.


/me

[Joe Rocci]

I got a little time today to work on the coding for the PIC end of this loader system. Programing entirely in PBP (with the exception of one line of assembler for the final 'GOTO" that starts the downloaded application), it looks like this loader will fit into about 600 bytes of PIC18 memory space - not as bad as I expected.

The down-side is that there are other loaders, coded in assembler, that are as small as 100 bytes. The up side is that this one's written entirely in PBP, is supportable by virtually anyone, and is therefore infinitely scalable for any desired level of functionality by anyone in this community.

In the coming days, I'll try to find time to write the VB6 host application that drives the loader. Once something that functions is available, I'll try to find a way to post the sources so that this can become an open-source, community supported tool.

Joe