Searching \ for '[PIC] Bootloader at top or bottom of memory.' 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/memory.htm?key=memory
Search entire site for: 'Bootloader at top or bottom of memory.'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Bootloader at top or bottom of memory.'
2007\02\21@101903 by Bob Axtell

face picon face
Without a tag, most people missed it.

(my comments below)

Forrest Christian wrote:
{Quote hidden}

Putting the bootloader at the top is common practice if the chip is
PIC16Fxxxx. PIC18FXXXX have
the ability to protect the bootloader in a special area and it can be
protected from EXTERNAL programming.

--Bob

2007\02\21@105047 by Wouter van Ooijen

face picon face
> Besides this, and perhaps a little bit of
> difference in .hex file generation (changing origins and the like), I
> don't really see the need to put the bootloader at the top of memory.

I dislike "difference in the .hex", so I like a bootloeader to be
transparent (invisible to the user, up to the limit of what is
achieveable). A top-memory BL can do this quite good, a bottom-memory BL
can't.

> Also, does write protecting this space gain you any real reliability,
> especially if you hack the bootloader not so it's not able to write to

> itself?  (Trying to see the disadvantage of putting the loader at the
> top as well).

For all situations where the BL code is not HW (fuses) protected there
is some possibility that the (malfunctioning?) user code overwrites the
BL. I guess that possibility is higher if there is self-writing code
present already.

> Experience with different loaders and their quality would be nice also
:)

I don't think there is much quality difference. Major differences are:
- size and other use of resources
- interface


Wouter van Ooijen

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


2007\02\21@110030 by Harold Hallikainen

face
flavicon
face

>> Besides this, and perhaps a little bit of
>> difference in .hex file generation (changing origins and the like), I
>> don't really see the need to put the bootloader at the top of memory.
>
> I dislike "difference in the .hex", so I like a bootloeader to be
> transparent (invisible to the user, up to the limit of what is
> achieveable). A top-memory BL can do this quite good, a bottom-memory BL
> can't.
>


Why can't a bottom-memory (low address, right?) bootloader avoid the
"difference in hex" problem? I've been using bootloader starting at
address 0. When compiling a new version, I compile with the bootloader and
with the appropriate linker script. I send out this hex file. The write
protect of the bootloader area prevents this area from being overwritten,
even though it is present in the hex file. I use the same hex file for
field updates (bootload) and production programming of raw chips.

Harold
(fan of bootloaders starting at address 0)

--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\02\21@114222 by Alan B. Pearce

face picon face
> I understand there is a slight interrupt latency increase due to the
> bootloader code having to jump to the real isr which won't be in the
> first 256 bytes of memory..  Besides this, and perhaps a little bit of
> difference in .hex file generation (changing origins and the like), I
> don't really see the need to put the bootloader at the top of memory.

Note that there is a "gotcha" if doing this with interrupt code.

The problem is that when entering the interrupt you do not know the state of
the PCLATH register when the interrupt occurs (assuming 16F series, haven't
yet played with 18F series, so don't know if the equivalent problem exists).

This means that BEFORE jumping the 256 bytes to the application interrupt
you need to

1. save W
2. save PCLATH
3. clear PCLATH
4. now you can do the 256 byte jump.

Bearing in mind that one needs to do all this anyway, it is not costing
anything except space in the 256 byte boatloader area. If the space is
available it may even be practical to have more of the "standard" interrupt
entry code there before doing the jump.

2007\02\21@120011 by Hector Martin

flavicon
face
Harold Hallikainen wrote:
> Why can't a bottom-memory (low address, right?) bootloader avoid the
> "difference in hex" problem? I've been using bootloader starting at
> address 0. When compiling a new version, I compile with the bootloader and
> with the appropriate linker script.
The idea is that some people like to be able to compile regular programs
as if the bootloader weren't there in the first place.

Personally, I've never used bootloaders. For a commercial app,
bottom-end bootloaders might be a better option due to the protection.
(This is the way I've seen them done). For prototyping and hobby usage,
top-end bootloaders are slightly more convenient, although I doubt it'd
be a problem to compile things using a modified linker script.


--
Hector Martin (spam_OUThectorTakeThisOuTspammarcansoft.com)
Public Key: http://www.marcansoft.com/marcan.asc

2007\02\21@130815 by Wouter van Ooijen

face picon face
> Why can't a bottom-memory (low address, right?) bootloader avoid the
> "difference in hex" problem?

You are right in the sense that you can construct .hex files that can be
run both standalone and with the bootloader, but this requires some
creativity from the user, which might not be all that easy when he uses
for instance a basic compiler which offers no control over the layout of
the .hex file.

What I probably should have said is that I like a bootloader to work
with a .hex file that was created without the bootloader in mind.

Wouter van Ooijen

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


2007\02\21@130819 by Bob Axtell

face picon face
Hector Martin wrote:
> Harold Hallikainen wrote:
>  
>> Why can't a bottom-memory (low address, right?) bootloader avoid the
>> "difference in hex" problem? I've been using bootloader starting at
>> address 0. When compiling a new version, I compile with the bootloader and
>> with the appropriate linker script.
>>    
> The idea is that some people like to be able to compile regular programs
> as if the bootloader weren't there in the first place.
>
> Personally, I've never used bootloaders. For a commercial app,
> bottom-end bootloaders might be a better option due to the protection.
> (This is the way I've seen them done). For prototyping and hobby usage,
> top-end bootloaders are slightly more convenient, although I doubt it'd
> be a problem to compile things using a modified linker script.
>
>
>  
I like the high-end bootloader because I like to use the space the ICD2
would use. My code then tests
for the bootloader "token" at a certain address, and if not present,
knows that the ICD2 is installed instead.
I make a habit of always reserving the last 256-word area for ICD2 or
bootloader even if never used.

Normally, I use ICSP anyway, but like the idea of being able to change
the firmware through the client website. I test
the bootloader as it powers up, and if it is present, I set a flag in
the EEPROM to that effect.


BTW, while on the bootloader subject: your bootloader should be capable
of installing new EEPROM values, because
frequently these need to be changed as well. I do this with a special
marker during self-programming. To confuse people,
I shift the bootloader code words coming in and  have a small lookup
table for a substitution cipher, so that the new firmware
download from a website is already keyed to that user, yet won't be the
same for each download...

I have been fascinated with Wouter's one-pin programmer... neat idea. I
already have a "manchester" coded diagnostic tool
scheme on one pin... maybe it can be made useful for a bootloader...

--Bob

2007\02\21@202453 by Forrest W. Christian

flavicon
face
I think I fully understand at this point, but let me make sure I
understand this correctly:

Wouter van Ooijen wrote:

>What I probably should have said is that I like a bootloader to work
>with a .hex file that was created without the bootloader in mind.
>
On init, the PIC jumps to 0x0000.  So, regardless, the actual
programmed, in-flash jump at this location has to be to the bootloader
wherever it is.

If the bootloader is in low memory, the actual .hex file has to be
linked such that it starts at say 0x0100, so that jumps and other
inside-code references are correct, since the real code cannot live
where the bootloader is.   Plus, it occurs to me that the whole ISR
thing is going to be a pain since you have to define a spot to jump to
within the bootloader, do all the fixup stuff, etc. etc. etc.

The only real advantage with a low-memory bootloader is that you can
hardware-protect the bootloader.  

If the bootloader is in high memory, the actual .hex file can be linked
such that it starts at 0x0000.  The only difference between in-flash and
the original hex copies are that the code between 0x0000 and 0x0003,
inclusive, needs to be moved elsewhere and replaced with a jump to the
bootloader.  The bootloader can take care of this.  Otherwise the hex
file and the flash copy are the same.   Code is much simpler to deal
with, and the only thing you really loose is the ability to
hardware-protect the bootloader.

If that is correct, I think the only two categories questions which
occur to me:

1) Assuming the bootloader code is perfect (well, at least well-tested
and written :), it sounds like hardware protecting the bootloader
doesn't really gain me all that much  Is this correct?   Mainly I'm
thinking of what is happening internally to the PIC, and if anyone
believes that there is any meaningful increase of risk to the bootloader
code itself if it is not protected - specifically in the case of an
internal PIC malfunction - I.E. a stray address bit or similar.   It
also appears that because the interrupt vector lives at 0x0004, and that
the self-programming devices generally erase more than 4 words at a
time, that the initial jump needs to be re-written each time you change
the code in the PIC.  This sounds like it might be asking for something
bad to happen.  Did I miss something?

2) Is it safe to assume that a typical compiler (.C, basic, whatever)
will include a jump within those first 4 instructions, or do some
compilers ignore the interrupt vector if it isn't used?   I don't see
this being likely, but it is possible.

Some of this thought process has given me the idea that I might not want
to write protect the bootloader - just so I can upgrade it through
software instead of having to drag out an ICD - which would require me
to actually populate the ICD headers on the boards.  Don't expect that
to occur a lot, but it is possible.

-forrest

2007\02\22@021931 by Wouter van Ooijen

face picon face
> 2) Is it safe to assume that a typical compiler (.C, basic, whatever)
> will include a jump within those first 4 instructions, or do some
> compilers ignore the interrupt vector if it isn't used?   I don't see
> this being likely, but it is possible.

