Protocol is being switched. For now the TTL lines are long because the=20 box is mounted under the truck (18-wheeler rig) and the RS232-to-TTL=20 adapter is inside, but that it will be moved on the main PCB later. Cheers, -Neil. On 11/13/2014 11:20 AM, Bob Ammerman wrote: > 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 a= s > 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? >> >> Okay, I have more data on the full system, and more data on what's >> causing the problem. Crude diagram attached. >> >> 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 EEPRO= M >> getting corrupt. C also has another ground for a motor controller. >> >> 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 = an >> external adapter. >> >> Here's the enlightening info... apparently the EEPROM corruption seems t= o >> 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 t= o >> 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 pluggin= g > 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. >> >> 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 ca= n > add >> checksums etc to that protocol. >> >> Yes, I should still find out how much filtering is in the system, and ad= d > to C if >> more is needed, but thinking that may not be this specific issue now. >> >> 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. >> >> Cheers, >> -Neil. >> >> >> >> 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 .