Searching \ for '[PIC]: In Circuit Programming - 16F877 using MCLR' in subject line. ()
Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'In Circuit Programming - 16F877 using MCLR'.

Exact match. Not showing close matches.
'[PIC]: In Circuit Programming - 16F877 using MCLR '
2002\03\11@122328 by

Here is one basic idea of how it can be done:

The boot loader times ON periods -- ie: how long it can run before it is
reset. Each ON time is a "Baud" which can encode several bits.

If the ON period is > 1 second then we assume that we are running the actual
application and branch to it.

If the ON period is > 3/4 but less than 1 second then we assume that we are

Following the pulse with an ON period of  > 3/4 seconds we send several
pulses exactly 1/8 second long. These are timed by the boot loader to
establish a baseline for how long a 1/8 second pulse will look to it (after
appropriate oscillator start up etc.)

4. Now you can send multiple bits per reset by computing an interval between
1/8 and 3/8 of a second. For example, to send 4 bits per reset, stored in
the variable 'b', you could compute the interval as:

1/8 + b/64 seconds

The number of bits sent per interval is limited by the resolution of the
timing, as well as the tolerance of the clock frequency.

Well, Wouter, is that close to what you had in mind?

Bob  Ammerman
RAm Systems

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

It takes care of the problem of startup (por, etc) that I kept wondering

I suspect that a pic with a crystal/resonator could reliably receive
more than 7 bits per reset if the MCLR isn't loaded too badly with other
circuitry...  Hmmm...  Since the pulses are going to be multiples of a
certian time period, a smarter bootloader would track error and correct
for it.  The programming time will be a long time, and the chip may warm
up over that time.  With a crystal it wouldn't be a problem, but we may
as well make it harder and plan on programming rc driven pics.  Temp can
change a lot over 10 minutes...

Bob Ammerman wrote:

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

> Well, Wouter, is that close to what you had in mind?

Of course. As someone (you?) said: once you know something si possible is it
is not hard to find out how, because the guy who came up with the idea has
the same set of basic knowledge as you have. Worked that way for me when

I wonder what baud rate could be achieved, maybe 1 .. 10 kb with 3 bits per
baud? The clock is already running, no power-up-timer etc, so the
on-period-timing should be pretty accurate. When I hive some time (read: not
likely to be soon) I might give it a try.

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

At 04:09 PM 3/11/02 +0100, wouter van ooijen & floortje hanneman wrote:

>I wonder what baud rate could be achieved, maybe 1 .. 10 kb with 3 bits per
>baud? The clock is already running, no power-up-timer etc,

I had written earlier that you probably had to take into account the
oscillator start-up timer.  But I've just taken a much closer look at the
data sheet (ds30292c pg 124) and see that I was mistaken.  Sorry about that!

dwayne