I know for sure that the old Jal would not include a jump at 0 when no
interrupt routine was specified.

I think a rough consensus is that there are two main kinds of
bootloaders (transparent == no special care needed when creating the
.hex):

1) For general hobbyist use: should be transparent, almost invisible to
use.

2) For professional (production) use for a specific project: needs to be
write-protected, transparency is not an issue.

Side note: a few days ago someone asked me whether he could program a
PIC with only two wires. I responded that it is not possible: even for a
bootloader (stretching the term 'programming' a bit) you need ground and
power, plus a wire to carry data. Last night I was thinking about this
and I think I was wrong. Are there any PICs with an accessible internal
voltage reference (an absolute one, not one derived from Vdd)?


Wouter van Ooijen

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


2007\02\22@024854 by Vasile Surducan

face picon face
On 2/22/07, Wouter van Ooijen <.....wouterKILLspamspam@spam@voti.nl> wrote:

> Side note: a few days ago someone asked me whether he could program a
> PIC with only two wires. I responded that it is not possible: even for a
> bootloader (stretching the term 'programming' a bit) you need ground and
> power, plus a wire to carry data.

 AFIR, one of your bootloaders are working like this.


Last night I was thinking about this
> and I think I was wrong.

One choiche is a bootloader on USART without verifying algorithm implemented.
It will need just TX and ground and might work. Of course the
bootloader must be previously loaded somehow.


Are there any PICs with an accessible internal
> voltage reference (an absolute one, not one derived from Vdd)?

What is your point?

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

2007\02\22@025953 by Vasile Surducan

face picon face
On 2/22/07, Vasile Surducan <piclist9spamKILLspamgmail.com> wrote:
{Quote hidden}

Any pn junction reversed polarised becomes a voltage reference.
Unfortunately it needs more than 5V for this... and 6V which is still
a safe area for PIC VDD (please do not look in the datasheet,  this is
and experimental truth) it's still not enough.

Vasile

2007\02\22@034447 by Wouter van Ooijen

face picon face
> > Side note: a few days ago someone asked me whether he could
> program a
> > PIC with only two wires. I responded that it is not
> possible: even for a
> > bootloader (stretching the term 'programming' a bit) you
> need ground and
> > power, plus a wire to carry data.
>
>   AFIR, one of your bootloaders are working like this.

both WLoader and ZPL work this way, ZPL gets away with using MCLR as the
'data line'.

>  One choiche is a bootloader on USART without verifying
> algorithm implemented.
> It will need just TX and ground and might work. Of course the
> bootloader must be previously loaded somehow.

No, I was realy thinking about only two lines to the PIC, and no other
'outside world' connections (xtal yes, power no). So no cheating with a
separate power! (Xtal might not even be needed when the PIC has internal
OSC).

> Are there any PICs with an accessible internal
> > voltage reference (an absolute one, not one derived from Vdd)?
>
> What is your point?

That is left as an excercise for the reader :)

Hint: if you have only two wires, and these wires must carry power and
data, how could you encode the data on top of the power, and how can the
PIC decode this data?

Wouter van Ooijen

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


2007\02\22@041314 by Vasile Surducan

face picon face
On 2/22/07, Wouter van Ooijen <EraseMEwouterspam_OUTspamTakeThisOuTvoti.nl> wrote:
{Quote hidden}

Probably in many ways. One is using bipolar signal refering to PIC
GND. The positive
voltage will open the IO to VDD limiting diode and supply the PIC. A
capacitor between VDD and GND will accumulate the energy. That was the
supplying sequence.
A negative voltage will open the IO to GND voltage diode acting as low
level input
for the IO PIN.

However it hasn't any sense to design such a bootloader only if you do
not care too much about  your neurons.

2007\02\22@041928 by Alan B. Pearce

