BBG fried. Hint needed to undestand why.

My BBGreen got fried (when I power it up it just dims once the power led and that’s all it does).

an 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.

You didn’t have a magic jack plugged in did you?

No, no magic jack plugged in :slight_smile:

El dilluns, 7 març de 2016 14:18:30 UTC+1, lazarman va escriure:

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:

I would not recommend shorting outputs of two processor together, something might get fried.

Gerald

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

This reminds me of a nightmare job I inherited. I showed up at clients site he had 2 processors communication via McBSP a bread board and some line drivers in between and asked why his software wasn’t working. Turns out he had the wrong voltage version of the chips on his Bread board in the middle

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:

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

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:

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

Thanks. I’ll do it better in the future with your advices!

El dissabte, 12 març de 2016 1:06:29 UTC+1, john3909 va escriure: