Problems with two Arduinos back-to-back on the GPIB bus

[WaveyDipole]

I am working on an Arduino based GPIB controller and have come across a rather strange issue when two Arduinos are placed back-to-back on the GPIB bus along with another GPIB device. Let me explain.

I have been working on a GPIB controller and have pretty much completed controller mode with using my Solatron 7150 DMM as a test instrument and so far everything seemed to work as expected. I then moved on to implementing a device mode. This required that two Arduinos be connected to the GPIB bus simultaneously – one acting as a controller and the second as the device. Since the controller has a GPIB cable to connect to an instrument, I left this attached to my Solatron, but also I the controller to a prototype board. This allowed me to also connect the second Arduino as well as a logic analyser so that I could develop device mode using the second Arduino and see what was happening with the various GPIB wires. This did not prove to be quite as  straightforward as I had hoped.

Firstly, I quickly discovered that the power draw exceeded USB limits which was resolved by using an externally powered USB hub. I then also found that the breadboard connections can be quite temperamental sometimes. Having noted that and working with it, I then discovered a further problem.

Now, I am aware that the Arduino has only sufficient current handling to drive two devices at most so maybe that is part of the issue. I’m also not sure whether the Logic Analyser adds something to the load but I quickly found some odd reliability issues. Sometimes I could read the meter, sometimes I could not. Sometimes I could send the meter commands, sometimes I could not. Sometimes the readings returned from the meter were corrupted. None of these issue occurred when just one Arduino was connected to the instrument.

Initially some work had to be done to ensure that the Arduino pins were in the correct state. For example that the "device" was not asserting signals when it should be listening. However, having got past these issues, the problems persisted. On the logic analyser I observed that when the second Arduino is turned off, all GPIB signals go high and occasionally the odd signal on a pin fluctuates rapidly. Disconnecting the second Arduino completely from the breadboard even without resetting the controller and instrument, restores normal operation between those two devices. On the other hand, just turning off the instrument allows successful communication between the two Arduinos. It seems like three is a crowd, but I can’t quite figure why that should be, and why when the second Arduino powered off, it still affects signal states between the remaining Arduino and instrument? As mentioned, disconnect that second Arduino from the circuit and everything works normally again.

Any thoughts?

[oPossum]

On the logic analyser I observed that when the second Arduino is turned off, all GPIB signals go high and occasionally the odd signal on a pin fluctuates rapidly. Disconnecting the second Arduino completely from the breadboard even without resetting the controller and instrument, restores normal operation between those two devices.

This is probably due to parasitic power via the GPIO pins. Ground reset instead of removing power.

Most likely problem is a flawed device implementation.

[WaveyDipole]

This is probably due to parasitic power via the GPIO pins. Ground reset instead of removing power.

Most likely problem is a flawed device implementation.

Thanks for your comment. Although I'm not entirely familiar with the term "parasitic power", I did observe that even after I disconnect the USB cable, one or two LEDs stay lit - although perhaps not to the same intensity. Since USB is now disconnected, the only way power can be getting to the board is, as you point out, via the GPIO pins. I have just tried disconnecting each wire in turn and found that one of the LEDs can be extinguished by disconnecting a particular wire, however the other LED cannot be extinguished by disconnecting any single wire. Both LEDs do extinguish when I pull all of the wires out, so it seems evident that power is getting there via multiple paths. With only two pins to spare (Rx/Tx excepted) there are plenty of wires with signals in different states connecting the two boards.

Regarding "ground reset", if this refers to the action of momentarily connecting RESET to GND, then I have found that all lines remain high while the reset button is pressed (i.e. RESET grounded) and become active again (as one expects) after the Arduino re-boots when the button is released. I will however try the reset button next time I start having problems reading from and sending to the instrument and see whether that clears it.

[Kilrah]

An unpowered device WILL affect signals unless specifically designed not to.
An arduino definitely isn't.

Each microcontroller pin has ESD protection diodes to GND and VCC to divert current from electrostatic discharges into the power supply instead of the chip itself. That means that all pins are clapmed on the high side to 0.7V above the microcontroller's supply voltage.
As your microcontroller is powered down it is now supplied with 0V. That means anything on the data lines above 0.7V is going to start "leaking" into the arduino's power supply, drawing more current on the lines than they're meant to carry which can bring them down, and can cause weird stuff due to the arduino being partially powered and potentially starting to run erratically and affecting the lines itself. Current may also be going wherever else depending on the circuitry you have and cause other weirdnesses.

So an arduino with direct connection of its GPIOs to a bus is not something you can leave connected to a bus when off.

Also you need a scope in addition to the logic analyzer. The LA alone can be very misleading since it either shows high or low but won't let you see that a line is actually in a completely invalid state in the middle.

[Kilrah]

Regarding "ground reset", if this refers to the action of momentarily connecting RESET to GND

No, what he says is leave the "unwanted" arduino powered, but tie its RESET line to ground (aka hold its RESET button down permanently) so it's effectively disabled, but since it's powered it's not causing the problems explained above.

[WaveyDipole]

As your microcontroller is powered down it is now supplied with 0V. That means anything on the data lines above 0.7V is going to start "leaking" into the arduino's power supply, drawing more current on the lines than they're meant to carry which can bring them down, and can cause weird stuff due to the arduino being partially powered and potentially starting to run erratically and affecting the lines itself. Current may also be going wherever else depending on the circuitry you have and cause other weirdnesses.