face picon face
>Hint: if you have only two wires, and these wires must carry power and
>data, how could you encode the data on top of the power, and how can the
>PIC decode this data?

Surely this would require a minimum of 2 extra components at the PIC, a
diode and a capacitor, so one can do a "one wire" type communication, while
having a capacitor to supply enough power to the PIC, and the diode to
isolate the capacitor from the "data" line while it is low.

I have a vision of some poor lackey in an Asian back room attempting to
reverse a Wouter designed system that is reprogramming the PIC using a "one
wire ZPL", and trying to figure out how it is done.

2007\02\22@051221 by Vasile Surducan

face picon face
On 2/22/07, Alan B. Pearce <A.B.Pearcespamspam_OUTrl.ac.uk> wrote:
> >Hint: if you have only two wires, and these wires must carry power and
> >data, how could you encode the data on top of the power, and how can the
> >PIC decode this data?
>
> Surely this would require a minimum of 2 extra components at the PIC, a
> diode and a capacitor, so one can do a "one wire" type communication, while
> having a capacitor to supply enough power to the PIC, and the diode to
> isolate the capacitor from the "data" line while it is low.
>
> I have a vision of some poor lackey in an Asian back room attempting to
> reverse a Wouter designed system that is reprogramming the PIC using a "one
> wire ZPL", and trying to figure out how it is done.

Alan, you have no ideea about what an asian could do. You need two
weeks of coreean or chinese air. ZPL was probably improved long time
ago and sold also...as well.
Try to change your opinion, and that old english atitude. The poor
lakey is as good as you...
:)

2007\02\22@052425 by Wouter van Ooijen

face picon face
> Probably in many ways. One is using bipolar signal refering to PIC
> GND. The positive
> voltage will open the IO to VDD limiting diode and supply the PIC. A
> capacitor between VDD and GND will accumulate the energy. That was the
> supplying sequence.
> A negative voltage will open the IO to GND voltage diode acting as low
> level input
> for the IO PIN.

that would be one way (similar to the Dallas one-wire when used with 2
wires, not 3). but I don't like the idea that the limiting diodes are
misused to carry all energy that is (lateron) used to program the flash.

> However it hasn't any sense to design such a bootloader only if you do
> not care too much about  your neurons.

I agree, this definitely falls in the category "why? because it can be
done!"

Wouter van Ooijen

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


2007\02\22@052855 by Wouter van Ooijen

face picon face
> Surely this would require a minimum of 2 extra components at
> the PIC, a diode and a capacitor, so one can do a "one wire" type
> communication, while having a capacitor to supply enough power
> to the PIC, and the diode to
> isolate the capacitor from the "data" line while it is low.

That would be a possibility, but not what I had in mind. I want to
connect *only* to the gnd and power pin(s) (assuming internal MCLR and
internal OSC). And yes, a capacitor on the power pins would still be
required.

Wouter van Ooijen

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


2007\02\22@072111 by olin piclist

face picon face
Alan B. Pearce wrote:
> Surely this would require a minimum of 2 extra components at the PIC,

Nope.  You should be able to create a bootloader for some PICs where the
only connections to the driving hardware are Vdd and Vcc without any
additional external hardware other than that required for the PIC to run in
its intended operating mode (like oscillator, MCLR high, PGM high).  I
haven't done it and don't plan to, but I'm pretty sure it is possible.

There are quite a few PICs where this is possible.  The 18F2520 is one
example.  On this PIC if MCLR is configured as a digital input, PGM is
disabled, and the internal oscillator is used, the only necessary
connections to the PIC are Vdd and Vss for the bootloader to function.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@072206 by Gerhard Fiedler

picon face
Wouter van Ooijen wrote:

> Are there any PICs with an accessible internal
> voltage reference (an absolute one, not one derived from Vdd)?

Yes. Look for "fixed voltage reference", "VP6EN", "VR" (as in voltage
reference, parameters VR01...VR04 -- mostly "TBD" :).

E.g. the 16F690 has such a 600mV reference. Works with comparators and can
be selected as ADC input.

Gerhard

2007\02\22@074847 by Nigel Duckworth

picon face
> Try to change your opinion, and that old english atitude.

The above statement is equally offensive.

Nigel Duckworth - Englishman


Vasile Surducan wrote

> Alan, you have no ideea about what an asian could do. You need two
> weeks of coreean or chinese air. ZPL was probably improved long time
> ago and sold also...as well.
> Try to change your opinion, and that old english atitude. The poor
> lakey is as good as you...
> :)
>  

2007\02\22@075604 by Wouter van Ooijen

face picon face
> > Surely this would require a minimum of 2 extra components
> at the PIC,
>
> Nope.  You should be able to create a bootloader for some
> PICs where the
> only connections to the driving hardware are Vdd and Vcc without any
> additional external hardware other than that required for the
> PIC to run in
> its intended operating mode (like oscillator, MCLR high, PGM high).  I
> haven't done it and don't plan to, but I'm pretty sure it is possible.

I am not sure I will do it anytime soon (before my retirement, which is
a long way off), but I am equaly sure it is possible.

As for components needed: I was thinking of an ICSP-like situtation with
relatively long wires from programmer to PIC, so a 100nF power
decoupling would be needed. If the wires can be short (ZIF-style
'programming') two connections to the PIC (gnd and power, both might
need multiple pins) should be enough.

Wouter van Ooijen

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


2007\02\22@075607 by Wouter van Ooijen

face picon face
> > Are there any PICs with an accessible internal
> > voltage reference (an absolute one, not one derived from Vdd)?
>
> Yes. Look for "fixed voltage reference", "VP6EN", "VR" (as in voltage
> reference, parameters VR01...VR04 -- mostly "TBD" :).
>
> E.g. the 16F690 has such a 600mV reference. Works with
> comparators and can be selected as ADC input.

I knew it existed somewhere. Now I must find a PIC that also can write
its flash.

Wouter van Ooijen

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


2007\02\22@082128 by John Chung

picon face
Try looking up X10 on it's implementation. After some
thought it is a very good exercise to do :)

John


--- Wouter van Ooijen <@spam@wouterKILLspamspamvoti.nl> wrote:

{Quote hidden}

> --

2007\02\22@082654 by Alan B. Pearce

face picon face
>> Surely this would require a minimum of 2 extra components at the PIC,
>
>Nope.  You should be able to create a bootloader for some PICs where the
>only connections to the driving hardware are Vdd and Vcc without any
>additional external hardware other than that required for the PIC to run in
>its intended operating mode (like oscillator, MCLR high, PGM high).  I
>haven't done it and don't plan to, but I'm pretty sure it is possible.

