Searching \ for 'windowed PICs sensitive to light??' 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/devices.htm?key=pic
Search entire site for: 'windowed PICs sensitive to light??'.

Truncated match.
PICList Thread
'windowed PICs sensitive to light??'
1997\07\09@100053 by Tim Drury

flavicon
face
Here is my setup:

PIC14000 acting as I2C master sending 5 bytes to a PIC16C63 acting as I2C slave.
PIC16C63 buffers the I2C data and sends it to a PC via RS-232.  I can look on a
scope and see the 5 I2C bytes followed by the 5 (plus checksum, total 6) bytes
on the RS232 line.

One of the bytes from the PIC14000 indicates how many data bytes are in the
message.  There is a three byte header and two data bytes for this test.
I know the protocol of the I2C doesn't need a "number of bytes" parameter; that
info is used by the RS232 portion of the 16C63, so it has to stay.

Everything works fine until I place my hand between my 100W halogen desk lamp
and the PIC14000.  The PIC14000 still only sends 5 bytes but the PIC16C63 starts
sending lots of data (lots and lots...).  Presumably the 14000 is telling the
16C63
that there are more than 2 data bytes.  This is strange, but what is also
stranger
is that it only works with the light _on_.  When I block the light or turn it
off the
PIC losses its mind.  This doesn't bode well for a dark, windowless OTP 14000.
BTW, the 16C63 doesn't have any problems (that I can detect).

The first think I thought of is the internal 4Mhz clock of the 14000 is
fluctuating
enough that the I2C master clock and data timing are moving outside the limits.
That isn't happening.  I confirmed it on the scope.

Any ideas?  Will the OTP parts exhibit the same behavior?

-tim drury

1997\07\09@130458 by Mike

flavicon
face
At 10:02 AM 7/9/97 -0400, you wrote:
>Here is my setup:

<snip>

Make sure you clear or initiate all RAM variables before use.

The light ON might act to clear those RAM variables you didn't in
software - especially on power up...

We had a couple of MC68705R5S processors on a remote hybrid power station
and had the windows covered with black masking tape.

When we took a photo of the cabinet (with a flash) it went haywire and
relays clicked all over the place - fortunately the hardware safety
interlocks prevented the generators starting...

The point is that opaque masking tape was not opaque the the UV from an
electronic flash. We had to put aluminium foil (doubled over to avoid
pin holes) then cover this with tape to be sure we didn't let any other
light in...

Rgds

Mike


Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
                                                                      Massen

1997\07\10@053603 by Tom Handley

picon face
re: Errors with 14000/16C63

  Tim, this is probably obvious but are both those parts EPROM versions and did
you run the test with the windows covered up by a suitable opaque cover?

  - Tom

At 10:02 AM 7/9/97 -0400, you wrote:
>Here is my setup:
>
>PIC14000 acting as I2C master sending 5 bytes to a PIC16C63 acting as I2C
slave.
{Quote hidden}

starts
{Quote hidden}

1997\07\10@103052 by Tim Drury

flavicon
face
>Make sure you clear or initiate all RAM variables before use.
>
>The light ON might act to clear those RAM variables you didn't in
>software - especially on power up...
>
>We had a couple of MC68705R5S processors on a remote hybrid power station
>and had the windows covered with black masking tape.
>
>When we took a photo of the cabinet (with a flash) it went haywire and
>relays clicked all over the place - fortunately the hardware safety
>interlocks prevented the generators starting...
>
>The point is that opaque masking tape was not opaque the the UV from an
>electronic flash. We had to put aluminium foil (doubled over to avoid
>pin holes) then cover this with tape to be sure we didn't let any other
>light in...

Mike,

Thanks for the reply.  I read the FAQ regarding uninitialized variables.  I
didn't
think this problem affected me since it wasn't a "boot-up" problem.  This
occurred hours into the test after (I believe) every RAM location had been
accessed.

Anyway, I went through the code in fine detail and found a couple subtle bugs
that didn't relate to the uninitialized RAM problem.  After fixing them, the
problem went away.  I don't really know why.

The question I have is this: once the PIC is powered up, can it be affected
by light.  I would certainly think not, but my earlier problem hints that it
can.  I just don't know the answer.

