You _will almost certainly_ get random bytes in as you plug/unplug the
TTL/RS232 converter. If your protocol does not protect against this then I
think you have probably found the issue.

Also, you should put your TTL to Serial adapter as close to the TTL end as
you can.


~ Bob Ammerman
RAm Systems

> -----Original Message-----
> From: piclist-bounces@mit.edu [mailto:piclist-bounces@mit.edu] On Behalf
> Of Neil
> Sent: Thursday, November 13, 2014 10:13 AM
> To: piclist@mit.edu
> Subject: Re: [PIC] Power surges --> EEPROM corruption?
>=20
> Okay, I have more data on the full system, and more data on what's
> causing the problem.   Crude diagram attached.
>=20
> The power conditioner has filtering caps, reverse protection, etc but I
don't
> know the specifics.  I do know that B draws approx 160mA, and C draws
> approx 65mA.  C is the device of interest here... the one with the EEPROM
> getting corrupt.  C also has another ground for a motor controller.
>=20
> C communicates with one device by  TTL-level data and another by RS232
> signals.  However, there is also another serial interface to a laptop.
> The signals are TTL-level out of the box, but are converted to RS232 by a=
n
> external adapter.
>=20
> Here's the enlightening info... apparently the EEPROM corruption seems to
> be linked to disconnecting & connecting the TTL-to-RS232 adapter board
(the
> D-E connection in the diagram).  The protocol for the laptop telling C to
> update certain parameters (changing some EEPROM values) is pretty basic -=
-
> a 1-byte command, a 2-byte parameter value (correlates to a specific
> EEPROM address), and a 1-byte value to update.  I'm wondering if plugging
in
> the D-E connection is causing either a surge on the power line (as the
TTL-to-
> RS232 interface uses 5V provided by C), or perhaps the connection causes =
a
> "switch-bounce" type effect that sends random pulses when being plugging
> in, with some of those pulses being interpreted as commands to update
> parameters.  Data rate is 19200.
>=20
> For a test I can disable the EEPROM-write mechanism in C (so I'd receive
the
> command, but do nothing) and see if that stops the problem.  If so, I can
add
> checksums etc to that protocol.
>=20
> Yes, I should still find out how much filtering is in the system, and add
to C if
> more is needed, but thinking that may not be this specific issue now.
>=20
> But does this provide any other clues?  Mark Jordan mentioned ground
> loops, so I'm wondering if the secondary ground to C may be causing some
of
> that.
>=20
> Cheers,
> -Neil.
>=20
>=20
>=20
> On 10/28/2014 3:40 PM, RussellMc wrote:
> > Your small caps have power supply holdup times in the order of a few
> > milliseconds. If no spikes that drop out the supply completely are
> > longer than this you may be getting noise induced by other means. But
> > without a more detailed look I'd not be at all surprised if direct
> > supply dropout was the poblem. At that stage your PIC may be surviving
> > brownout internally with its reset and disable mechanisms, but if you
> > cannot guarantee the voltage-time profiles on the external eeprom pins
it
> is on its own.
> >
> > For a controller's internal brownout mechanism to protect externally
> > connected parts it must guarantee the relative state of all
> > interconnected pins on the potentially affected device, AND the device
> > itself must guarantee that it can survive  a multi transition brownout
> > on the power rails and any other pin that is not guaranteed by the PIC.
> >
> > If the EEPROM spec says it will survive random violence on its supply
> > lines and any other non-PIC-connected pins, if the PIC connected pins
> > are managed well, AND if the PIC guarantess that it will not only
> > survive said violence but guarantee the state of the interconnected
> > pins during that period, then all may be OK. If both of those
> > guarantees are not specifically given then you have no reason to be
certain
> that corruption should not occur.
> > Should-not and will-not are variably well correlated in reality :-).
> >
> >
> >
> >      Russell


--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.