Thanks for that very clear explanation, which makes perfect sense and would certainly explain the issues that I have come across. I can see how this would cause random issues depending on the status of signals at the time, although I did notice that one particular analog pin seemed especially susceptible to fluctuation. This might also explain why communication between controller and instrument sometimes springs back to life again when the second Arduino is powered back up, as by applying power, the excessive or unexpected power drain is suddenly gone and the line state stabilizes, although sometimes signals are left in an unexpected state so then an error occurs. I have noticed that sometimes the instrument will assert SRQ indicating that it is in an error state and usually requiring reset.

Also you need a scope in addition to the logic analyzer. The LA alone can be very misleading since it either shows high or low but won't let you see that a line is actually in a completely invalid state in the middle.

Indeed, the fluctuation at times is so erratic and occurring with such frequency that it can only be attributed to noise rather than actual changes of state. I had also imagined the possibility that the line might be floating somewhere near mid-point and having trouble maintaining either state and therefore rapidly fluctuating. The reasons for that possibly you have also clearly explained. Of course, you are quite correct that a scope would have shown me that more clearly, however I had simply put it down to one of the above causes but just couldn't think of an explanation for why it was happening. It did throw me one time when I had the LA plugged in but forgot to power up any of the other devices and just got utter gibberish across several lines!

So I think it is now clear that the powered down Arduino needs to be disconnected. This is going to be a bit of a pain since there are some 16 wires that need to be re-connected each time. Hopefully it won't be much longer before I'm done with the project though.

[WaveyDipole]

Regarding "ground reset", if this refers to the action of momentarily connecting RESET to GND

No, what he says is leave the "unwanted" arduino powered, but tie its RESET line to ground (aka hold its RESET button down permanently) so it's effectively disabled, but since it's powered it's not causing the problems explained above.

Sorry, I perhaps didn't reply that clearly, but I was assuming exactly that - while the Arduino is not required to be "online", keep RESET tied to GND but the Arduino itself powered on. However, as I mentioned, holding down the reset button - which effectively does the same thing - still results in all [but one] GPIO lines going high. I guess this would suggest that the GPIO lines are de-activated and unpowered either way with same result?

UPDATE:
Just in case holing down the reset button behaves somehow differently, I just tried it with a piece of jumper wire between RST and GND and unfortunately it does the same thing. Actually its all GPIO pins except one - D13, that go high. D13 is the only one that stays low. Whatever the case, reset to ground does not actually seem to solve the problem.

[Kilrah]

While RESET is active all GPIOs are tri-stated so effectively disconnected as far as the micro only is concerned, so it's whatever else you have on the circuit that drives the lines high.

You never said what Arduino you were using nor if there were additional components so can't really guess here. BUT AFAIK on most arduinos D13 is connected to the onboard LED, so even if the micro is in RESET and "disconnected" the LED is still there, so your line is now powering the LED and likely being brought down by it. You probably do NOT want the LED connected to the bus at anytime so might want not to use D13.

[Kasper]

Looks like power flow through internal esd diodes has already been covered here but if it doesn't make total sense, Dave explains it well in this video.

https://www.eevblog.com/forum/blog/eevblog-831-power-a-micro-with-no-power-pin!/

[WaveyDipole]

I am using a pair of Arduino UNO compatible. There are no other components involved except the prototype board as a means of interconnection.

Pin 13 is being used because there seem to be no other available pins that can be used safely. I had issues with pin 2, 3 and pin 6. I understand that only pin 2 and 3 are available on the Uno for attachInterrupt() to hook. There are two specific cases where a response to an interrupt might yield an improvement in performance so I was keeping those two pins reserved for that purpose.

Pin 2 was used initially with attachInterrupt() to detect a change in state of a particular GPIB signal line. This worked until I discovered and configmed with the LA that the interrupt was being fired even when a change of state was not occurring. It works fine when used without attachInterrupt() so reverted the code to polling the state of the pin on each cycle of the loop.

On pin 3, attachInterrupt() didn't seem to work at all as it never detected changes in state in either direction. It might still be possible to use this pin instead of pin 13, but I was keeping it clear in case I found a solution to this particular problem.

On pin 6, which was used for only for listening, I observed random changes of state for no apparent reason.

Please note that the above problems were without the added issue of the second Arduino attached as described here and were encountered well before I reached that phase of the project.

From research I suspect that the issue with pin 6 is that it is shared with the timer interrupt and I am using in delay(), delayMicroseconds() and millis() functions in the code. Reading between the lines on various forums it looks like there are other shared interrupts which might explain the odd behavior of other pins but without any specific information as to how the interrupts are mapped to pins I cannot say for sure.

My choice of pins is therefore rather limited but thanks for your point about the LED.

I watched the video (after manually correcting the URL - needs !/ adding on to the end) with interest.

[Kilrah]

Well you can always just remove the LED from the board

The interrupt issues seem weird. Again a scope would hep ensuring there are no transients or invalid levels on the lines.

[WaveyDipole]

Well you can always just remove the LED from the board

That idea did occur to me and I was going to ask the question but you answered it before I even asked it!

The interrupt issues seem weird. Again a scope would hep ensuring there are no transients or invalid levels on the lines.

Yes, I intend to investigate in more detail when I have finished the current programming tasks that I have on my todo list and as you recommend, a scope will almost certainly need to be pressed into service for those investigations.