v9-40

Received the following email (VERY IMPORTANT - READ THIS BEFORE BURNING
BOOTLOADER - FAILURE TO SET THE BROWN OUT RESET BIT WILL RESULT IN THE PIC
POSSIBLY DYING!!)

Dear Shane,

Although I'm still very positive about the PIC16F877 boatloader I have recently
expierenced a very nasty side effect I think others should know about it before
they start using it for their rocket detonators, breathing devices etc.

At the research institute where I work, I have added the bootloader to the
firmware of about a 100 sensors. This has proven to be very handy for field
upgrading, changing calibration tables etc.  But after a while sensors started
coming back. When I readback the code, I noticed a few bits of code had changed.
Very scary !!!

So I spend some of time finding the cause. I made a little 'spurious write
detection' program that compares the lower half of the code memory with the
upper half where I put a mirror of the code. When I programmed this into a
PIC16F877 (using ICD2) and connected the device to a 'very very dirty power
supply' I carried out the following experiments:

- with a bootloader, Brownout Detect (BOR)=off, Power Up Timer=off, LVP=on:
spurious writes after a just few power interrupts;

- without bootloader, same config setting: no problem after many power
interrupts;

- with bootloader, with BOR on: also no problems after many power interrupts;

Conclusion: never use this bootloader with the BOR switched off!

I think you should put this warning very loud and clear to all the user of this
bootloader.

Kind Regards,

Herman Aartsen.
---end email---

No assembly code changes since v9-30; only the recommendation to set BOR (Brown
Out Reset) if you can get away with it. Note that unless the PIC is running at
+5V, you may not be able to set the BOR bit, or else the PIC continually resets
in some cases. For this reason, and others (namely that on the PIC18F4550 that
one cannot reset the code protection fuses unless the PIC is running at >4.5V)
it is recommended that all PIC16F and PIC18F devices are run at at least +5V
rather than a lower voltage. Strange but true.

- Shane Tolmie (www.microchipc.com).

v9-30

Shane Tolmie told me, that some users of my bootloader modification had problems
with "quad alignement" when using C-compilers (I use primarily MPLAB assembler).
Now I have fixed the problem with quad alignment, but the bootloader code is
increased by about 100 bytes.

The new bootloader version (1.2) can be downloaded from
http://www.htl-steyr.ac.at/~huep/bootldra.htm

Best regards and enjoy the code
Peter Huemer

--email--

Fixed quad-alignment bug in 16F87xA version:

Display all headersTo: picbootloader@yahoogroups.com
From: "reactivate_now"
Date: Sun, 06 Jun 2004 10:12:01 -0000
Subject: [picbootloader] Workaround for trouble with PIC16F87XA devices!
Reply-To: picbootloader@yahoogroups.com

Hello,

First of all, this bootloader rocks! Saved me hours of debugging!

I think there is indeed a bug in Shane's bootloader when using it
with PIC16F87XA devices and there is a 3 in 4 chance that you will
encounter it :-). When you have a hex file with a non multiple of 4
opcodes, the bootloader won't work!

non-working example:
:040000008A01252824
:080008008A110A1242284A285D
:1000100056289828DF280B29142927293A2942290C
:10002000532964297529962999299C29A429AC2941
:10003000BD29C52983120313A20000308A00253090
:10004000220703188A0A2208820704308316031342
:1000503086008030870083129F010630D3

working example:
:040000008A01252824
:080008008A110A1242284A285D
:1000100056289828DF280B29142927293A2942290C
:10002000532964297529962999299C29A429AC2941
:10003000BD29C52983120313A20000308A00253090
:10004000220703188A0A2208820704308316031342
:100050008500F03086008030870083129F010630D3


The datasheet specs that:
1) you MUST write the FLASH in groups of 4 words.
2) When not writing 4 WORDS you MUST READ the non-written words so
you don't overwrite them
I assume that the bootloader sins against one of these rules,
hopefully the authors have an idea were it can be.

Workaround: very simple, make sure you always have a multiple of 4
opcodes in the hex file and it works! Simply add some nops somewhere
to fill it up. With an editor you can easily see how many opcodes you
have to add to have a nice alignment in the hex file at the end.

Hope this works for you!
greets,

G

[if anyone can fix this bug and post it to me, it would be great!
- webmaster[at]microchipc.com][Many thanks to Peter Huemer <p.huemer@eduhi.at>
for this fix.]

v9-20

added bootloader written in MSVC

v9-0

Added 16F87xA compatible bootloader.

v7-6

Turned BODEN off so b/l can be used with low voltage parts.

v7-41

Enhanced the "test serial port" routines to support processors with 128 bytes of
EEPROM, and a wider range of crystal speeds.

Updated file structure of distribution download to make it easier to navigate.

Moved all files into a directory structure. Updated to remove references to
16F872 - it has no hardware serial UART and therefore will not work. Updated
documentation.

v7-3

Assembly bootloader updated, released as v2-2.  Now with smaller size, and reset
of UART and TIMER1 after bootloading, and passes on watchdog parameters.

v7-2

v1-08 of PICdownloader.exe released - now automatically opens the .hex file
specified on the command line.

This is an excellent time saver, you set the editor to open the downloader with
your new file after compilation.  One user reported using PBPro and Microcode
Studio (from www.mecanique.co.uk) as the editor. It allows you to set your
programmer and or bootloader and associated parameters to open those up
automatically after compilation.

v7-10

Made a few minor changes to the documentation.  This version has been up on the
website, with thousands of downloads, and theres remarkably few tech support
requests which I havnt been able to solve with a simple answer.


v7 (beta)

This version is different to v6.52 in that all .hex files provided are from the
assembly language of the bootloader.  Previous version was from C language
version of bootloader.


Whats new
---------

The first 4 instructions in .hex file at 0x0000 to 0x0003 do *not* have to have
a long jump with zeroed PCLATH, as in v6.52 and below.


Known untested portions:
------------------------

PIN option in assembly language program untested.
Havnt tested with PIC16F870-1-2 (its a simple 0x1000 to 0x700 change).

v6.52

Current version.