Yes, I see where Wouter is coming from. I guess this method could be used
with any device that his ZPL will run on, though I suspect it may need some
changes to allow for bootup time.

Still amuses me with the thought of someone somewhere attempting to reverse
engineer the product using the process. (How does the code load, only the
supply is being switched ... ???)

2007\02\22@083247 by Michael Rigby-Jones

picon face


{Quote hidden}

Olin,

I remember that someone (Wouter?) managed to do a one wire bootloader by toggling MCLR. The GPR's in a PIC (mid-range at least) are not changed by a reset, which means you can store state/program data information between resets.  This would obviously not be the case if you were toggling Vdd, so I would be interested into how such a bootloader could be realised if you are willing to divulge your scheme.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2007\02\22@084123 by olin piclist

face picon face
Wouter van Ooijen wrote:
>> E.g. the 16F690 has such a 600mV reference. Works with
>> comparators and can be selected as ADC input.
>
> I knew it existed somewhere.

But that's not what you want since it requires some external parts.  Two
resistors are required best I can tell.  As I said before, I think it can be
done with the 18F2520 without *any* specific external parts for the
bootloader.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@084803 by olin piclist

face picon face
Alan B. Pearce wrote:
> Yes, I see where Wouter is coming from. I guess this method could be
> used with any device that his ZPL will run on,

No I don't see how.  The ZPL requires 3 connections, this method only 2.
Consider RAM retention voltage.  I'm also assuming a rule is that each
uploaded FLASH location will only be written once and no algorithm state is
allowed to be kept in the flash.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@085432 by Wouter van Ooijen

face picon face
> Try looking up X10 on it's implementation. After some
> thought it is a very good exercise to do :)

I am not aware of any zero-parts X10 receivers, which would be
equivalent to what I was talking about: a PIC that can bootload over
just 2 wires (Ok, maybe one 100nF decoupler).

Wouter van Ooijen

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


2007\02\22@085520 by olin piclist

face picon face
Michael Rigby-Jones wrote:
> I remember that someone (Wouter?) managed to do a one wire bootloader
> by toggling MCLR.

No, that's either a 2 or three wire bootloader depending on how you look at
it.  The driving hardware must be conntected to GND and MCLR, and the PIC to
GND, Vdd, and MCLR.

I'm talking about a bootloader where only Vdd and GND need to be connected
to the PIC.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@090333 by Wouter van Ooijen

face picon face
> I remember that someone (Wouter?) managed to do a one wire
> bootloader by toggling MCLR.

http://www.voti.nl/dwarf/zpl.zip

> The GPR's in a PIC (mid-range at
> least) are not changed by a reset, which means you can store
> state/program data information between resets.  This would
> obviously not be the case if you were toggling Vdd

Who said that you must toggle Vdd? Think a bit less digital, a bit more
analog. And remember that I asked for PICs
- that can write their Flash
- have an internal absolute (not Vdd-derived) voltage reference
- (I did not say, but this is needed too) have an AD or internal
comparator (some brownout detectors might do too)

Wouter van Ooijen

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


2007\02\22@090759 by Cristóvão Dalla Costa

picon face
On 2/22/07, Olin Lathrop <spamBeGoneolin_piclistspamBeGonespamembedinc.com> wrote:
>
> Alan B. Pearce wrote:
> > Yes, I see where Wouter is coming from. I guess this method could be
> > used with any device that his ZPL will run on,
>
> No I don't see how.  The ZPL requires 3 connections, this method only 2.
> Consider RAM retention voltage.  I'm also assuming a rule is that each
> uploaded FLASH location will only be written once and no algorithm state
> is
> allowed to be kept in the flash.


As long as the GPRs retain their states between resets you could use BOR to
supply the resets while mantaining  Vdd above retention voltage.

2007\02\22@091440 by Wouter van Ooijen

face picon face
> But that's not what you want since it requires some external
> parts.  Two
> resistors are required best I can tell.  As I said before, I
> think it can be
> done with the 18F2520 without *any* specific external parts for the
> bootloader.

I think you are right, but with a detection mechanism that is a bit
different from what I had in mind.

Wouter van Ooijen

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


2007\02\22@091928 by Wouter van Ooijen

face picon face
> I'm also assuming a rule is that each
> uploaded FLASH location will only be written once and no
> algorithm state is
> allowed to be kept in the flash.

that is a reasonable assumption, otherwise the stress on the flash would
make it impractical

Wouter van Ooijen

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


2007\02\22@092137 by olin piclist

face picon face
"Cristóvão Dalla Costa" wrote:
> As long as the GPRs retain their states between resets you could use
> BOR to supply the resets while mantaining  Vdd above retention voltage.

Exactly.  The brownout reset voltage is above the RAM retention voltage.
Others were talking about using the A/D or comparator with a internal fixed
reference, but I don't think the Vdd level can be sensed that way without
some external connections or parts.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@092804 by Timothy J. Weber

face picon face
Wouter van Ooijen wrote:
> Who said that you must toggle Vdd? Think a bit less digital, a bit more
> analog. And remember that I asked for PICs
> - that can write their Flash
> - have an internal absolute (not Vdd-derived) voltage reference
> - (I did not say, but this is needed too) have an AD or internal
> comparator (some brownout detectors might do too)

I thought you were talking about passing the signal by varying Vdd.  The
internal reference is used to distinguish between two supply voltage
levels, signifying "0" and "1".
--
Timothy J. Weber
http://timothyweber.org

2007\02\22@092847 by Wouter van Ooijen

face picon face
> > I have a vision of some poor lackey in an Asian back room
> attempting to
> > reverse a Wouter designed system that is reprogramming the
> PIC using a "one
> > wire ZPL", and trying to figure out how it is done.
>
> Alan, you have no ideea about what an asian could do. You need two
> weeks of coreean or chinese air. ZPL was probably improved long time
> ago and sold also...as well.

If the aim was to give a reverse engineer a nice time I would choose a
Very Slow Bootloader, Non-Contact version. The target circuit would
contain some obfusciated way to measure temperature (for instance
watchdog-timeout measurement) and the bootloader interface would be a
peltier heater/cooler.

Wouter van Ooijen

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


2007\02\22@101907 by Bob Axtell