Dwayne Reid   <dwaynerplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
.-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
`-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Note that by the nature of this scheme not all bauds are created equal. Some
will take less time than others. I wonder if that could be taken advantage
of...

You could also have an 'out-of-band' signal by using extra long bauds, for
example to indicate that no more data is coming.

I wonder how reliable this could be and whether any sort of forward error
correction would be needed to really get it to work.

Bob Ammerman
RAm Systems

{Original Message removed}
Bob Ammerman wrote:
>
> Note that by the nature of this scheme not all bauds are created equal. Some
> will take less time than others. I wonder if that could be taken advantage
> of...
>
> You could also have an 'out-of-band' signal by using extra long bauds, for
> example to indicate that no more data is coming.
>
> I wonder how reliable this could be and whether any sort of forward error
> correction would be needed to really get it to work.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesbubblesoftonline.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

No verification, at least no external acknowledgment. The bootloader should
assure that the application is started only when all data is received and
application starts, the loading must have been succesfull. You must have a
way to check that the application is running, but that should not be too
hard. You can not expect too much from a zero-IO-pin interface....

Wouter van Ooijen
--
Van Ooijen Technische Informatica: http://www.voti.nl

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

wouter van ooijen & floortje hanneman wrote:
>
>
> No verification, at least no external acknowledgment. The bootloader should
> assure that the application is started only when all data is received and
> application starts, the loading must have been succesfull. You must have a
> way to check that the application is running, but that should not be too
> hard. You can not expect too much from a zero-IO-pin interface....

I suppose with checksums etc it should be doable.

I was wondering if you would have more luck clocking the OSC1 pin after
a reset.

That way it's possible to know exactly what code your boot loader should
be executing.

You might get faster transfers knowing this.

--
Best regards

Tony

mICros
http://www.bubblesoftonline.com
salesbubblesoftonline.com

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

----- Original Message -----
From: "Tony Nixon" <Tony.NixonENG.MONASH.EDU.AU>
To: <PICLISTMITVMA.MIT.EDU>
Sent: Monday, March 11, 2002 1:42 PM
Subject: Re: [PIC]: In Circuit Programming - 16F877 using MCLR only

> Bob Ammerman wrote:
> >
> > Note that by the nature of this scheme not all bauds are created equal.
Some
> > will take less time than others. I wonder if that could be taken
> > of...
> >
> > You could also have an 'out-of-band' signal by using extra long bauds,
for
> > example to indicate that no more data is coming.
> >
> > I wonder how reliable this could be and whether any sort of forward
error
> > correction would be needed to really get it to work.
>

With a FEC scheme you could be quite sure the chip got the right stuff. If
the design contains any user interface elements at all (LED, LCD, etc) then
an LED, or some such.

Bob Ammerman
RAm Systems

{Quote hidden}

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

Just drive the MCLR line from a suitably clamped serial port output from a
PC.

The idle state of the serial port will hold MCLR low.

Generating a timed break can be used to allow long runtimes, for example to
routine to run (greater than 1 second).

Sending an ordinary character, the start bit will raise MCLR, then the width
of the pulse can be controlled from 1 unit to 9 units by controlling the
number of consecutive low-order 0 bits in the byte.

This would let you send 3 bits per async character.

Bob Ammerman
RAm Systems

{Original Message removed}
At 08:42 AM 3/12/02 +1100, Tony Nixon wrote:

I suspect there may some confusion regarding this: it may be the same
confusion I initially suffered from.

Wouter said "bootloader", I thought "programmer".  Specifically, ICSP
programmer using only MCLR.  Big difference!  He was accurate in his post,
I was careless in reading it.

Olin's post made it clear to me that this was a bootload technique, not a
general purpose ICSP programmer.  I mean: it can be an ICSP programmer, but

As such, I don't think that verification is required.  A CRC or checksum
would be a good idea, as would an error routine that causes the target
system to warn the user that the code transfer did not work correctly.  But
the bootloader itself should be able to take care of verifying that each
location was programmed correctly and to re-try if does not program correctly.

dwayne

Dwayne Reid   <dwaynerplanet.eon.net>
Trinity Electronics Systems Ltd    Edmonton, AB, CANADA
(780) 489-3199 voice          (780) 487-6397 fax

Celebrating 18 years of Engineering Innovation (1984 - 2002)
.-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-.   .-
`-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'   `-'
Do NOT send unsolicited commercial email to this email address.
This message neither grants consent to receive unsolicited
commercial email nor is intended to solicit commercial email.

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
email listservmitvma.mit.edu with SET PICList DIGEST in the body

>I suppose with checksums etc it should be doable.
>
>I was wondering if you would have more luck clocking the OSC1 pin after
>a reset.
>
>That way it's possible to know exactly what code your boot loader should
>be executing.
>
>You might get faster transfers knowing this.

How about moving the goal posts slightly. Use a timed reset to put the
device into programming mode as per someone's 3/4 sec - 1sec suggestion, and
then the programming code uses normal pins to do the communication, e.g. the
on board uart, or it could be any pair of pins.

Using this method one could also have a "timed reset to enter ICD mode" :)

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

{Quote hidden}

I've been following this thread with interest, a bootloader that just uses
MCLR is very appealing.  However, I can't see how the bootloader would
differentiate a valid reset (from e.g. a rest button or supervisor) from a
bootloading attempt.  If you have to use another pin to test for "run" or
"bootloader" mode, then the whole thing seems a little pointless and you may
as well use an existing loader.  Of course it's more than likely I'm missing
something blatantly obvious.

Cheers

Mike

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> I've been following this thread with interest, a bootloader that just uses
> MCLR is very appealing.  However, I can't see how the bootloader would
> differentiate a valid reset (from e.g. a rest button or supervisor) from a

Timing.  If MCLR is left high long enough, the bootloader will run the main
code if it passes the checksum test.

********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

The data is encoded by how long you leave it running between reset.
Typically when reseting, a person doesn't press the reset button multiple
times with 1/4 to 3/4 of a second spacing (unless they're taking anger out
on the chip, in which case they deserve to mess up its programming ^_^).

-Aaron

{Quote hidden}

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

Okay, I've spent some time thinking of an MCLR only boot loader driven
directly by a suitably clamped EIA232 port. My original thought was to use a
pulse width encoding, encoding from 0 to 7 low order zero bits in each byte
sent in order to transmit 3 data bits per aync byte transmitted. After
reflection, I came up with a scheme that gives my 4 data bits per async
byte, plus a few convenient special cases.

In the following charts a line of the form

1 xxxxxxxx 0 - 0x?? - y,y - zzzz

is interpreted as follows:

1 represents the start bit

