Testing PIC

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Hi,

I'm testing a PIC by sending data to it's RX with a terminal (teraterm), the PIC works on the data and outputs the result to the TX, which I receive and read in a second Terminal.

I find that when the power is switched off, for PIC removal and re-programming or resetting, the terminal holds the PIC on via the TX and RX pins. I tried a 0.1uF capacitor in series with the RX TX connections and this appeared to solve the power problem, and seemed to work regarding the terminal.

Is this an acceptable way to work?

Camerart.
 

Papabravo

Joined Feb 24, 2006
21,157
Not really. What you have done is effectively AC couple Rx Data In to the transmitting source. For UART communications the data value is SUPPOSED to be stable for a large fraction of the bit time so that the value of the bit can be sampled near the middle of the bit cell. As a transmitter, the AC coupling makes it tough for the receiver to figure out what the value of a bit is when the level decays after each edge. It would be in your best interest to figure out why this is happening and find another solution. If the MCLR* pin is available as a RESET then you could at least hold the part in that state while you remove power and remove it from the fixture. Alternatively you could run Rx and Tx through a DPST switch.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Not really. What you have done is effectively AC couple Rx Data In to the transmitting source. For UART communications the data value is SUPPOSED to be stable for a large fraction of the bit time so that the value of the bit can be sampled near the middle of the bit cell. As a transmitter, the AC coupling makes it tough for the receiver to figure out what the value of a bit is when the level decays after each edge. It would be in your best interest to figure out why this is happening and find another solution. If the MCLR* pin is available as a RESET then you could at least hold the part in that state while you remove power and remove it from the fixture. Alternatively you could run Rx and Tx through a DPST switch.
Hi PB,

Ok, thanks. Good job, I asked as it appeared to be working ok.
There is a MCLR RESET button, and perhaps I could add break switches too.
Does the RESET act as if the PIC was disconnected from power and reconnected?

C.
 

Papabravo

Joined Feb 24, 2006
21,157
The primary purpose of activating MCLR* is to minimize the chance that the PIC is doing something while power is being removed. Since you say the voltage(s) on RX and Tx continue to power the part I'd like to see a schematic of the entire setup. I have a feeling there might be something else egregious going on. Just activating MCLR* is similar to power down/power up except for the bits in the STATUS and/or PCON register which allow the firmware to tell the difference between various initial conditions. Initial conditions like power on, RESET, watchdog timeout, and so forth.

Question: Are you using RS-232 transmitters and receivers to connect the PIC to the external terminals? If you shut down power to the PIC and the transceivers there should be nothing to power the PIC. If you are connecting RS-232 levels, potentially ±25 VDC to the PIC, that could be very bad indeed.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
The primary purpose of activating MCLR* is to minimize the chance that the PIC is doing something while power is being removed. Since you say the voltage(s) on RX and Tx continue to power the part I'd like to see a schematic of the entire setup. I have a feeling there might be something else egregious going on. Just activating MCLR* is similar to power down/power up except for the bits in the STATUS and/or PCON register which allow the firmware to tell the difference between various initial conditions. Initial conditions like power on, RESET, watchdog timeout, and so forth.

Question: Are you using RS-232 transmitters and receivers to connect the PIC to the external terminals? If you shut down power to the PIC and the transceivers there should be nothing to power the PIC. If you are connecting RS-232 levels, potentially ±25 VDC to the PIC, that could be very bad indeed.
Hi PB,
I think the answer then is to add break switches on the TX RX wires.
I use a pair of FTDI USB to 3.3v adaptors for TX RX.
I'm working far above my skills, and study the PIC data sheets intensely, but sad to say, mild dyslexia scrambles it up sometimes. Interesting though.
You have replied to my post: Solving an intermittent 18F2431 PIC problem, which this relates to.

Thanks, C.
 

ErnieM

Joined Apr 24, 2011
8,377
Those break switches are a very good solution. Your underlying problem is these little chips run off so little power they can quite simply run off the power coming in off an I/O pin thru the ESD diode that is typically there on most every pin.

So if a pin is high when power goes off the device stays on.

I first saw this decades ago when building a CMOS controller as part of a large team. I had trouble convincing my co workers some chips had no power connected as the thing was working. At the time I did not understand how it was working but I kept insisting until we added those wires.
 

Thread Starter

camerart

Joined Feb 25, 2013
3,724
Those break switches are a very good solution. Your underlying problem is these little chips run off so little power they can quite simply run off the power coming in off an I/O pin thru the ESD diode that is typically there on most every pin.

So if a pin is high when power goes off the device stays on.

I first saw this decades ago when building a CMOS controller as part of a large team. I had trouble convincing my co workers some chips had no power connected as the thing was working. At the time I did not understand how it was working but I kept insisting until we added those wires.
Hi E,

These little things are sent to try us! I've just been having problems with the macro sending my test data to the PIC. After spending all morning with the programming, it turned out to be WORDWRAP in the TEXT file. (I think:) )

C.
 
Top