Searching \ for '[PIC:] EEPROM write temperature dependence?' 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/ios.htm?key=temperature
Search entire site for: 'EEPROM write temperature dependence?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] EEPROM write temperature dependence?'
2004\03\01@003414 by Ben Jackson

flavicon
face
I'm working on an 18F2320 device that I need to calibrate at several
temperatures.  At the moment I'm just saving the raw cal data to a scratch
area of EEPROM so I can read it back out and test it for sanity before
manually adding it to tables.

After several passes at about room temperature and 'fridge temperature'
(around 40F, 4C) I tried it in the freezer (around 0F, -18C) and
consistently the programming loop failed to write (left at 0xFF) the
first EEPROM byte.

-18C is well within the -40C minimum device temp.  The 5V power
regulation is good.  All bytes after the first one write fine.

Am I doing something wrong?  I can add a verify/rewrite loop but I'd
like to understand why first.  Should I be setting WREN earlier?  Does
that start the onboard charge pump?  Are the bytes that DO get written
likely to be 'more fragile'?

--
Ben Jackson
<spam_OUTbenTakeThisOuTspamben.com>
http://www.ben.com/

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu

2004\03\01@004037 by Liam O'Hagan

flavicon
face
is something taking a while to start up because of the cold? What sort of
oscillator are you using?

Perhaps it's not stable enough to write the first byte correctly, but has
"warmed up" enough to write the subsequent bytes...

By wamed up I mean started stable oscillations.

> {Original Message removed}

2004\03\01@014551 by Ken Pergola

flavicon
face
Ben Jackson wrote:

> After several passes at about room temperature and 'fridge temperature'
> (around 40F, 4C) I tried it in the freezer (around 0F, -18C) and
> consistently the programming loop failed to write (left at 0xFF) the
> first EEPROM byte.


Hi Ben,

It's not too clear what you are actually putting inside the freezer besides
the PIC -- is this a complete PCB board or a perf-board project?
If so, is the board conformally coated? Perhaps it is related to humidity
and condensation on the board?

I'm thinking you are using a environmental chamber, but you mentioned
'freezer' -- is this a food freezer?

Also, if you are using a crystal or ceramic resonator, are you operating in
the manufacturer's recommended temperature range of the crystal or
resonator?

Regards,

Ken Pergola

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

2004\03\01@041017 by Jinx

face picon face
First, are you sure you've got the industrial or better grade PIC ?

It's interesting that only the first byte doesn't get written. This suggests
that maybe the PIC and crystal are OK

Are you using SLEEP and WDT at all ? 32kHz ?

WDT can be 25% faster at -18C than at 25C and I wonder if there's
some problem allowing enough time for the PIC's oscillator to wake
up for the first time. A problem that doesn't seem isn't there at higher
temperatures, although you could be on the ragged edge and not
know it

The 32kHz LP can take quite a while to stabilise, even at room temp

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

2004\03\02@010112 by Ben Jackson

flavicon
face
Liam O'Hagan <EraseMEliamspam_OUTspamTakeThisOuTGLI.COM.AU> wrote:
> is something taking a while to start up because of the cold? What sort of
> oscillator are you using?

It's driving a 4MHz crystal.  The device at that point has been on (never
sleeping) for at least a minute (the time to acquire the calibration) and
to be sure I was at equilibrium it was actually running for about an hour
before the first trial and probably 20 minutes the second time.

Ken Pergola wrote:
> It's not too clear what you are actually putting inside the freezer besides
> the PIC -- is this a complete PCB board or a perf-board project?

It's on a breadboard.  Condensation did form later but was not present
during the EEPROM writes.  Either way I'm not sure how that would affect
just the first EEPROM byte.

The crystal is a junk box part labelled 4.000000 KDS 2K.  I can't find
any KDS crystal datasheets.  It ran the rest of the chip fine, though.

Jinx <joecolquittspamspam_OUTCLEAR.NET.NZ> wrote:
> First, are you sure you've got the industrial or better grade PIC ?

It's an 18F2320, as far as I can tell it only comes in Industrial
(-40C..85C) and Extended (-40C..125C).  I have an industrial one.
Both should go down to -40C, and I was only at -20C at worst (probably
a bit warmer).