xxxxxxxx represents the eight data bits of a byte, least significant bit
first (because that is the order they are transmitted by the UART, and with
each bit complemented (becuase a zero bit in the register results in a
positive voltage on the line).

0 represents the stop bit

0x?? is the actual hex value that would have to be sent, in normal bit order

y,y is the decoded pulse width(s) as seen by the PIC. Note that the PIC
computes a pulse width as: bit-times-between-resets minus 1.

zzzz is the actual decoded codes in normal bit order (the decoded bit pairs
are loaded in to the LSBits of a byte under construction). After four such
pairs have been processed a full byte has been received.

The first 16 codes allow us to send to pulses which each decode to a 0, 1, 2
or 3. Thus we can send four bits with each code:

1 00001000 0 - 0x10 - 0,0 - 0000
1 00001100 0 - 0x30 - 0,1 - 0001
1 00001110 0 - 0x70 - 0,2 - 0010
1 00001111 0 - 0xF0 - 0,3 - 0011

1 10001000 0 - 0x11 - 1,0 - 0100
1 10001100 0 - 0x31 - 1,1 - 0101
1 10001110 0 - 0x71 - 1,2 - 0110
1 10001111 0 - 0xF1 - 1,3 - 0111

1 11001000 0 - 0x13 - 2,0 - 1000
1 11001100 0 - 0x33 - 2,1 - 1001
1 11001110 0 - 0x73 - 2,2 - 1010
1 11001111 0 - 0xF3 - 2,3 - 1011

1 11101000 0 - 0x17 - 3,0 - 1100
1 11101100 0 - 0x37 - 3,1 - 1101
1 11101110 0 - 0x77 - 3,2 - 1110
1 11101111 0 - 0xF7 - 3,3 - 1111

A very useful special case allows us to send a whole zero byte with a single
byte. This is because the bootloader will treat this byte as 4 pulses, each
of which decodes to zero:

1 01010100 0 - 0x2A - 0,0,0,0 - 00000000

It is often useful to have 'escape' codes on a communication link, often
used to frame messages, or to set the remote end to a known state. We can
send 'escape' codes by sending bytes which result in pulses that decode to
numbers greater than 3:

1 11110000 0 - 0x0F - 4 - escape code 1
1 11111000 0 - 0x1F - 5 - escape code 2
1 11111100 0 - 0x3F - 6 - escape code 3
1 11111110 0 - 0x7F - 7 - escape code 4
1 11111111 0 - 0xFF - 8 - escape code 5

This is only 22 of the possible 256 codes that can be sent. Many of the
others would be interpreted redundantly with those above. For example:

1 01000000 0 - 0x02 - 0,0 - 0000

is another way to send four zero bits.

Others could be used to extend the escape code set. For example:

1 11110100 0 - 0x2F - 4,0 - escape code 1A
1 11110110 0 - 0x6F - 4,1 - escape code 1B
1 11110111 0 - 0xEF - 4,2 - escape code 1C

There are also some combinations that would let you output 6 bits in one
byte. For example:

1 01010000 0 - 0x0A - 0,0,0 - 000000
1 10101000 0 - 0x15 - 1,0,0 - 000001

There are even a few combinations that give you eight full bits (including
the 00000000 case above). For example:

1 01101011 0 - 0xD6 - 0,1,0,1 - 00010001

Depending on how sophisticated you wanted to get with the encoder you could
take advantage of these funny encodings to optimize the transfer rate.

Note that the PIC side of the code doesn't care about any of the funny
encodings. All it sees are simple pulses on MCLR which it has to time. Each
such pulse will always be decoded into a bit pair (pulse widths of 1 through
4), an escape code (pulse widths of 5 through 9) or a special command
indicated by a very long pulse. Two such commands could be:

-  Use next 2 pulses to calibrate timing. This would be followed by pulses
of length 1 and 4 (a byte of 0xF0). This would establish and offset and
scale for the pulse width to encoded value computation.

- Let application run if checksum is valid. This would be the case where
MCLR remained high for a protracted period of time.

Bob Ammerman
RAm Systems

--
http://www.piclist.com hint: To leave the PICList
piclist-unsubscribe-requestmitvma.mit.edu

> -----Original Message-----
> From: Olin Lathrop [SMTP:olin_piclistEMBEDINC.COM]
> Sent: Tuesday, March 12, 2002 5:40 PM
> To:   PICLISTMITVMA.MIT.EDU
> Subject:      Re: [PIC]: In Circuit Programming - 16F877 using MCLR only
>
> > I've been following this thread with interest, a bootloader that just
> uses
> > MCLR is very appealing.  However, I can't see how the bootloader would
> > differentiate a valid reset (from e.g. a rest button or supervisor) from
> a
>
> Timing.  If MCLR is left high long enough, the bootloader will run the
> main
> code if it passes the checksum test.
>
>
Right, I kind of understood that.  What I was thinking of was the
possibility of a series of genuine reset pulses (caused by e.g. a a ropey
supply) being interpreted as a programming attempt.  I suppose that if the
checksum/CRC was made robust enough this should be a problem.

Regards

Mike

--