Whenever you have separate systems that may power up at different times or the I/O configuration is unpredictable, then you should always use tristate buffers so that you don’t drive I/O until it is ready. Also, some GPIO are also used for boot configuration and these pins should not be driven during the boot process. The GPIO can tolerate I/O conflict for short durations, but if these conflicts persist over time, the processor will fail.
You could also add a 33 ohm resistor in series and monitor the TX/RX waveform. What you want to see is 0V and 3V3, but when you see stair step, then you have some conflict. Also watch for reflections which can occur when the lines are too long. This will typically cause ringing because of impedance mismatch and this can cause the voltage to exceed 3V3 or go below 0V. This will also cause processor failure. Regards, John > On Mar 11, 2016, at 3:32 PM, Jordi Segura <[email protected]> wrote: > > > Thanks @john3909. > This is to avoid having external power applied to the GPIO pins of the BBB/G > before is booted up which can damage the board right? > I suppose that was the the problem with my fried BBG. > > This should also apply with a single Tx board and a single Rx board > configuration rigth? > In my case the Tx sender micro (not a BBB) is powered from the VDD_3V3 pin of > the BBB. I've been running for more than one month without any issue in the > BBB until now. Should I also worry and use a tristate? > > Cheers, > Jordi > > > El divendres, 11 març de 2016 19:05:00 UTC+1, john3909 va escriure: > Use a tristate buffer between the BBB TX and the BBB/BBG RX. Use a 2 input > AND gate with the output connected to the buffer enable and a GPIO_EN from > the BBB RX board connected to on of the AND gate input and a GPIO_EN from the > BBG RX board to the other AND gate input. When both BBB/BBG board are fully > booted, and their RX pins configured as inputs, set the GPIO_EN pins high, so > that the buffer is no longer in tristate. > > Regards, > John > > > > >> On Mar 11, 2016, at 8:19 AM, Jordi Segura <jor...@ <>gmail.com >> <http://gmail.com/>> wrote: >> >> Thanks for answers so far. >> >> Yes my case is a single Tx output driving two Rx inputs. All processors are >> at 3.3 V. >> >> My original explanation of what I did: The BBG died after several days >> working 24/7, powered up from a power supply 5V 2A, with an 3G usb dongle >> connected on it, and (maybe that's my fault ...) I connected the Tx output >> of another microcontroller to one Rx input of the BBG but also to one Rx >> input of a BBB (I had both the BBG and the BBB receiving the same Tx signal >> from a third micro). >> The same power supply was powering both systems (BBG and BBB) and I also >> interconnected GNDs. The third micro sending the Tx signal was powered from >> the BBB. BBB is working well so far. >> >> Jordi >> >> El divendres, 11 març de 2016 17:00:01 UTC+1, Harvey White va escriure: >> On Fri, 11 Mar 2016 09:29:07 -0600, you wrote: >> >> >I would not recommend shorting outputs of two processor together, something >> >might get fried. >> >> Exactly right, the output drivers will likely overheat and perhaps be >> damaged when one chip is outputting a different state than the other. >> >> In this case, it was a single output driving two inputs. With >> properly connected grounds, there shouldn't be a problem with multiply >> connected outputs. >> >> However, the question may be one of voltages. The maximum voltage >> input to the processor is 3.3 volts, and if driven by a 5.0 volt >> source can certainly damage the processor. >> >> Paranoid design would have a buffer (running from the processor's VCC) >> connected to the real world, input to the real world, output to the >> processor. At the other end (driving end) you use another buffer to >> drive the line, both must be either inverting or non-inverting. For >> each additional input to another processor, use another buffer. >> >> If the processors use different supply voltages, then you would want a >> circuit to translate the voltage levels. There are chips that are >> designed to do that. >> >> I use a similar idea when connecting I2C driven systems (PCA9517 works >> well). >> >> RS-232 drivers work the same way, and in fact, would be very tolerant >> of voltage level differences. I'd suggest a MAX232 style chip. The >> outputs of the chip are +/- 9 volts, so absolutely cannot be connected >> directly to a processor. >> >> Harvey >> >> >> > >> >Gerald >> > >> >On Fri, Mar 11, 2016 at 9:27 AM, Jordi Segura <jor...@ <>gmail.com >> ><http://gmail.com/>> wrote: >> > >> >> Related to my unanswered problem below, main point I want to know is: >> >> >> >> Is it safe to connect directly the same Tx external signal simultaneously >> >> to a couple of BBs ? >> >> >> >> Cheers, >> >> Jordi >> >> >> >> El dilluns, 7 març de 2016 0:11:32 UTC+1, Jordi Segura va escriure: >> >>> >> >>> My BBGreen got fried (when I power it up it just dims once the power led >> >>> and that's all it does). >> >>> >> >>> >> >>> Can someone explain me what I did wrong so it won't happen to me or >> >>> others again? >> >>> >> >>> >> >>> Explanation of what I did: The BBG died after several days working 24/7, >> >>> powered up from a power supply 5V 2A, with an 3G usb dongle connected on >> >>> it, and (maybe that's my fault ...) I connected the Tx output of another >> >>> microcontroller to one Rx input of the BBG but also to one Rx input of a >> >>> BBB (I had both the BBG and the BBB receiving the same Tx signal from a >> >>> third micro) >> >>> The same power supply was powering both systems (BBG and BBB) and I also >> >>> interconnected GNDs. The third micro sending the Tx signal was powered >> >>> from >> >>> the BBB. BBB is working well so far. >> >>> >> >>> >> >>> Cheers. >> >>> >> >> -- >> >> For more options, visit http://beagleboard.org/discuss >> >> <http://beagleboard.org/discuss> >> >> --- >> >> You received this message because you are subscribed to the Google Groups >> >> "BeagleBoard" group. >> >> To unsubscribe from this group and stop receiving emails from it, send an >> >> email to beagleboard...@ <>googlegroups.com <http://googlegroups.com/>. >> >> For more options, visit https://groups.google.com/d/optout >> >> <https://groups.google.com/d/optout>. >> >> >> > >> > >> > >> >-- >> >Gerald >> > >> >ger...@ <>beagleboard.org <http://beagleboard.org/> >> >http://beagleboard.org/ <http://beagleboard.org/> >> >> >> -- >> For more options, visit http://beagleboard.org/discuss >> <http://beagleboard.org/discuss> >> --- >> You received this message because you are subscribed to the Google Groups >> "BeagleBoard" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to beagleboard...@ <>googlegroups.com <http://googlegroups.com/>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > For more options, visit http://beagleboard.org/discuss > <http://beagleboard.org/discuss> > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