> Are you using SLEEP and WDT at all ? 32kHz ?

No, device was awake for an hour for one trial.  Not using a watch
crystal.

> WDT can be 25% faster at -18C than at 25C and I wonder if there's
> some problem allowing enough time for the PIC's oscillator to wake

My pet theory is that the internal charge pump to program the EEPROM
takes longer to start.  I was hoping someone would know if setting WREN
starts it so I could 'warm it up'.

--
Ben Jackson
<@spam@benKILLspamspamben.com>
http://www.ben.com/

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\02@011642 by Ken Pergola

flavicon
face
Ben,

Are you aware about this errata on the PIC18F2220/2320/4220/4320 devices?


Module: Data EEPROM
-------------------
When writing to the data EEPROM, the contents of
the data EEPROM memory may not be written as
expected.

Work around:
------------
Either of two work arounds can be used:

1. Before beginning any writes to the data
EEPROM, enable the LVD (any voltage) and
wait for the internal voltage reference to
become stable. LVD interrupt requests may be
ignored. Once the LVD voltage reference is
stable, perform all EEPROM writes normally.
When writes have been completed, the LVD
may be disabled.

2. Configure the BOR as enabled (any voltage).
Select a threshold below VDD to allow normal
operation. If VDD is below the BOR threshold,
the device will be held in BOR Reset.
Date Codes that pertain to this issue:
All engineering and production devices.


Ben what is you silicon revision of that part?

Regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\02@012723 by Ken Pergola

flavicon
face
Hi Ben,

That was Rev. B2 errata referenced in my previous post by the way.

If your device has the following Device ID, that errata would apply to your
part:

Device ID: 0x0503 (silicon revision 0x03)

If your have an ICD 2, you can easily check the silicon revision.

If not, just read the Device ID registers:

DEVID 2   DEVID 1
(MSB)     (LSB)
0x3FFFFF:0x3FFFFE

The lower 5 bits in DEVICE ID REGISTER 1 indicates your silicon device
revision.

Regards,

Ken Pergola

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2004\03\03@014511 by Ben Jackson

flavicon
face
Ken Pergola wrote:
> Are you aware about this errata on the PIC18F2220/2320/4220/4320 devices?

Ouch, I should be, I checked the errata looking for my RE3 problem, but
my memory isn't what it used to be.

> Device ID: 0x0503 (silicon revision 0x03)

I'm not sure why they write it that way, it reads out as 0x03, 0x05.
But yes, that's the revision I have.

I might try the workarounds and report back to the list.  The datasheet
recommends using program memory (via TBLWT) for long term configuration
anyway.

Here's the snippet I used, in case anyone else needs it (no ICD here):

DEVID1 equ 0x3ffffe ; not in the header?
devid:
       movlw UPPER(DEVID1)
       movwf TBLPTRU
       movlw HIGH(DEVID1 & 0xFFFF) ; HIGH complains about >0xFFFF?!
       movwf TBLPTRH
       movlw LOW(DEVID1)
       movwf TBLPTRL
       tblrd*+
       movff TABLAT, HEATA
       tblrd*
       movff TABLAT, HEATB
       call eewrite_debug
       bra $

My eewrite_debug happens to save HEATA/B and some other things so I just
reused it.

--
Ben Jackson
<KILLspambenKILLspamspamben.com>
http://www.ben.com/

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2004\03\03@114203 by Ken Pergola

flavicon
face
Ben Jackson wrote:

> > Device ID: 0x0503 (silicon revision 0x03)
>
> I'm not sure why they write it that way, it reads out as 0x03, 0x05.

Hi Ben,

Words are stored in little-endian format.

0x0503 is a 16-bit word.

0x05 is the most-significant byte of the word.
0x03 is the least-significant byte of the word.

The device ID is stored as such:

0x3FFFFE  Device ID LSB
0x3FFFFF  Device ID MSB


In the routine you posted, you are reading the least-significant byte of the
Device ID first at address 0x3FFFFE, then you are reading the most
significant byte of the device ID second.

If you string the two bytes you read into a word, you get 0x0503.

Hope this clears things up.

Best regards,

Ken Pergola

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

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