I have just had a great deal of fun and excitement in moving from P16F84 to
P16F84A devices. Thanks Microchip.
At first when the A version was programmed and plonked in my circuit it
appeared to work ok. But with some testing strange things happened. Writing
a simple test program and circuit will still show this problem.
1) Firstly though I also have problems programming the A version. Using
a parallel port programmer and the PIX software. The configuration fuse does
not always get programmed. I have too use the 'program fuse' button
separately which works. Weird!
2) Using an A version placed into a breadboard. Supply +5v. 2 x 10K sil
resistor packs to pull up Port B RB0 to RB3 and RA2 to RA4 and MCLR. The
other pins configured as outputs. RC oscillator mode, R=3K9 C=33pf. And the
code below programmed and run. Linking any of port B RB0 to RB3 repeatably
to 0v will cause RA4 to switch high/low.
Next. Place 100nf miniature polyester Cap from any of RB0 to RB2 to
0v and repeatably short any of RB0 to RB3 to 0v and RA4 will switch.
All fine so far.
Now place the 100nf on RB3 to 0v and short RB3 to 0v repeatably.
Crash! The pic will lockup or all the ports will oscillate (??).
If you monitor the RA4 output on a scope. You should see some
glitches when you switch RB3 with the cap attached.
I spent a couple of evenings trying to find what was happening. But I yet to
find out why. This weird effect happens with three different A versions but
is fine with the non A versions.
Would some kind soul try the same circuit out with the attached code, Both
with A and non A 16F84. It would be nice to know if it's a problem with all
A versions, or just mine, or just me. The code is in its simplest form ,no
labels defined or macro's or stuff.
LIST p=16F84, r=hex
__CONFIG 3FF3 ; RC mode, No Protect, No WDT, PWRTE on
BCF 3,5 ; Bank 0
CLRF 05 ; Clear PORT A
CLRF 06 ; Clear PORT B
CLRF 0B ; Clear INTCON register 0000,0000
BSF 3,5 ; Bank 1
MOVLW 88 ; No weak pull ups, Prescaler to WDT (Not
used)
MOVWF 01 ; Set Options register
MOVLW 0F ; Set Tri-State settings RA0 to RA3
as input, RA4 as output
MOVWF 05 ; Tris A
MOVLW 0F ; Tri-state for Port B RB0 to RB3
as input, RB4 to RB7 as output
MOVWF 06 ; Tris B
BCF 3,5 ; Bank 0
here
MOVF 6,W ; Read port B
ANDLW 0F ; Keep RB0 to RB3
XORLW 0F ; Are all high? (Z=1 if yes)
BTFSC 3,2 ; Skip if Zero clear
BSF 5,4 ; Set RA4
BTFSS 3,2 ; Skip if zero set
BCF 5,4 ; Clear RA4
GOTO here ; Loop
END
Please reply both direct to me and the list, as I receive the list in digest
form so will not get your replies until tomorrow otherwise.
Many thanks in advance
Regards
Clive Frederickson
R&D Technician (CECF Group)
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
The new Dyson Root8Cyclone(TM) vacuum cleaner is the
most powerful upright available.
Like all Dyson cleaners the Root8Cyclone(TM) maintains
constant suction. Dyson scientists have developed the
Root8Cyclone(TM) to give higher suction power and pick up
more dust. It will be available from June 2001 in the UK.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
> BCF 3,5 ; Bank 0
>
> CLRF 05 ; Clear PORT A
> CLRF 06 ; Clear PORT B
> CLRF 0B ; Clear INTCON register 0000,0000
Use the include file and mnemonic register names! Looking for bugs in this
code is a complete waste of time until you follow reasonable coding
practices. Then you also don't have to waste the comments on explaining
the instruction, but spend them instead on explaining the purpose of the
instruction.
The code below was written deliberately without using include files, labels
definitions etc, To absolutely ensure that no oddities were going on also it
does not require anybody else who tries the code to have the same header
files or include files. (In case they are not using MPLAB, And some do not!)
The program is also small and simple. The problem is not a code/software
problem. But appears to be a hardware problem with the PIC and RB3.
I started with a working program that was using include files, macro etc. A
program that has been in use in over 200 finished units that have been
working happily for up to 3 years (so far). This same code in the same
circuit using an A revision chip fails to function correctly. I ended up the
simple code to prove it was not me but the PIC. (I was convinced it was me
and did everything I could to prove it was not before settling for the PIC
as the cause.)
> BCF 3,5 ; Bank 0
>
> CLRF 05 ; Clear PORT A
> CLRF 06 ; Clear PORT B
> CLRF 0B ; Clear INTCON register 0000,0000
Use the include file and mnemonic register names! Looking for bugs
in this
code is a complete waste of time until you follow reasonable coding
practices. Then you also don't have to waste the comments on
explaining
the instruction, but spend them instead on explaining the purpose of
the
instruction.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
The new Dyson Root8Cyclone(TM) vacuum cleaner is the
most powerful upright available.
Like all Dyson cleaners the Root8Cyclone(TM) maintains
constant suction. Dyson scientists have developed the
Root8Cyclone(TM) to give higher suction power and pick up
more dust. It will be available from June 2001 in the UK.
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
-- http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads
> The code below was written deliberately without using include
> files, labels
> definitions etc,
<snip>
I disagree that that makes any sense. Using symbols is a way to guard
against typos and oversights when writing (or more importantly, changing)
the code. If you are concerned about the form of the final output you only
have to look at the hex in the listing file.
> I started with a working program that was using include files,
> macro etc. A
> program that has been in use in over 200 finished units that have been
> working happily for up to 3 years (so far). This same code in the same
> circuit using an A revision chip fails to function correctly. I
> ended up the
> simple code to prove it was not me but the PIC. (I was convinced it was me
> and did everything I could to prove it was not before settling for the PIC
> as the cause.)
According to Microchip's data sheet for the PIC16F84A the only differences
noted (Table B-1 in Appendix B) are:
1) Max voltage is now 5.5V, but top temperature +125degC
2) Max frequency increased to 20MHz
3) EEPROM cycle faster
4) Rext range starts at 3kohm
None of these should be affecting you, and your code looks simple enough and
ought to work. Is there a "16F84A" option for the list directive? (The
Microchip web site does not remark upon updates for MPLAB for PIC16F84A)
How about a wiring error on your board? Perhaps by shorting RB3 to ground
you are inadvertently causing a brownout. Perhaps the original chip is not
as sensitive to this as the 'A' version is. I would try this myself, but I
do not have any of these chips.
>I started with a working program that was using include files, macro etc. A
>program that has been in use in over 200 finished units that have been
>working happily for up to 3 years (so far). This same code in the same
>circuit using an A revision chip fails to function correctly. I ended up the
>simple code to prove it was not me but the PIC. (I was convinced it was me
>and did everything I could to prove it was not before settling for the PIC
>as the cause.)
Clive (are you relative of Sir Clive Sinclair, his holiness? :oD), see this
There is a note about the migration from PIC16F84 to PIC16F84A, see the header:
----
PIC16F84 to PIC16F84A Migration (119 K) 6/14/1999
Notes: This document is intended to describe the functional differences and the electrical
specification differences that are present when migrating from one device to the next.
----
In message <NABBIDDPJGGANFPHEGAKCEGAFCAA.amespam_OUTsynaptics.com>, Andrew
Errington <@spam@ameKILLspamSYNAPTICS.COM> writes
>According to Microchip's data sheet for the PIC16F84A the only differences
>noted (Table B-1 in Appendix B) are:
>1) Max voltage is now 5.5V, but top temperature +125degC
>2) Max frequency increased to 20MHz
>3) EEPROM cycle faster
>4) Rext range starts at 3kohm
There are also differences in the programming requirements (although I
don't think MicroChip mention it!). Many programmers (mine amongst them)
wouldn't program the 16F84A, I had to alter the erase routines to cure
the problem.
--
Nigel.
/--------------------------------------------------------------\
| Nigel Goodwin | Internet : KILLspamnigelgKILLspamlpilsley.co.uk |
| Lower Pilsley | Web Page : http://www.lpilsley.co.uk |
| Chesterfield | Official site for Shin Ki and New Spirit |
| England | Ju Jitsu |
\--------------------------------------------------------------/
What were the changes you made to the erase routines? I have used the
PIC16F84A in my El Cheapo without any problems, but I would like to know
what to do if it bites somebody.
In message <003301c0d49d$cc6810e0$3a5170cf@l9d1f7>, myke predko
<RemoveMEmykeTakeThisOuTPASSPORT.CA> writes
>Hi Nigel,
>
>What were the changes you made to the erase routines? I have used the
>PIC16F84A in my El Cheapo without any problems, but I would like to know
>what to do if it bites somebody.
Hi Mike,
I can't remember how the routine was before, it basically developed over
a number of years - as you probably remember there were problems with
the erase routine listed in the 16C84 datasheet, and I implemented
changes based on information from the PicList. Here is the routine I
currently use.
ProgMode() turns MCLR on or off, Command() sends a command to the PIC,
Outword() sends a 14 bit value. The values send (like BegPrg) are those
listed in the datasheet. I notice I've actually commented a change for
the 16F84A
Procedure EraseAll;
Var
i : Byte;
Begin
{Clear Protect fuse}
ProgMode(POn);
Command(LdConf);
OutWord($3FFF); {value to reset memory to}
FOR i := 0 TO 6 Do
Command(IncAdd);
Command(1);
Command(7);
Command(BegPrg);
Delay(ProgDelayTime);
Command(1);
Command(7);
{Command(BegPrg); - removed for 16F84A}
ProgMode(POff);
{Clear Program memory}
ProgMode(POn);
Command(LdProg);
OutWord($3FFF);
Command(BegPrg);
Command(ErsPrg);
Command(BegPrg);
Delay(ProgDelayTime);
ProgMode(POff);
{Clear Data memory}
ProgMode(POn);
Command(LdData);
OutWord($3FFF);
Command(1);
Command(7);
Command(BegPrg);
Delay(ProgDelayTime);
Command(1);
Command(7);
ProgMode(POff);
End;
--
Nigel.
/--------------------------------------------------------------\
| Nigel Goodwin | Internet : spamBeGonenigelgspamBeGonelpilsley.co.uk |
| Lower Pilsley | Web Page : http://www.lpilsley.co.uk |
| Chesterfield | Official site for Shin Ki and New Spirit |
| England | Ju Jitsu |
\--------------------------------------------------------------/
It's quite a bit more comprehensive than what I've been using. I've just
used the Microchip suggested code. I'll add it to my El Cheapo and see how
it works.
Just to make sure I'm clear on everything, the constant "ProgDelayTime" is
10 msecs for the flash parts?
In message <010301c0d514$be8c45a0$5d5170cf@l9d1f7>, myke predko
<mykeEraseME.....PASSPORT.CA> writes
>Hi Nigel,
>
>It's quite a bit more comprehensive than what I've been using. I've just
>used the Microchip suggested code. I'll add it to my El Cheapo and see how
>it works.
>
>Just to make sure I'm clear on everything, the constant "ProgDelayTime" is
>10 msecs for the flash parts?
ProgDelayTime is actually a variable, and can be changed on the hardware
options page, by default it's 10mS - I've found that it will usually
work OK with a 16C84 down as low as 7mS, but fails below that. I've
never tried with the later chips, but I seem to remember reading that
they can use lower delay times than the older ones?.
--
Nigel.
/--------------------------------------------------------------\
| Nigel Goodwin | Internet : EraseMEnigelglpilsley.co.uk |
| Lower Pilsley | Web Page : http://www.lpilsley.co.uk |
| Chesterfield | Official site for Shin Ki and New Spirit |
| England | Ju Jitsu |
\--------------------------------------------------------------/
mitvma.mit.edu
