UART being damaged during powerup

[staan]

Hi,

I am interfacing three PIC16F1947's with UART (RS232 protocol).

For instance lets name the three PICs as A, B and C.

PIC 'A' has two UART ports active.
PIC 'B' and 'C' have one port active.

'B' and 'C' are connected to 'A'.

'B' is not directly connected to 'C'.

'A' is the master board with circuitry for power supply.
'B' and 'C' are pluggable boards.

The PICs are interconnected via three RS232 chips (one for each PIC- no isolation).

When I connect 'B' or 'C' to 'A' they work fine as they have for many days.

But now I discovered a problem.

When I hotplug the 'B' or 'C' to 'A'.
The UART ports on 'B' and 'C' sometimes don't seem to work. They just throw a garbage character at the instant when connected (powering up) and go dark.

All other GPIO functions work fine.

This seems to happen under all circumstances.
ex. Internal oscillator/external oscillator, delayed uart initialization.

Anyway, I am preparing the short version of the code right now. I will post soon.

Your help is much appreciated.

[RF_Developer]

Hot plugging is not easy. It generally needs special connectors and careful software design. A tranmission standard such as RS232 is not good as as ithe board is connected the lines can appear to go up and down, looking like malformed characters. Half-duplex RS485 would probably be better, but really for proper hot-plugging you need to use a transmission standard designed and intended, at both hardware and software levels, for hot-plugging, such as USB.

IF you use RS232, at the very least you MUST have "errors" in your #use_rs232 line as otherwise the rubbish seen when you connect will probably cause the UART to lock-up. This could well be what is happening as you describe receiveing one (possibly more) rubbish characters then it goes "dead". Oh, and another thing, your topic title says "damaged"? Is anything damaged, i.e. a hard fault requiring replacement of components, or is it just a soft failure issue, fixable by restarting?

The firmware should be written to ensure that comms are only attempted once you know everything is up and stable: all voltages correct, all false characters read and discarded and so on.

This may not be fully fixable by code changes alone. You may need to rethink your hardware design.

[staan]

Yes, I have the "errors" turned on in #use_rs232

The PIC gets damaged over-time by hot-plugging, one of my chip had to be replaced. Replaced chip works fine.

It is not fixable by restarting. I have to completely disconnect (power down) the PIC and then reconnect it again to to resolve it, but sometimes replugging doesn't help too.

I enabled the power up timer and set brown-out to ensure the PIC turns off/on properly.

Added a .1uf capacitor to the MCLR, seems to help. but doesn't really eradicate the problem

[temtronic]

As RF D says 'hot plugging' can be 'tricky'. One possible hardware solution is to use 'USB' style connectors. These by their design, connect power ( +5 and GND) before communitacions( D+ and D-). I did this for a 'bench test --- proof of concept' 2 decades ago. Worked fine, never damaged the PIC after a week long trial of yanking out, plugging in.

Now the only issue is that you have to remember they are 'connectors' NOT USB ports !!!, so label them 'NOT USB'.

Jay

[staan]

Thanks for the response,

As said, I tried to check the clock speed when the UART doesn't work. Seems to be alright. Is there a way to initialize UART dynamically in the program after a delay ( I am aware of NOINIT option in #use rs232), rather than using it in the preprocessor #use rs232 ?
Do you think it'll work?

[Ttelmah]

If the UART is being damaged, being 'initialised' or not, won't change things.

What connector are you using for the connection?. What provides the ground?.
The 'odds' are what is happening, is the two bits of kit have floated to different voltages, and the signal pins are connecting before the grounds. The current flow when this happens may be enormous for a short time, and this is going through to the PIC UART.

If your answer to this is 'but they have the same ground', then think where this actually 'routes'. It is common for the same ground signal to actually have different voltages along it depending on where it actually comes from in a circuit.

[staan]

I use a molex 2510 connector, and yes, the odds of a working UART does seem to depend on the connector.

The ground and supply are routed from the main board.
minimal potential difference between two grounds.

I have a MAX232 before the UART.

I can understand that the supply line or the TX/RX lines connecting before the reference (GND) can result as large voltage.

[Ttelmah]

'Minimal potential differences', can be the worst type of connection...

There was a system some years ago, that had a connection to a serial printer 'built in'. Used common grounds, but if you connected the printer, it'd about 20% of the time blow the port. The reason was that the (tiny) motor in the printer resulted in just under half a volt difference between the two grounds. Though the voltage was tiny, if you measured the current that flowed at the moment of connection, it was for a few nSec, over an amp.....

Some connectors (as with the USB mentioned), have versions that make one or more pins before the others. These should always be used for anything requiring 'hot plugging'.

[staan]

Turns out that its the connector that has resulted in UART to hang (Signals momentarily connecting before the GND and Supply.)

I tested out four different connectors
1)Dupont 2.00mm
2) Molex 2510
3) A modified RJ45 with guide
4) And a DIN connector

1) I couldn't get the UART working with the DUPONT
2) The 2510 had the odds of 4/10
3) odds of 9/10 for the DIN (shell connector to GND)
4) The modified RJ45 worked every time and i tried for more than 50 times

Then I noticed that most Chinese control boards come with an RJ45 for external wired connection.

By minimal potential differences I mean less than 0. 05V

What actually happens when when you hot plug is that the connected device/board draws current form the host instantaneously (ex. charging a cap or an inductor) this causes drop in voltage for the host, the host brown out s, provided that your connector connects supply and ground first. If its not the case then the signals connecting first could have 'God knows what' voltage because of the static build up .

I plan to use an intelligent connector design and a hot-plug controller next time.

Thank you Ttelmah, temtronic and RF_Developer for all your responses.
I feel enlightened in the connectors dept. now.

[temtronic]

You really should try some USB connectors, if 4 pins is enough. They ARE designed for 'hot plugging' AND have a very good 'life span'. 'Old school' connectors HAD good(thick) gold plating on quality pins,but these days I've seen RJ45 units that the gold wore OFF after a few months use(maybe 100 uses !).
As you've found out, there is a World of difference in the quality of connectors ! Sadly most don't spend enough time researching/testing the critical connector. Maybe not as much fun as code crunching but vital if you want a reliable product.

Jay

[Ttelmah]

As a separate comment. Put resistors in line on the RS232 connection pins, and a thermistor in the +ve connection pin.

It sounds as if you are actually supplying power on the same connector. Now in this case you have a number of extra problems:

First, if a data line, and a +ve line make before the ground, this can reverse bias the transistor junctions in the driver as it tries to pull the ground pin down. Effectively the junction then behaves like a thyristor, and can become permanently damaged. Resistors in the data lines will prevent this.
Then when the power connections make, the source device, if it is supplying power, is suddenly presented by what is effectively a dead short, as it tries to charge the capacitors in the target device. Solution here is to limit the inrush current by having a thermistor in the +ve line. This will prevent brownout's on the source device.

[temtronic]

it'd be nice to see a schematic of your 'network'. Use a 3rd party to post the schematic as CCS can't do it. We'll be better able to help you design a better method of powering the project !

Jay