Basic Scope Probing of Microcontroller Causing Very Odd Behavior- HELP Please ! - Page 1
Forum section: electronics / beginners

author: K1JOS
author_rank: Regular Contributor
timestamp: August 28, 2014, 01:16:26 pm
content: I am a hobbyist non-engineer newbie. While probing a simple microcontroller serial bus circuit on an Arduino(Mega) to an external device with my Agilent scope, I am finding a weird phenomenon that I think must be due to the 10x probe loading something down to give me screwy results. However what I am doing seems so basic, that I wonder how others would approach this.I have a a simple program (attached) to control the serial output to an external device via an external serial UART )(RS232. Before transmission I have to first raise a enable pin High on the Arduino tied to the external UART to enable it to receive data from Arduino. I then send out a fixed (constant) 5 byte data packet. I can monitor the data stream on another Arduino serial port attached to a laptop terminal.When left alone, all is fine on the laptop terminal. However if i take my 10x probe to the TX or Enable pin on the microcontroller a very odd thing happens that persists after applying the test probe. The TX to the external UART stops, as does the Enable pin being switched from Low to High and on the laptop serial monitor the 5th byte in the data packet becomes altered to another value!I have attached the code for anyone interested but this is independent of the code.My probing technique is to carefully move from pin to pin with the probe tip. Everything shares a common short ground lead. I have replaced the Arduino twice to make sure it wasn't something in the MCU. How can I avoid this problem particularly if working on something that I have less control over. What I am doing seems so basic that I would like to understand what I am doing wrong and how others would handle this?Here is the code:Code:#define Transmit HIGH#define Receive LOWbyte receivePacket ;int UART_Control = 22; // Set High to enable external UARTvoid setup (){Serial.begin (9600);Serial1.begin (9600);pinMode(UART_Control, OUTPUT); // sets Arduino pin for outputdigitalWrite(UART_Control, LOW); // sets LOW on external UART to allow UART to send to Arduinodelay(1);}void loop (){receivePacket = 2;receivePacket = 136;receivePacket = 49;receivePacket = 0;receivePacket = 4;SendSerial();}void SendSerial(){digitalWrite(UART_Control, HIGH); // sets the UART HIGHdelay(1);Serial.println("TX= ");for (int j=0; j < 5; j++){Serial1.write(receivePacket);Serial.print(receivePacket);Serial.println(" ");}Serial1.flush();digitalWrite(UART483_Control, LOW); // sets the RE LOW for Receive again}

author: SL4P
author_rank: Super Contributor
timestamp: August 28, 2014, 02:10:58 pm
content: So it's Arduino MEGA talking serially to another Arduino.Using external hardware UARTs rather than the on-chip UARTs.Transmitting Arduino sends 5-byte packets - no problem, and they are received and displayed by the 'receiver' without any problem - until you probe the sender's UART enable (on digital pin 22) - then oddities.If this is all there is to it - I'd be looking at decoupling caps around the sender CPU and UART. (Any reason not to use the on-chip serial?)Perhaps some other stray capacitance around the UART clock?Or perhaps a mix of 3V3 and 5V parts - right on the threshold of ewitching?

author: jlmoon
author_rank: Unknown
timestamp: August 28, 2014, 03:47:35 pm
content: Pull-ups or termination resistors required anywhere? I would look into that and also the 3v3 / 5v possibility.., how about ground references / CMI (common mode interference / noise)on ground bus between uP's when scope is attached.

author: JuKu
author_rank: Frequent Contributor
timestamp: August 28, 2014, 03:53:01 pm
content: Soinds like the enable pin is floating and taking high value from the charge on the probe tip.

author: K1JOS
author_rank: Regular Contributor
timestamp: August 28, 2014, 05:14:18 pm
content: The Mega pins are at 3.3v and the UART I am using is also a 3.3v device. This is actually a MAX3485 RS485 setup. So I use the MegaArduino two-wire hardware serial to communicate with the external MAX3485 plus a third Mega pin toggles the MAX3485 Enable pin. The Mega sets it from LOW (while Mega is receiving from MAX3485) to HIGH to enable the MAX3485 to receive from the MegaArduino. After I probe with my scope, the MegaArduino pin used to set the Enable on the UART no longer goes high and is stuck on LOW even though the Arduino code is telling it to be set to HIGH. Although the Arduinos's have internal pull-ups, I even added to the Mega a 10K external resistor to enabling pin that is tied to the 3.3V rail but it stays LOW always after my "probing". Any other advice to check out?

author: jlmoon
author_rank: Unknown
timestamp: August 28, 2014, 06:01:26 pm
content: In your code;"digitalWrite(UART483_Control, LOW); // sets the RE LOW for Receive again"where and when did you ever set UART483_Control to 'HIGH' ?I don't speak Arduino much.. only Microchip.. so I am kinda sorting out your details

author: David Hess
author_rank: Super Contributor
timestamp: August 28, 2014, 06:36:08 pm
content: The loading from a x10 probe is less than 20pF in parallel with 10 Mohms so it should not affect the circuit unless there is a problem like a tri-stated output. Even an open collector/drain output with a pullup resistor will ignore the load from a x10 probe.

author: jlmoon
author_rank: Unknown
timestamp: August 28, 2014, 07:05:19 pm
content: David,I'm wondering if there is some sort of coincidence issue in code that is causing the problem to look like hardware. Hardware port resets, getting trapped in interrupts, watch dog timers.. doing their tricks - no pun intended. So many things that could bang that pin around and make it behave bad. To think the other day I almost bought some RasPi's , Arduino's UnOs and stuff just to learn the ropes so I could overflow my thimble of intelligence on these devices.JLM

author: K1JOS
author_rank: Regular Contributor
timestamp: August 28, 2014, 09:14:13 pm
content: JLMoon -- the first of code in the Send Serial is:digitalWrite(UART_Control, HIGH); // sets the UART HIGHSorry for the cut and paste, there is a typo in the last reset it says UART483_Control but thats a typo. The actual code is all the same "UART_Control" label.The Arduinos pins are tri-state I think but I will check the documentation when I get home tonight. Assuming this is correct, is there something I should be doing with a tri-state pin to make sure it is set in the correct LOW and/or HIGH state? I did add a 10K pullup tied to the 3.3v rail but that made no difference.thanks again to all for advice

author: tggzzz
author_rank: Super Contributor
timestamp: September 02, 2014, 10:08:06 am
content: Quote from: David Hess on August 28, 2014, 06:36:08 pmThat depends on the resistance and the speed required.Back-of-envelope calculation. Assume highest frequency = 0.35/risetime, and Zc=1/(2*pi*f).A 10ns risetime equates to f = 35MHz, and at 35MHz a 20pF capacitance has am impedance of 220ohms. Can the driver supply enough current to pull a 220ohm load high?

author: idpromnut
author_rank: Unknown
timestamp: September 02, 2014, 10:31:37 am
content: Can you post the code for the receiver? Also, how did you verify that the enable pin is indeed toggling before probing it with the scope?

author: David Hess
author_rank: Super Contributor
timestamp: September 02, 2014, 12:05:28 pm
content: Quote from: tggzzz on September 02, 2014, 10:08:06 amIt looks like the speed is 9600 baud so very slow. The input resistance of a x10 probe is 10 MOhms so it will be pulled up but the question is how quickly.QuoteI usually calculate it in the opposite direction.Most CMOS drivers have an output resistance of 25 to 50 ohms so they will drive a x10 probe or oscilloscope vertical input directly to almost their rated bandwidth. More recent low voltage logic may have an even lower output resistance. Probe and oscilloscope bandwidth is specified assuming a 25 ohm source from a terminated 50 ohm transmission line which as you point out, yields unrealistic bandwidth with typical sources.If it really was an open collector/drain output but had a pullup, then the pullup resistor will limit the rise time but not the fall time. An order of magnitude higher than the 10kHz (roughly 9600 baud) is 100kHz. That would require an 80k pullup into 20 picofarads (3.5 microsecond rise) which is an outrageously high pullup resistance unless working with a micropower design. 4.7k is more typical but I have seen values of 1k to 47k. 220 ohms or lower is possible for some logic families but unrealistic in most applications whether the logic can drive it or not.On a related note, I have occasionally done quick and dirty RS-232 level shifts using a couple of 2N3904s to make a high level driver and they easily drive a x10 probe with a transition time of 50 nanoseconds or better. Real RS-232 drivers are slew rate limited to lower EMI.

author: tggzzz
author_rank: Super Contributor
timestamp: September 02, 2014, 03:03:06 pm
content: Quote from: David Hess on September 02, 2014, 12:05:28 pmHe refers "if i take my 10x probe to the TX or Enable pin on the microcontroller", so I would guess the edge rate is far higher than needed for a 9k6baud data signal. Consider, for example, what would happen if it caused a device to be mis-initialised due to setup/hold time violations.

author: David Hess
author_rank: Super Contributor
timestamp: September 02, 2014, 07:23:01 pm
content: Quote from: tggzzz on September 02, 2014, 03:03:06 pmI will not say that is impossible but I have difficulty imagining a setup and hold time violation on an asynchronous input.He can always just measure it. The oscilloscope will show what is happening.

author: tggzzz
author_rank: Super Contributor
timestamp: September 02, 2014, 07:33:42 pm
content: Quote from: David Hess on September 02, 2014, 07:23:01 pmAgreed.I've seen too many people that don't realise that scope probes arepartof the circuit under test, and you can infer the rest!

author: K1JOS
author_rank: Regular Contributor
timestamp: September 03, 2014, 12:24:55 am
content: Quote from: idpromnut on September 02, 2014, 10:31:37 amI have a much simpler setup that reproduces the problem - only one Arduino with 3 wires (RX, TX and Enable) to a MAX3485 RS485. Instead of another MAX3485/Arduino pair setup to RX and TX back and forth, I use the single Arduino/MAX3485 and bring the A and B RS485 bus lines out with a 330 ohm resistor load from each line to ground. I code a simple send routine that toggles the Enable pin high and after sending a 5 byte packet then sets the enable low. I have a delay of about 200msec between packets. I dont have any receive code on the RX line as I am just sending out on the TX line in 200msec bursts. I can monitor the enable pin state with my scope probe or a high impedance logic probe or with a scope probe on either line of the A -B bus of the MAX3485 chip as code will only appear on the bus when the enable pin is set high. As soon as I probe the enable pin direct, the TX stops and the enable pin is stuck LOW not high. The presence of the probe tip keeps the pin low and will not allow it to be set high bny the MCU even with a 5K resistor tied to Vcc on the enable pin.

author: Bukurat
author_rank: Regular Contributor
timestamp: September 03, 2014, 12:49:45 am
content: What do you see if you simplify further and remove the MAX3485?

author: idpromnut
author_rank: Unknown
timestamp: September 03, 2014, 02:20:46 am
content: I assume you have tied the /RE pin (on the MAX3485) to VCC with a pull up for this test, right?

author: K1JOS
author_rank: Regular Contributor
timestamp: September 07, 2014, 04:05:41 am
content: Yes, the enable pin has a 1k to Vcc. In the absence of the MAX485 the enable goes high as expected. I have replace the MAX485 with at least 2 new chips as same results. Its clearly something to do with the MAX485 interface, no problem otherwise pulling any pin high with code. I was hoping some RS485 experts might have seen this before.