Searching \ for '[PIC] Microchip AN851 16F87XA Bootloader.' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=16F
Search entire site for: 'Microchip AN851 16F87XA Bootloader.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Microchip AN851 16F87XA Bootloader.'
2005\05\05@100018 by Roberts II, Charles K.

picon face

Hello list

I was reading the app note for the 16F87XA boot loader and was wondering
if anyone on the list had used it before, and if so how did you take
care of the configuration memory? Did you set them to the desired levels
before you installed the boot loader? My understanding is that you can
not write the configuration memory with the 16F87XA boot loader.

The module I am working on will be installed in some hard to reach
places and I was thinking of adding the boot loader to my code to allow
software upgrades without moving the boards. IS this a good application
of the boot loader?

And how hard will it to be to add the boot loader to my existing code? I
used absolute code, will that help or hurt?

   
Charles K Roberts II



2005\05\05@112451 by Jan-Erik Soderholm

face picon face
Roberts II, Charles K. wrote :

> Hello list
>
> I was reading the app note for the 16F87XA boot loader and
> was wondering if anyone on the list had used it before, and if
> so how did you take care of the configuration memory? Did
> you set them to the desired levels before you installed the
> boot loader? My understanding is that you can
> not write the configuration memory with the 16F87XA boot loader.

I've got the impression that very few (any at all ?) bootloaders
can change whatever CONFIG settings that was made initialy (that
is, at the time the bootloader *itself* was programmed into the chip).

Why do you need to change the any config settings in-circuit ?
Most config settings are depending on the circuit the PIC is
used in.

> The module I am working on will be installed in some hard
> to reach places and I was thinking of adding the boot loader
> to my code to allow software upgrades without moving the
> boards. IS this a good application of the boot loader?

That *IS* the application of the bootloader. :-)
(Well, one of them, anyway...)

> And how hard will it to be to add the boot loader to my
> existing code? I used absolute code, will that help or hurt?

If you use some of the general purpose bootloaders, you
don't realy "add" it to your application. Your application
doesn't even (have to) *know* it was "loaded" that way.
Some bootloaders are 100% transparent, some might
need a few minor changes to the application code.

On the other hand, one can get some added functionality
if the bootloader is more integrated into the application,
such as only re-loading part of the app (maybe some
tables or other config info in program memory).

Jan-Erik.



2005\05\05@121631 by Byron A Jeff

face picon face
On Thu, May 05, 2005 at 09:59:57AM -0400, Roberts II, Charles K. wrote:
>
> Hello list
>
> I was reading the app note for the 16F87XA boot loader and was wondering
> if anyone on the list had used it before, and if so how did you take
> care of the configuration memory? Did you set them to the desired levels
> before you installed the boot loader? My understanding is that you can
> not write the configuration memory with the 16F87XA boot loader.

That's correct.

> The module I am working on will be installed in some hard to reach
> places and I was thinking of adding the boot loader to my code to allow
> software upgrades without moving the boards. IS this a good application
> of the boot loader?

There are others. You should peruse the Tiny Bootloader page before making
any decisions:

http://www.ac.ugal.ro/staff/ckiku/software/picbootloader.htm

It features Tiny and surveys other PIC bootloaders.

> And how hard will it to be to add the boot loader to my existing code?

