Searching \ for 'Dead parrot' 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/index.htm?key=dead+parrot
Search entire site for: 'Dead parrot'.

Truncated match.
PICList Thread
'Dead parrot'
1999\01\27@211822 by Westpin

picon face
   Like the guy with the dead parrot, "I wish to register a complaint".
   As soon as my distributor got them in stock, I bought a stick of
12C671/04P chips (dated week 28 of '98) together with the Data Sheet (  ), and
started programming "the chip of the future".  The Data Sheet was extensive
but confusing -- to put it kindly, it was not well-organized.
   My first problem was with OSCCAL.  It clearly didn't work like the Data
Sheet seemed to say, and I ended up with four dead soldiers.  Then, I
downloaded THREE Errata Sheets from the Microchip web site (referring to
OSCCAL on "Rev. A silicon", Rev. B silicon, etc.) that didn't give a clue as
to what was wrong.  I appealed to my distributor, who sent me the "new" Data
Sheet -- slightly different contents, but the SAME document number!  The
different contents didn't help a bit -- six more dead soldiers.
   I wrote an e-mail to spam_OUTtech.supportTakeThisOuTspammicrochip.com, asking for clarification.
Response after one week: zero.
   I'm a believer in OTP -- buy 'em by the stick and use 'em like Kleenex
--but not with odds like this.  I bought four of the JW chips (dated week 38
of '98) and started a cut-and-try calibration of OSCCAL.  Slow work.  The
soldiers were revivable, but the results still didn't make any sense.
   Are we still in the beta stage here?  If so, why are they selling them at
retail?  And when do we get an HONEST Data Sheet?
-- Mel Evans    .....westpinKILLspamspam@spam@aol.com

1999\01\28@023821 by Dr. Imre Bartfai

flavicon
face
Hi,
I do not want to hurt you that's why I kindly ask:
did you read the chips and saved data before programming?
If I guess correctly, the LAST instruction for 8-pin chips of MC contains
the instruction MOVLW xx
where xx is the factory-set OSCCAL value. It is adviced then, that the
very first instruction of the program should say MOVWF OSCCAL. So, the
following way is recommended:

1. Read the virgin chip, save (maybe write down) the xx value.

2. Put following into program:

       ORG     0
       MOVWF   OSCCAL

       ...                     ; your program


       ORG     03FFh           ; or your last address otherwise
       MOVLW   xx

3. Program the chip.

The chip starts on the last address, so loads W, then wraps around and
will fill OSCCAL.

I did not tried this, though.

Hope this helps.

Imre


On Wed, 27 Jan 1999 WestpinspamKILLspamAOL.COM wrote:

{Quote hidden}

1999\01\28@030145 by Quentin

flavicon
face
Question:
I read Osccal on my new 12cxxx JW devices and program it back in after
an erase.
Isn't Movlw xx (Osccal value) also already programmed in an OTP?
I haven't done a 12Cxxx OTP yet, so why is it necessary to read it or
change it when you program the PIC?

What am I missing here?
Quentin

1999\01\28@051909 by Dr. Imre Bartfai

flavicon
face
Hi,
it is programmed already, but I think, if the program does not contain the
same sequence at the same place it may be overwritten or cause programming
failure.
On the other hand, I do not know in which bank is the OSCCAL located so it
may be necessary to switch the bank before writing OSCCAL.

Imre


On Thu, 28 Jan 1999, Quentin wrote:

{Quote hidden}

1999\01\28@064951 by Jim Robertson

flavicon
face
At 10:01 28/01/99 +0200, you wrote:
>Question:
>I read Osccal on my new 12cxxx JW devices and program it back in after
>an erase.
>Isn't Movlw xx (Osccal value) also already programmed in an OTP?

Yes, that is correct.

>I haven't done a 12Cxxx OTP yet, so why is it necessary to read it or
>change it when you program the PIC?

It isn't. What you require is programmer software smart enough to leave
it alone.


>What am I missing here?

I gather the original "dead pariot" compliant was more about the inaccuracy
of the internal oscillator and/or OSCCAL value. Microchip have release a
batch that are wildly out of spec.

I was at a microchip seminar where microchip guys said they aimed to get to
within 5% accuracy. That is leaves quite a large error potential, enough to
kill its usefullness for async comms.

Jim


>Quentin
>
--------------------------------------------------------
Jim Robertson
Email: newfoundspamspam_OUTpipeline.com.au

http://www.pipeline.com.au/users/newfound
--------------------------------------------------------

1999\01\28@100259 by Wolfgang Strobl

flavicon
face
On 28 Jan 99, 10:01  Quentin wrote:

> Question:
> I read Osccal on my new 12cxxx JW devices and program it back in after
> an erase.

So do I. I wrote both number on the back of the ceramic casing
using a permanent pen (the kind used for overhead foils), and just
include a #byte oscal = 5; oscal = 0x94 or whatever in CCS C.

> Isn't Movlw xx (Osccal value) also already programmed in an OTP?

It is.  But one doesn't have to use that very instruction. What
counts is that you somehow get the correct calibration value, once
and store it into OSCAL, before you need it.

The aforementioned technique works well for small (small being
1..5) series, too, on OTPs. One has to modify the source and
reload the programmer for each new piece, of course*). For larger
batches, I'd use the standard practice (i.e. not touching the
MOVLW xx in high memory when programming, and adding a
MOVWF 5 at loc 0 to the program), though.


> I haven't done a 12Cxxx OTP yet, so why is it necessary to read it or
> change it when you program the PIC?

It isn't, and you can't.