face picon face
Alan B. Pearce wrote:
>> Hint: if you have only two wires, and these wires must carry power and
>> data, how could you encode the data on top of the power, and how can the
>> PIC decode this data?
>>    
>
> Surely this would require a minimum of 2 extra components at the PIC, a
> diode and a capacitor, so one can do a "one wire" type communication, while
> having a capacitor to supply enough power to the PIC, and the diode to
> isolate the capacitor from the "data" line while it is low.
>
> I have a vision of some poor lackey in an Asian back room attempting to
> reverse a Wouter designed system that is reprogramming the PIC using a "one
> wire ZPL", and trying to figure out how it is done.
>
>  
I have been intrigued about using an IR diode emitter/rcvr pair as a
bootloader tool.

--Bob

2007\02\22@103159 by Bob Axtell

face picon face
Timothy J. Weber wrote:
> Wouter van Ooijen wrote:
>  
>> Who said that you must toggle Vdd? Think a bit less digital, a bit more
>> analog. And remember that I asked for PICs
>> - that can write their Flash
>> - have an internal absolute (not Vdd-derived) voltage reference
>> - (I did not say, but this is needed too) have an AD or internal
>> comparator (some brownout detectors might do too)
>>    
>
> I thought you were talking about passing the signal by varying Vdd.  The
> internal reference is used to distinguish between two supply voltage
> levels, signifying "0" and "1".
>  
I controlled a robot this way once. I varied the 24V power line at about
10 hz to 22V, and the robot
in the sewer line extracted the data for control purposes. It had
problems as the tether got too long
(more than 300m) due to plain ole IR losses.

--Bob.

2007\02\22@103653 by Alan B. Pearce

face picon face
>I have been intrigued about using an IR diode emitter/rcvr
>pair as a bootloader tool.

"I'll just put this little box on the bench beside the Wotsit XT7000, and
we'll go and organise payment. I'll pick the box up when we get back, and
the job will be done.

Fine, how much do we owe you?

Oh, that will be $4972 plus taxes please.

BUT YOU HAVEN'T DONE ANYTHING !!!!!!!!!!!!"

2007\02\22@104027 by Harold Hallikainen

face
flavicon
face
I did, I think, an interesting bootloader for the IQ512M
(http://www.dovesystems.com). The bootloader reads hex code off an MMC/SD
card. The socket is already present for the operation of the rest of the
system. The bootloader is written in asm and does not use FAT16, while the
rest of the system is written in C and DOES use FAT16. The hex code to be
bootloaded is put on the MMC/SD as a text file on a newly formatted card.
On starting the IQ512M, if the user is holding down a couple buttons on
power up, the system scans the MMC/SD starting at sector 0 looking for an
identifying string added to the start of the hex file. On finding it, it
reads through the hex file, checking the checksum on each line. If ok, it
goes back to the start of the hex file and actually bootloads it to flash.

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\02\22@105951 by Byron A Jeff

face picon face
On Thu, Feb 22, 2007 at 09:23:20AM -0500, Olin Lathrop wrote:
> "Crist?v?o Dalla Costa" wrote:
> > As long as the GPRs retain their states between resets you could use
> > BOR to supply the resets while mantaining  Vdd above retention voltage.
>
> Exactly.  The brownout reset voltage is above the RAM retention voltage.
> Others were talking about using the A/D or comparator with a internal fixed
> reference, but I don't think the Vdd level can be sensed that way without
> some external connections or parts.

You'd have to use an I/O pin in that case to connect Vdd to the comparitor
or ADC input.

However, I'm not sure that violates Wouter's original specifications or not.
The original spec IIRC stated that only two wires for power and GND were
allowed to go to the PIC. He constrasted that with ZPL which required a
a 3 wire connection (power,GND,MCLR).

It's unclear in the original spec if either of the two incoming wires are
allowed to be connected to a PIC I/O pin. Considering Wouter's drive for
transparency, it's probably not the intent to connect the power and GND
wires to anything other than Vdd and Vss pins on the PIC, but as I said
I think it's unclear.

Olin's proposal would seem to work for quite a few PICs. I just took a
quick look at the (of course preliminary) electrical specs for the 16F88X
series parts. Brown out has a minimum voltage of 3.7V while RAM retention
is only 1.5V. So enabling BODEN and simply modulating Vdd between 3.5V and
5V should be well more than enough to cause the part to reset. Implementing
Wouter's ZPL with BODEN enabled should be sufficient to get things going.

It would be a true zero pin loader because absolutely no I/O pins would be
used in the operation. And since MCLR (and the CLK pins) can be repurposed
as I/O (input only in the MCLR case), your truly get a a bootloadable part
that can dedicate 36 I/O pins on a 40 pin part to the application.

BTW Wouter, one small improvement I always thought that ZPL could use was
a "reset frame" bit. I think it would add a bit more reliability to the
loader because the loader would know when a new frame was coming down the
pipe. It could be as simple as an intermediate timed bit between the zero
and one times implemented.

So on to the hardware. What's the simplest way to cleanly vary a serial
signal between 3.5V and 5V with sufficient power to program a PIC?

BAJ

2007\02\22@111330 by Mike Harrison

flavicon
face
On Thu, 22 Feb 2007 08:32:26 -0700, you wrote:

>Timothy J. Weber wrote:
>> Wouter van Ooijen wrote:
>>  
>>> Who said that you must toggle Vdd? Think a bit less digital, a bit more
>>> analog. And remember that I asked for PICs
>>> - that can write their Flash
>>> - have an internal absolute (not Vdd-derived) voltage reference
>>> - (I did not say, but this is needed too) have an AD or internal
>>> comparator (some brownout detectors might do too)
>>>    
>>
>> I thought you were talking about passing the signal by varying Vdd.  The
>> internal reference is used to distinguish between two supply voltage
>> levels, signifying "0" and "1".

I did this a while ago - data in was by modulating the supply voltage ( referenced to the 5V
regulator), and data out was via a red LED that was already there. This was for configuring data in
an eeprom before the days of flash PICs but the same technique could be used now for firmware.

In fact you can do it with out an absolute reference as you can use transitions on the supply (i.e.
it looks for a sudden change, not an absolute value), the reference being the capacitor-decoupled
logic supply which doesn't move as fast.

2007\02\22@111557 by Mike Harrison

flavicon
face
On Thu, 22 Feb 2007 15:36:39 -0000, you wrote:

>>I have been intrigued about using an IR diode emitter/rcvr
>>pair as a bootloader tool.

I've used this in the past on a sealed product in a waterproof case - just an IR LED, a
phototransistor & a couple of resistors. Easy to get a data rate about 10kbits/sec.
For minimum power it used very short pulses, a bit like irda, with a start pulse and the
presence/absence of a pulse in a bit slot indicating 0/1.

2007\02\22@112733 by Mike Harrison

flavicon
face
While we're on the subject of bootloaders, there is an alternative technique I did a while ago that
has some advantages in specific applications.
If your application _already has_ a reasonable size eeprom or flash ( > the program memory size),
and some way to read/write to it via whatever interface is present, then you can  use this existing
comms infrastructure to write and verify the new code to the eeprom/serial flash, and then call an
extremely small  loader that simply copies the ee/flash to program memory.

This is particularly useful for where there is very little space for a loader ( e.g. 16F818), as you
are sharing a lot of code (comms/ee read/write) that already exists in the main application. It can
be done (just) in 32 words on a16F818.
It is also very useful where the comms protocol is complex (i.e. would take disproportionate space
if implemented in a traditional bootloader), or where the comms is very slow or has poor reliability
(you can take as long as you like to write the flash/eeprom image before committing to programming)

There is a marginal risk of problems if power fails during the programming phase, but this is a very
small time window, and even then there are things that can be done to recover if you are
particularly paranoid.

see http://www.electricstuff.co.uk/picavrstuff.html#The%2032-word*%20Bootloader
for more info and a 16F818/ST serial flash example.


2007\02\22@113055 by John Chung

picon face



--- Olin Lathrop <TakeThisOuTolin_piclistEraseMEspamspam_OUTembedinc.com> wrote:

{Quote hidden}

I don get you. Is there a PIC that can live without
MCLR? Pardon my question since I don dwell in a wide
range of PICs.

John



____________________________________________________________________________________
It's here! Your new message!  
Get new email alerts with the free Yahoo! Toolbar.
tools.search.yahoo.com/toolbar/features/mail/

2007\02\22@113822 by Bob Axtell

face picon face
Alan B. Pearce wrote:
>> I have been intrigued about using an IR diode emitter/rcvr
>> pair as a bootloader tool.
>>    
>
> "I'll just put this little box on the bench beside the Wotsit XT7000, and
> we'll go and organise payment. I'll pick the box up when we get back, and
> the job will be done.
>
> Fine, how much do we owe you?
>
> Oh, that will be $4972 plus taxes please.
>
> BUT YOU HAVEN'T DONE ANYTHING !!!!!!!!!!!!"
>
>  
<G>

Well actually, keeping the upgrade medium secret might have strategic
value... I like
even better the emitter that is a standard visible LED and a receiver
that is a standard
visible LED, too...

After all, the cold war is beginning to heat up; the Democrats have
grabbed Congress
again. Soon it will be Un-American to use standard incandescent bulbs,
poo-poo Global
Warming, and  make fun of Hillary anymore... keeping the truth safe will
become a constant
chore...

--Bob

2007\02\22@115555 by Alan B. Pearce

face picon face
>I don get you. Is there a PIC that can live without
>MCLR? Pardon my question since I don dwell in a wide
>range of PICs.

Yes, there are several PICs where the MCLR line can be configured as an
input. It is not available for use as an output though.

It means that there is no external reset line on the PIC, the only way to
reset it is to power it off. There are also various recommendations about
using the internal reset timer to ensure that the power supplies have
settled before the PIC starts processing.

Have a look at the 16F627/628/648 as an example.

2007\02\22@130434 by Gerhard Fiedler

picon face
Olin Lathrop wrote:

> Wouter van Ooijen wrote:
>>> E.g. the 16F690 has such a 600mV reference. Works with
>>> comparators and can be selected as ADC input.
>>
>> I knew it existed somewhere.
>
> But that's not what you want since it requires some external parts.  Two
> resistors are required best I can tell.  

Not really, if I understand both of you correctly. With the 16F690, it is
possible to select the internal 600mV reference voltage as input for the
ADC and read it with Vdd as ADC reference. This gives a measure for Vdd
based on the internal reference voltage, without any external parts.

Gerhard

2007\02\22@132739 by Wouter van Ooijen

face picon face
> I have been intrigued about using an IR diode emitter/rcvr pair as a
> bootloader tool.

Definitely feasible. Now for the real challenge: use a pair of common
RED leds...

Wouter van Ooijen

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


2007\02\22@133254 by olin piclist

face picon face
Byron A Jeff wrote:
> So on to the hardware. What's the simplest way to cleanly vary a serial
> signal between 3.5V and 5V with sufficient power to program a PIC?

A USBProg would work well for that ;-)
Tie the PGC and PGD outputs together and set Vdd to 5V.  That gives you 0V,
2.5V, and 5V with about 75 ohm output impedence.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.