Did you track your flash-bulb problem down to a specific uninitialized
register?  I can't find mine, and I hate solving a problem without knowing
what the answer was.  It unnerves me.

-tim

Attachment converted: wonderland:WINMAIL.DAT (????/----) (00003E74)

1997\07\10@105724 by John Payson

picon face
> The question I have is this: once the PIC is powered up, can it be affected
> by light.  I would certainly think not, but my earlier problem hints that it
> can.  I just don't know the answer.

From my experience, light has three effects on a 16C622/JW that I've been
able to identify:

[1] It seems to cause the comparators to misread slightly.

[2] If the light gets strong, it can increase current consumption (e.g. when
   the part is sleeping)

[3] If the light gets very strong (e.g. mini-Maglite at 1") the part will start
   to malfunction "randomly" [there's probably some pattern to what it does,
   but I've not identified it; it did cause a program crash].

1997\07\10@144311 by Mike

flavicon
face
At 10:32 AM 7/10/97 -0400, you wrote:

>>When we took a photo of the cabinet (with a flash) it went haywire and
>>relays clicked all over the place - fortunately the hardware safety
>>interlocks prevented the generators starting...
>>
>>The point is that opaque masking tape was not opaque the the UV from an
>>electronic flash. We had to put aluminium foil (doubled over to avoid
>>pin holes) then cover this with tape to be sure we didn't let any other
>>light in...

>Did you track your flash-bulb problem down to a specific uninitialized
>register?  I can't find mine, and I hate solving a problem without knowing
>what the answer was.  It unnerves me.

Both controllers were set up as state machines, so there were negligble
opportunities for uninitialised variables. It seems the direction registers
were momentarily inverted when the UV burst from the flash hit. One thing
we did as a precaution was to refresh the direction registers upon each
state change detected. WHen didn't have time to investigate any further and
found no other software precautions/changes necessary.

As a matter of policy ALL our windowed chips are covered with full opaque
metal tabs to be as sure as possible there is no chance of any light
causing alteration of operation.

It stands to reason that chips will have some susceptibility, especially
with design tolerances getting ever smaller and the energy per gate being
very small indeed.

Prior to the UV flash we noticed no difference in operation from normal
incandescent light bulbs, though these were MC68705R5S dies which were
NMOS and were made around 1988 so die sizes were a bit larger than etc...

Maybe some subtle thing like a flag or set of memory locations are being
changed - it would be quite easy to set up a test - that is a full
RAM XOR to report which RAM locations and/or flags change.

This would be a simple, yet most interesting experiment.

I know of one chap around 1985 that used a 2708 fully programmed and watched
how the bits were slowly erased by exposure to daylight as a possible
means to determine UV strength - I think consistency was a problem...

Rgds

Mike
Perth, Western Australia


Some say there is no magic but, all things begin with thought then it becomes
academic, then some poor slob works out a practical way to implement all that
theory, this is called Engineering - for most people another form of magic.
                                                                      Massen

1997\07\10@182906 by Andy Kunz
flavicon
face
>The question I have is this: once the PIC is powered up, can it be affected
>by light.  I would certainly think not, but my earlier problem hints that it
>can.  I just don't know the answer.

Yes.

I have seen all my windowed chips behave slightly differently, from
changing frequency (with the 8-pin devices on internal RC) to losing memory
in RAM.  All kinds of things.

Here's what to do with all those 5" disk write-protect tabs.  Use them as
EPROM window shades!

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\07\14@100622 by Tim Drury

flavicon
face
>> The question I have is this: once the PIC is powered up, can it be affected
>> by light.  I would certainly think not, but my earlier problem hints that it
>> can.  I just don't know the answer.
>
>From my experience, light has three effects on a 16C622/JW that I've been
>able to identify:
>
>[1] It seems to cause the comparators to misread slightly.
>
>[2] If the light gets strong, it can increase current consumption (e.g. when
>    the part is sleeping)
>
>[3] If the light gets very strong (e.g. mini-Maglite at 1") the part will start
>    to malfunction "randomly" [there's probably some pattern to what it does,
>    but I've not identified it; it did cause a program crash].


Thanks for all the responses.  There is obviously a problem with windowed
PICs and light, but nothing that cannot be cured.

Did anyone notice, however, that my problem was NOT a problem with light,
but with _dark_??  My system ran fine with a 100W halogen desk lamp shining
but when I turned the light off, or if I put my hand between the PIC and the
lamp, then the system started to malfunction?

In this case, placing an opaque cover on the PIC made the problem worse.
What I needed to do was tape a light bulb to the PIC!  Kidding, of course.

As Mike stated, this would be an interesting problem to explore, but I don't
have the time.  I have to keep moving forward.

Thanks again, folks.

-tim


Attachment converted: wonderland:WINMAIL.DAT (????/----) (00003EFD)

1997\07\14@130245 by Andy Kunz

flavicon
face
>Did anyone notice, however, that my problem was NOT a problem with light,
>but with _dark_??  My system ran fine with a 100W halogen desk lamp shining
>but when I turned the light off, or if I put my hand between the PIC and the
>lamp, then the system started to malfunction?

I noticed that you _saw_ a problem when the chip was operating in the
proper mode.

This implies that the code was wrong.

Since then you fixed the code, I presume, and now the chip works correctly.

Amazing the neat little things you learn on this list!

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\07\15@164255 by Tim Kerby

picon face
Halogen lights give off a load of uv - thats why they need a glass plate
over the bulb and you should be further than a metre away at all times.  It
could be erasing the chip.

Tim


At 10:02 09/07/97 -0400, you wrote:
>Here is my setup:
>
>PIC14000 acting as I2C master sending 5 bytes to a PIC16C63 acting as I2C
slave.
>PIC16C63 buffers the I2C data and sends it to a PC via RS-232.  I can look
on a
>scope and see the 5 I2C bytes followed by the 5 (plus checksum, total 6)
bytes
>on the RS232 line.
>
>One of the bytes from the PIC14000 indicates how many data bytes are in the
>message.  There is a three byte header and two data bytes for this test.
>I know the protocol of the I2C doesn't need a "number of bytes" parameter;
that
>info is used by the RS232 portion of the 16C63, so it has to stay.
>
>Everything works fine until I place my hand between my 100W halogen desk lamp
>and the PIC14000.  The PIC14000 still only sends 5 bytes but the PIC16C63
starts
>sending lots of data (lots and lots...).  Presumably the 14000 is telling the
> 16C63
>that there are more than 2 data bytes.  This is strange, but what is also
> stranger
>is that it only works with the light _on_.  When I block the light or turn it
> off the
>PIC losses its mind.  This doesn't bode well for a dark, windowless OTP
14000.
>BTW, the 16C63 doesn't have any problems (that I can detect).
>
>The first think I thought of is the internal 4Mhz clock of the 14000 is
> fluctuating
>enough that the I2C master clock and data timing are moving outside the
limits.
>That isn't happening.  I confirmed it on the scope.
>
>Any ideas?  Will the OTP parts exhibit the same behavior?
>
>-tim drury
>
>


------------------------------------------------------------------
Personal Web Pages: http://web.ukonline.co.uk/members/tim.kerby/
PIC Site: web.ukonline.co.uk/members/tim.kerby/pic/
The PIC Pages are under construction and I am looking for projects
------------------------------------------------------------------

1997\07\16@034840 by Keith Dowsett

flavicon
face
At 21:25 15/07/97 +0100, you wrote:
>Halogen lights give off a load of uv - thats why they need a glass plate
>over the bulb and you should be further than a metre away at all times.  It
>could be erasing the chip.
>
>Tim
>

Hmm, not all that much u.v. They have a colour temperature around 3200K
(sorry photograpy creeping in) which is similar to a domestic light bulb.
They emit a little more uv because the tube is silica rather than glass.

AFAIK the reason most of them have a glass plate in front is because they
frequently fail with a bang. Being sprayed with lots of red hot quartz
fragments is no fun (been there, done that).

Keith.
==========================================================
Keith Dowsett         "Variables won't; constants aren't."

E-mail: spam_OUTkdowsettTakeThisOuTspamrpms.ac.uk
  WWW: http://kd.rpms.ac.uk/index.htm

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