It depends on the bootloader. Most load into high memory out of the way,
but some use low memory. Some require that you leave the first 3-4 memory
locations clear, while others (like Wouter's Wloader) will automagically
relocate any user code in those locations.

Integration depends on a lot of factors: the ones above, the hardware used
(such as a hardware USART for example), how much memory does the bootloader
occupy, how much error checking does it perform are all features that need
to be examined.

You brought another to the table: config memory. Simple for all 16F parts:
can't be done. However 18F parts can reconfigure their own config memories
programmatically. The question then becomes what happens when it glitches
are the wrong bits accidentlly get written to the config memory. You could
end up with a hard to access brick.

> I used absolute code, will that help or hurt?

It doesn't matter. Your code doesn't integrate with the bootloader. You have
to change your thinking. You are probably used to your code having total
control. But in a bootloader situation the bootloader gets first crack at
the system, and then delegates to the application code. They are not going
to be integrated most likely. You'll program the part with the bootloader,
test the bootloader out, then use the bootloader to load the applications
code. Note that the two pieces of software are not linked together in any
meaningful way.

Good luck in your search. I've had good luck with Wouter's bootloaders in
the past. If bootloading speed isn't an issue, and you really really want
to be able to change the config memory, consider using Wouter's ZPL loader
which uses no pins at all in a 18F part. You can find the description and
code in the development tools section at the bottom of this page:

http://www.voti.nl/dwarf

BAJ

2005\05\05@131758 by Wouter van Ooijen

face picon face
> Good luck in your search. I've had good luck with Wouter's
> bootloaders in
> the past. If bootloading speed isn't an issue, and you really
> really want
> to be able to change the config memory, consider using
> Wouter's ZPL loader
> which uses no pins at all in a 18F part.

Note: ZPL does *not* change the config setting.

When you think you want a bootloader to change config settings think
twice about *which* settings it would be allowed to change. As said,
most config settings are tied to the hardware around the chip, which is
not likely to be updated by the bootloader, or they are required for the
bootloading communication.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\05\05@133603 by Dave Turner

picon face
Umm...  How can it use no pins?

On 5/5/05, Wouter van Ooijen <spam_OUTwouterTakeThisOuTspamvoti.nl> wrote:
{Quote hidden}

> -

2005\05\05@143619 by Byron A Jeff

face picon face
On Thu, May 05, 2005 at 07:17:56PM +0200, Wouter van Ooijen wrote:
> > Good luck in your search. I've had good luck with Wouter's
> > bootloaders in
> > the past. If bootloading speed isn't an issue, and you really
> > really want
> > to be able to change the config memory, consider using
> > Wouter's ZPL loader
> > which uses no pins at all in a 18F part.
>
> Note: ZPL does *not* change the config setting.

Sorry Wouter,

I did mean to say that. It was my third thought relative to ZPL.
Must have gotten lost in the noise.

BAJ

> When you think you want a bootloader to change config settings think
> twice about *which* settings it would be allowed to change. As said,
> most config settings are tied to the hardware around the chip, which is
> not likely to be updated by the bootloader, or they are required for the
> bootloading communication.

Which is the reason for your design choice in ZPL.

However the 18F is capable of it. So if one really wanted to roll the dice
one could simply disable the address check in ZPL.

And that was the point I think I was trying to make.

BAJ

2005\05\05@145559 by Wouter van Ooijen

face picon face
> Umm...  How can it use no pins?

It uses no *I/O* pins. There are a few other pins to exploit, in this
case the /MCLR pin.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\05\05@152132 by Jan-Erik Soderholm

face picon face
Dave Turner wrote :

[Regarding Wouter's ZPL (zero pin loader) bootloader...]

> Umm...  How can it use no pins?

Well, it doesn't use any *normal I/O* pin.

All communication is through the MCLR pin, which
isn't used anyway as an I/O.

And how is that done ? You might ask...

The PC software resets the PIC using MCLR as usual.
Now, the *timing* between each reset is the key here.
By varying the time the PIC is left running *betwen* each
reset, you can transfer 1's and 0's between the PC and
ZPL in the PIC.

Clever...

Jan-Erik.



2005\05\05@161059 by Dave Turner

picon face
If it's contually resetting, how can it actually do any programming then?

On 5/5/05, Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl> wrote:
> > Umm...  How can it use no pins?
>
> It uses no *I/O* pins. There are a few other pins to exploit, in this
> case the /MCLR pin.
>
> Wouter van Ooijen
>
> -- -------------------------------------------
> Van Ooijen Technische Informatica: http://www.voti.nl
> consultancy, development, PICmicro products
> docent Hogeschool van Utrecht: http://www.voti.nl/hvu
>
> -

2005\05\05@172847 by Wouter van Ooijen

face picon face
> If it's contually resetting, how can it actually do any
> programming then?

Who says it's continuously resetting? The PC program that drives the
/MCLR (using the serial port for timing - yes, this will work OK with an
USB-serial converter) controls the time between resets, so it can
provide the PIC exactly (or in fact some more - the exact time required
is/was not documented, and some PC-driver related unceratinly has to be
taken into account) the time its needs.

And for the record: I did not *invent* this. I read somewhere that a
reset-based bootloader existed (IIRC for some 68HC chip) and that was
enough. The idea was out there, the method is obvious once you have the
idea. I just implemented it.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu



2005\05\05@173559 by Byron A Jeff

face picon face
On Thu, May 05, 2005 at 09:10:58PM +0100, Dave Turner wrote:
> If it's contually resetting, how can it actually do any programming then?

I hope Wouter won't mind me speaking for him. I dug into ZPL well enough that
I can explain it.

Wouter clocks in 64 bytes worth of data along with address information. No
programming during that time. Note that it isn't the length of the reset that
is measured, but the length of the execution of the chip before the reset
occurs. So consider this sequence (E is for execution, R for Reset)

EEEE R EE R EEEE R EEEE R EE R EE R EEEE R EE R

IF EEEE is a 1 and EE is a 0 then 10110010 gets clocked in.

Note that this system exploits the fact that a reset PIC that doesn't lose
power retains it RAM values across resets.

So once you've clocked in the address and data information, you then let the
PIC run for awhile. ZPL takes in the buffered data and programs the part.

Great system. No feedback or verification. But a great system.

BAJ
{Quote hidden}

2005\05\06@163027 by Mike Hord

picon face
> I was reading the app note for the 16F87XA boot loader and was wondering
> if anyone on the list had used it before, and if so how did you take
> care of the configuration memory? Did you set them to the desired levels
> before you installed the boot loader? My understanding is that you can
> not write the configuration memory with the 16F87XA boot loader.

I don't know about the 87xA portion, but I just adapted the 18F version
to my application on an 18F2320, so here are my observations:

1.  I'm not certain how truly well the app note, the PC software, and
the firmware match up.  That said, it does basically everything I need
it to do.

2.  The PC software has a config file which can easily be altered to
tell it where to start and stop writing, but regardless of the settings
there, the thing figures out where its own reset vector is and won't
write over it.  If you tell it to put its reset vector in location 0x001,
you can put your own application's reset vector in location 0x000.
That way, your app gets to decide when and if to bootload, rather
than the bootloader.  If that's what you want; Wouter scolded me
once for thinking that my application had to be aware of the
bootloader at all, and he's right, it doesn't.  With PBP, though, it
helps, because you never know where PBP is going to stick the
start of your code other than by the goto at 0x0000.

> The module I am working on will be installed in some hard to reach
> places and I was thinking of adding the boot loader to my code to allow
> software upgrades without moving the boards. IS this a good application
> of the boot loader?

That's my idea, too.  Just make certain that you can't trash the system
with an accidental entry into the bootloader.

> And how hard will it to be to add the boot loader to my existing code? I
> used absolute code, will that help or hurt?

In my case, I'm using PicBasic Pro.  I snooped a little but couldn't find
any real hard data about incorporating a bootloader, but a little investigation
showed that PBP puts a pointer at 0x0000 to the first line of user code,
goes about its business of loading its various libraries and such in the
first block of memory after the interrupt vector.  That's a problem, since
the bootloader wanted to go there.  Plus, the bootloader refuses to write
over its first memory location (it assumes that is the reset vector), so
upon reset, the bootloader always got first crack.  Usually not a problem,
but once into the bootloader, it became impossible to know for certain
where PBP had decided to stick the initialization code for my program.
The solution was to
alter the bootloader code to work in the last 256 words of memory
(replacing rcall with call and bra with goto, in some places, and changing
PCLATH to reflect the current memory location instead of letting it be
in the lower range) and start the whole thing at 0x0004.  That way, it
programs the PBP goto in location 0x0000, skips its own goto in 0x0004,
then continues to write the PBP code through the rest of the memory,
up until 0x1DFF.  The config file allows you to select the writable range;
tell it to stop before it overwrites itself, obviously.

Bottom line, it took me about 3 hours of fooling around to adapt this
to suit my own needs.  I'm sure a more experienced or skilled programmer
could have done it faster, but by both number of projects and time spent
on them, I'm barely a neophyte according to the standards of this list.

Mike H.

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...