2007\02\22@135440 by Wouter van Ooijen

face picon face
> > Others were talking about using the A/D or comparator with
> a internal fixed
> > reference, but I don't think the Vdd level can be sensed
> that way without
> > some external connections or parts.
>
> You'd have to use an I/O pin in that case to connect Vdd to
> the comparitor or ADC input.
> However, I'm not sure that violates Wouter's original
> specifications or not.

I think Olin worded what I had in mind perfectly: "no components needed
that are specific for the bootloader" (except of course what is on the
other side of the 2 wires, and the target circuit must tolerate the
wiggling of the power).

> The original spec IIRC stated that only two wires for power
> and GND were
> allowed to go to the PIC. He constrasted that with ZPL which
> required a
> a 3 wire connection (power,GND,MCLR).

What I had in mind was a PIC that has an internal absolute reference
that can be used as A/D or comparator input (using Vdd as AD reference).
The 16F690 seems to have such an absolute (0.6V) reference, but it can't
write its Flash.

Wouter van Ooijen

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


2007\02\22@150336 by Wouter van Ooijen

face picon face
> > I'm talking about a bootloader where only Vdd and
> > GND need to be connected
> > to the PIC.
> >
> I don get you. Is there a PIC that can live without
> MCLR? Pardon my question since I don dwell in a wide
> range of PICs.

There are lots of PICs that can be configured to have an I/O (actually I
only) pin instead of /MCLR.

Wouter van Ooijen

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


2007\02\22@215624 by John Chung

picon face
Thanks for the info guys.

John


--- Wouter van Ooijen <RemoveMEwouterspamTakeThisOuTvoti.nl> wrote:

{Quote hidden}

> --

2007\02\23@020441 by Vasile Surducan

face picon face
On 2/22/07, Nigel Duckworth <nduckworthEraseMEspam.....compuserve.com> wrote:
> > Try to change your opinion, and that old english atitude.
>
> The above statement is equally offensive.

Please accept my appologizes. You have right.

