Bootloader for 16f87/88 that doesn't use UART

[bcd]

Hi Guys,

based on what I found in http://www.picbasic.co.uk/forum/showthread.php?t=4498 I set about modifying the PBPPIC14.LIB to move the library functions out of the low memory so we don't overwrite them when we upload a new programme. I was getting compilation errors about not being able to move the librarys off page 0, but commented out the warning section to see what happened.

Well the answer was - nothing. The programme appeared to not start (I have some LEDs to give me status). I set the library to start at 800 using a custom Make_Loader define that I had in my BL program and it works again.

Custom Define definition from PBPPIC14.LIB
<code>
ifdef MAKE_LOADER ; Added by Bill Coghill 08.01.08
LIST
ORG 800 ; Keep the library code out the way
NOLIST ; was 3584, but would then not work
endif
</code>

So it looks like we can't move the PBP libary files out of page 0 which means that we either need to see if we can jump over them with an ORG 128 (or similar - remember we can only erase blocks of 64 words).

What I need to do is see how big the PBP libraries are when I use an ORG to move the actual program code to high memory.

I wonder if only the Librarys that are used are compiled in ? That would mean if I was to use the bootloader with a skip over the libraries to upload a file that didn't use a library that the Bootloader needed that the next time you tried to go to bootloader mode it would hang the chip.

Just did a quick test and it seems that 153 words are needed for the library functions. But more testing reveals that PBP compiles in the Libs it needs, meaning that the value for the libs may change according to the commands used.

Oh dear and it was all going so well. I need to think about where we can go now.

We might end up loosing a lot of space as a skip at the beginning for the Libraries and 400 words for the BL at the end !!

bill.

[Jumper]

Well,

http://www.picbasic.co.uk/forum/showthread.php?t=4498 works.. but the hack you tried doesnt. The only way I have gotten this to work is to (as stated later in the thread)

ifdef LOADER_USED
LIST
ORG 60160 ; Own loader address depending how big loader you write
NOLIST
endif

And if you first write your bootloader and then you can change the address from where it starts to allocate just as much memory as it needs. By putting the bootloader last in the program space you also get less trouble with interupt vectors if you are using a 18-pic with high and low priority interupts. This is an ugly hack and dont forget to change back these things when you plan to compile your normal software.

/me

[bcd]

Jumper,

It seems the 16 series pics are different in how the libraries are assigned in memory space. I am going to look further in to it, but will try to mod the LOADER_USED jump as suggested.

stay tuned..

bill.

[bcd]

Well I did a bit more digging and talked to Jeff at MELabs.

This is what he told me :
<quote>
Jeff Schmoyer wrote:
Hello,

The problem is that you really can't do that. For the 14-bit
core parts, the library must be at the bottom of memory. The
bootloader has to be a completely separate program, including
its own library. This really isn't practical for a 14-bit
core part.

We did make a change for the PIC18 parts to allow the reset
location to be changed. This allows you to move the library
and the entire program up to higher memory. When you
boot load in a new program, it fills in at the bottom as
usual, with the bootloader and its library still up high.

For the 14-bit core parts, you will need to create an
assembler boot loader that does what you want, or modify
one of the many that are already out there.

To write one in PBP, you will need to move to a PIC18 part.

Thank you,
Jeff Schmoyer
microEngineering Labs, Inc.
</quote>

So it looks like it is back to reverse engineering other peoples ASM code to make it run in the 16F87. I am now going to look at the WLoader ASM and see how 'portable' it is to the 16F8x series.

Stay tuned...

bill.

[Charles Linquis]

This might be a silly question, but why not move to 18F parts and solve the problem that way?

[bcd]

Hi Charles,

I looked into using something like the 18F1320, but the HW UART pins have moved, which means a redesign of the PCB.

Wehn the product comes up for a design refresh I will look at moving to a new processor, but for now looks like I am stuck with the 16f87.

All is not lost as I think I can re-engineer the WLoader to work.

bill.

[skimask]

I looked into using something like the 18F1320, but the HW UART pins have moved, which means a redesign of the PCB.

You using DIP or SOIC?
If DIP, put one in a socket, pop out some pins and run some jumpers.
Not the best fix in the world, but works for me.
If SOIC, maybe cut some traces and run some jumpers.
Same thing, not the best, but it works.

[dhouston]

This might be a silly question, but why not move to 18F parts and solve the problem that way?

In my case, I want to use the internal comparators as inverters for the UART and I haven't found an 18F PIC in the same size range as the 16F88 that will let me do that.

[bcd]

Still looking in to this and I think I have found a way. Using the SparkFun BLoader code and a quick tutorial on bit-banged serial ports in C I am aiming to do a bit of testing this weekend.

Not as nice as a pbp based one, but if it works - woohoo !

bill.