*) Another trick is to read a handfull of OTPs calibration values, and
sort them. I did this once, just on order to learn about the possible
values in real chips.


--
     o      (     @spam@Wolfgang.StroblKILLspamspamgmd.de (+49 2241) 14-2394
    /\        *   GMD mbH                       #include
  _`\ `_<===      Schloss Birlinghoven,         <std.disclaimer>
__(_)/_(_)___.-._  53754 Sankt Augustin, Germany ________________

1999\01\28@100725 by Westpin

picon face
In a message dated 99-01-28 03:01:45 EST, you write:

<< Isn't Movlw xx (Osccal value) also already programmed in an OTP?
I haven't done a 12Cxxx OTP yet, so why is it necessary to read it or
change it when you program the PIC? >>

   Because I want to fine-tune the oscillator frequency for more accurate
timing.  The problem isn't in reading or writing to OSCCAL, but in knowing how
to set the bits.  Read the Data Sheet(s) and/or the Errata Sheet(s) and you'll
see what I mean.
-- Mel Evans    KILLspamwestpinKILLspamspamaol.com

1999\01\28@102142 by Westpin

picon face
In a message dated 99-01-28 06:49:47 EST, you write:

<<
I gather the original "dead pariot" compliant was more about the inaccuracy
of the internal oscillator and/or OSCCAL value. Microchip have release a
batch that are wildly out of spec.

I was at a microchip seminar where microchip guys said they aimed to get to
within 5% accuracy. That is leaves quite a large error potential, enough to
kill its usefullness for async comms.

Jim
 >>
   OK.  "Wildly out of spec" I can handle, if I just knew HOW TO SET THE BITS
in OSCCAL.  But Microchip won't tell me!
-- Mel Evans    RemoveMEwestpinTakeThisOuTspamaol.com

1999\01\28@113940 by John Payson

flavicon
face
|If I guess correctly, the LAST instruction for 8-pin chips of MC contains
|the instruction MOVLW xx
|where xx is the factory-set OSCCAL value. It is adviced then, that the
|very first instruction of the program should say MOVWF OSCCAL. So, the
|following way is recommended:

For the 12C5xx parts, the last instruction in OTP is the
first one executed, and contains a MOVLW instruction.  On
the 12C6xx parts, the last instruction in OTP is only exec-
uted on request, and is a RETLW.

1999\01\28@114802 by John Payson

flavicon
face
|    OK.  "Wildly out of spec" I can handle, if I just knew HOW TO SET THE BITS
|in OSCCAL.  But Microchip won't tell me!

So write a small routine in an area of OTP you don't plan to
use for anything else which lets you test OSCCAL values.  Since
OSCCAL is a register, you could write a little program that out-
puts a square wave on a port pin while feeding OSCCAL a controll-
able value [e.g. using something like this:

               movlw           254
               tris            GPIO
               clrf            Speed
               clrf            OSCCAL

MainLoop:
               bsf             GPIO,0
               btfsc           GPIO,1
                goto           NewFreq
               bcf             GPIO,0
               goto            MainLoop

NewFreq:
               btfsc           GPIO,1
                goto           NewFreq
               incf            Speed,f
               movf            Speed,w
               movwf           OSCCAL
               goto            MainLoop

When you start up the chip, you should see a 166.67Khz square wave on
GP0.  Each pulse on GP1 will cause a new value to be loaded into the
OSCCAL.  Count how many pulses it takes to get a value you like; that
is the OSCCAL value you should use.

1999\01\28@135329 by Dan O'Brien

flavicon
face
This must be intended for someone else.

Dan O'Brien



At 10:49 AM 1/28/99 -0600, you wrote:
{Quote hidden}

1999\01\28@135346 by Westpin

picon face
In a message dated 99-01-28 11:47:59 EST, you write:

<<
So write a small routine in an area of OTP you don't plan to
use for anything else which lets you test OSCCAL values.  Since
OSCCAL is a register, you could write a little program that out-
puts a square wave on a port pin while feeding OSCCAL a controll-
able value [e.g. using something like this:
 >>
My thought exactly.  As soon as I make any change in OSCCAL, the chip hangs.

-- Mel Evans    spamBeGonewestpinspamBeGonespamaol.com

1999\01\28@142513 by John Payson

flavicon
face
In a message dated 99-01-28 11:47:59 EST, you write:

<<
So write a small routine in an area of OTP you don't plan to
use for anything else which lets you test OSCCAL values.  Since
OSCCAL is a register, you could write a little program that out-
puts a square wave on a port pin while feeding OSCCAL a controll-
able value [e.g. using something like this:
 >>
|My thought exactly.  As soon as I make any change in OSCCAL, the chip hangs.

In that case, I'd suggest writing a routine that reads a byte
from some outside source and updates OSCCAL with that byte (it
may be that some values of OSCCAL will hang the chip, though
that does seem annoying...)

Alternatively, you could do something like this [I forget what
page OSCCAL is in; you may have to adjust the code].

               clrf            GPIO
               movlw           254
               tris            GPIO
               bsf             GPIO,0
               btfsc           GPIO,1
                clrf           Speed
               movf            Speed,w
               incf            Speed,f
               movwf           OSCCAL
Loop:
               bsf             GPIO,0
               nop
               bcf             GPIO,0
               goto            LOOP

Repeated resets will cause higher OSCCAL values to be used if
RP1 is low [if it's high the value will reset to zero].  This
should allow testing a whole range of frequencies even though
some may hang.

BTW, what bank is OSCCAL in on the 12C6xx?  Are you switching
back to bank 0 after setting it?

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