Vasile

{Quote hidden}

> -

2007\02\24@085309 by Byron A Jeff

face picon face
On Thu, Feb 22, 2007 at 07:21:24AM -0500, Olin Lathrop wrote:
> Alan B. Pearce wrote:
> > Surely this would require a minimum of 2 extra components at the PIC,
>
> Nope.  You should be able to create a bootloader for some PICs where the
> only connections to the driving hardware are Vdd and Vcc without any
> additional external hardware other than that required for the PIC to run in
> its intended operating mode (like oscillator, MCLR high, PGM high).  I
> haven't done it and don't plan to, but I'm pretty sure it is possible.
>
> There are quite a few PICs where this is possible.  The 18F2520 is one
> example.

I just figured out the other key parameter. BODEN and PWRTMR have to be
decoupled for it to work.

Unfortunately this isn't universal. I checked on the 16F887, and the two
are coupled. On the 18F2520, they are decoupled. I then check the 16F88
and found that they are also decoupled. Weird as the 16F88X is a newer family
of parts.

>  On this PIC if MCLR is configured as a digital input, PGM is
> disabled, and the internal oscillator is used, the only necessary
> connections to the PIC are Vdd and Vss for the bootloader to function.

So you need the following:

1) Nanowatt enabled
2) BODEN enabled with low ram retention voltage (seemes to be 4.35V and 1.5V
respectively for all the sheets I checked)
3) Decoupled BODEN and PWRTMR

Now as to how to drive Vdd, I think an old Steve Ciarcia circuit could do
the trick. He used a LM317 adjustable voltage regulator and switched in
different resistor values to vary the voltage. IIRC he said that the signal
was clean switching up to 20 kHz though it's probably been 20 years since
the last time I read that article.

So it should be simple. Here's the adjusted formula for the LM317

R2 = R1((V/1.25)-1)

Say R1 is 330 ohms. So to get 5V

R2 = 330((5/1.25)-1)
R2 = 990 ohms.

So a 1K resistor gets us to 5.04V. We'll probably need E96 1% tolerance parts

Now what would we need for 3.5V?

R2 = 330((3.5/1.25)-1)

R2 = 594 ohms.

Now that's not the resistor we need. In order to ensure that the LM317 doesn't
drift above 5V we'll want to switch in a resistor in parallel with the 1K
resistor for 5V so that the total is 594 ohms. So

1/594 = 1/1000 + 1/R3

R3=1463 ohms

Where does a 1.5Kohm resistor put us? It gives an combined 600 ohms which
gives a total switched voltage of 3.72V. That's a bit too close to the lower
edge of the BOD. The E96 1% range has 1470 ohms. What about that? It comes
in just above 3.5V. Since the BOD kicks in at the 4.3V or so range and we
have so much RAM retention voltage latitude, for simplicity it may be better
to drop the parallel resistance therefore lowering the switched output voltage.
If we use a second 1K resistor, then the combined resistance is 500 ohms and
the output voltage is 3.14V. So that limits us to only getting two different
resistor values (330 and 1K).

Now Ciarcia used a 7407 OC buffer for the switch, but he needed to switch
in several different resistor values. Since we only need to switch in exactly
one value, a transistor switch should be fine.

Couple it with Wouter's excellent idea from ZPL of driving the timing from
a serial port, which addes a diode and a base current limiting resistor, and
you have a done deal.

The only problem I see left is the internal oscillator stabilization. I
don't know it well enough to be clear if the oscillator remains stable through
a BOD reset. Any thoughts?

The thought of bootloading a 16F88 without any I/O pins used is fascinating.
Also with the BOD you have a clear reset path too.

I'm only bummed out because the 16F887 doesn't decouple BODEN and PWRTMR. That
would have been the perfect target for me.

BAJ

2007\02\24@091301 by Byron A Jeff

face picon face
On Sat, Feb 24, 2007 at 08:53:06AM -0500, Byron A Jeff wrote:
> On Thu, Feb 22, 2007 at 07:21:24AM -0500, Olin Lathrop wrote:
> > Alan B. Pearce wrote:
> So you need the following:
>
> 1) Nanowatt enabled
> 2) BODEN enabled with low ram retention voltage (seemes to be 4.35V and 1.5V
> respectively for all the sheets I checked)
> 3) Decoupled BODEN and PWRTMR

I missed the obvious which is the part needs to be self programmable.

> I'm only bummed out because the 16F887 doesn't decouple BODEN and PWRTMR. That
> would have been the perfect target for me.

Now I'm confused. I'm almost certain that I read for the 16F887 that the 72ms
PWTTMR would be invoked on a BOD regardless of if the bit were set or not.
Wistfully I pulled the datasheet again (a different one?) And found this on
page 210 (emphesis mine):

"The Power-up Timer will now be invoked, IF ENABLED and will keep the chip in
Reset an additional 64 ms."

Now that's excellent news! I must have been reading a different data sheet
because note this line says 64 mS and I know I read a page that said 72 mS.

To program, just wiggle the power line. Wow!

BAJ

2007\02\24@094944 by Bob Axtell

face picon face
Byron A Jeff wrote:
{Quote hidden}

for F88: WHAT reg/bit is tested to determine the voltage bit HI or LO?
is it BOD? What is the procedure to determine a
data flag that means "go to programming mode?" I have some ideas, but
you guys are heavy hitters... what
happens next?

--Bob

2007\02\24@114058 by Byron A Jeff

face picon face
On Sat, Feb 24, 2007 at 07:48:21AM -0700, Bob Axtell wrote:
{Quote hidden}

A quick explanation of how Wouter's Zero Pin Bootloader (ZPL) works. It
measures the run time between resets. To clock a zero bit you run for
a short length of time, for a one bit your run for a longer bit of time
before resetting. Since memory is retained between resets you can simply read
the count of the previous runtime when you reboot. Based on that count you
clock in a one or zero bit.

The ingenious part is Wouter's tying of the bit time to the serial port, which
because of its async nature must be precisely timed.

I made a PDF of Wouter's original ZPL entry. You can find it here:

http://www.finitesite.com/d3jsys/zpl.pdf

The basic idea is that the chip runs normally when the TX line of the serial
port is idle and resets when a zero bit is sent. So the start bit and any
subsequent zero bits on TX resets the PIC.

Wouter constructs specific characters that causes a precise run time.
For example the pattern.

IIII S 1 0 111111 s IIII

Where I-idle (a 1 bit on TX), S-Start (a zero bit), s-stop(a 1 bit)

The part runs normally until the start bit, which resets it. It then
starts running again for the run time of the one 1 bit after the start bit,
is reset for the next cell and then runs normally for the rest of the
character including the stop bit and subsequent idle.

If we count the run time after the stop bit we get a precise count. Say for
the sake of argument it's 30. Now compare to this pattern...

IIII S 11 0 11111 s IIII

Note that it runs twice as long after the start bit. So the count should
be around 60.

So the run time can be used to clock in bits. Personally I also wanted a
special "reset packet" bit. Something like:

IIII S 111 0 1111 s IIII

So that the part knows when a new packet is starting.

BTW the run time after the mid character reset is the time used to determine
the previous bit and to clock it in.

> is it BOD?

Nope. All resets will be BOD resets.

> What is the procedure to determine a
> data flag that means "go to programming mode?"

Wouter's idea was simple. Any extremely long run times was considered to be
normal operation. Only super short run times are considered to be programming
operations.

> I have some ideas, but you guys are heavy hitters...

Wouter's the heavy hitter here. I'm just an interested interpreter.

> what happens next?

Truthfully Wouter has already done the hard part. There's already a working
ZPL implementation for the 18F family done. You can find his original
entry here:

http://www.circuitcellar.com/flash2002/Honorable/M285.zip

I'm not sure if he has an update. The only small change here is that we're
switching from a pin based reset to a BOR based reset. Another problem is
the fact to ensure a BOR based reset you have to drop the voltage for a minimum
of 100 uS. That means you'd have to slow the serial port down to 9600 BPS to
ensure cells that are 100 uS long. However I guess you could simply double or
triple faster cells to ensure that the resets are 100 uS. So instead of a
9600 BPS character of S 1 0 111111 s you could double the speed to 19200 and
52 uS cells and send S 0 1 00 1111 s and S 0 11 00 111 s. Wouter's original
PIC ran at 115.2k with 8.7 uS cells so the 5 cell runtime after the midcell
reset was 40 uS. The runtimes here are 250 uS and 200 uS, which should be
enough time. The good thing is that the reset frame bit I'd like to have
is easily implementable with S 0 111 00 11 s. Still an absolute full 32k
write to an 18F would take upwards of 7 minutes @ 19.2k based on Wouter's
timing of 70 seconds @ 115.2k. So it wouldn't be the fastest programmer on
the block.

Hope this helps,

BAJ

2007\02\24@132328 by Bob Axtell

face picon face
Byron A Jeff wrote:
{Quote hidden}

Good explanation. I assumed Wouter's ZPL scheme was manchester code
(falling edge begins/ends a new bit,
bit time measured, if pulse width was > 50% it was a ONE, less than 50%
it was a zero, which is also
what I use as a production diagnostic tool). Thanks for a GREAT explanation.

My production diagnostic tool  is more than 7 years old. ONE PIN is
dedicated as a diagnostic I/O. When
powerup happens with that pin held LOW, diagnostic info is requested;
when left OPEN (HI) nothing happens.
Diagnostic information is usually about 80 bits of information, a
three-bit "start flag" , and a 20% gap.
Speed ranges from 0.5mS/bit to 5ms/bit; this code is NOT time-critical
except within the bit itself, so it works
perfectly with RC-based products. I used it first on a PIC16C54
robot-controller product.

Normally the diagnostic data includes each of the port regs, each of the
TRIS regs, and several critical internal
registers, and each product uses different registers. Since 80 bits is
only 9 8-bit registers, the idea is to allow a
monitoring technician clues as to why the product is not (or is) working
properly. For PICs with A/D converters,
verifying the  A/D values  also verifies the VDD as a secondary result.

To pickup the data, I used an old DOS machine at first, but a PIC works
better, because the DOS tick interrupt  causes problems
at some speeds. Later I designed a small PCB with a PIC on it that
retreived the data and sent it on to a 9600b
Windows host. Very small, about the width of a DB9 connector but very
powerful. On most systems, it stole GND and 5V
from the running device.

So I was originally thinking about expanding that system to perform
bootloading functions as well....

--Bob


'[PIC] Bootloader at top or bottom of memory.'
2007\03\05@093259 by Howard Winter
face
flavicon
picon face
Bob,

On Thu, 22 Feb 2007 08:32:26 -0700, Bob Axtell wrote:

{Quote hidden}

I do hope you found this out before it was 300m into a sewer pipe!  :-)  Since the losses should have been pretty-much proportional at the 24V and
22V levels, shouldn't it have been possible to carry on with this method, with variable-level sensing?  Or did the difference deteriorate as well as the
actual levels?

Cheers,


Howard Winter
St.Albans, England


2007\03\05@102001 by Bob Axtell

face picon face
Howard Winter wrote:
{Quote hidden}

The problem had to do with robot DC motor load. The motor would affect
the cable drop significantly enough to begin to obscure the data. Had
the cable been less lossy it still would have worked anyway. But there
was a limit in allowable cable size.

Today I would have used NiMH batteries in the robot to provide the
driving load, and the cable was just a charging cable. But this was 20
years ago, back in the dark ages.

--Bob

--Bob
> Cheers,
>
>
> Howard Winter
> St.Albans, England
>
>
>  

2007\03\05@104516 by Harold Hallikainen

face
flavicon
face
I'm thinking of MAYBE writing a bootloader in C for the 24H series of
chips. I'd put all my C initialization main() and the bootloader code in
the write protected boot area of the chip and put the application (called
by main()) outside that area. Interrupts, exceptions, etc. would point to
a jump table outside the boot area.

Sound practical?

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com - Advertising
opportunities available!

2007\03\05@110330 by Alan B. Pearce

face picon face
>Interrupts, exceptions, etc. would point to
>a jump table outside the boot area.

I haven't checked the architecture, but can you do a jump from the vector
location to the jump table without needing to save anything first, like you
do on the 16F series (because you need to set PCLATH before the jump) ?

2007\03\05@111032 by Wouter van Ooijen

face picon face
> I'm thinking of MAYBE writing a bootloader in C for the 24H series of
> chips. I'd put all my C initialization main() and the
> bootloader code in
> the write protected boot area of the chip and put the
> application (called
> by main()) outside that area. Interrupts, exceptions, etc.
> would point to
> a jump table outside the boot area.
>
> Sound practical?

Main issues with a bootloader (which you do not mention) are:
- how do you communicate with it
- how is deceided whether at startup the bootloader or the app gets
control

Is 24H also limited to 1k (guaranteed) flash rewrites?

Wouter van Ooijen

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


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