BBB: RS232/UARTs send "break" during power up

I have a MAX3232 connected to UART5 on a BBB. During power up; presumably before the dtb has been loaded to set the pinmux for the UART, I see a “break” sequence being sent. A break sequence is defined as “tx held low for a duration longer than 1 frame”.

Seems like pinmuxing won’t help because it occurs too late. According to the am335x data sheet the “zero state” for the corresponding pin is Z which presumably means the pin will be low (i.e. “emitting” 0’s) until the pinmux takes over and configures it as a UART pin which presumably brings it to idle (high).

Any ideas how to avoid this?

Thanks,

-W

The GPIO pins on most processors, are open inputs until configured.
So a weak pull up resistor to +3.3V (not the switched +3.3V) on the TX line between the Sitara pin and the MAX3232 input would likely fix your problem.
Once configured, the TX line will overpower the weak pull up resistor.

— Graham

That’s what I was afraid of. Sadly, the connected peripheral doesn’t respond well to the break (I’m guessing it’s missing it’s pullups for the RX line). I did try rebuilding u-boot with UART5 enabled in the hope that it would get configured sooner, but it appears the break happens immediately at power up before anything has happened.

I shall try a 10K pulllup on the TX line.

Thanks for the feedback!

-W

The 10K pull-up didn’t work. I didn’t think it would, the am335x drives the pins low during initialization and this is overcoming the pull-up [the outputs were never free-floating]. I think I should have used a MAX3222 and wired up the SHDN pin to a GPIO so that I could independently enable the level converter once the system is stable (assuming I can figure out the .dts incantation to make a GPIO pin work under jessie/3.14-ti).

-W

The 10K pull-up didn’t work. I didn’t think it would, the am335x drives the pins low during initialization and this is overcoming the pull-up [the outputs were never free-floating]. I think I should have used a MAX3222 and wired up the SHDN pin to a GPIO so that I could independently enable the level converter once the system is stable (assuming I can figure out the .dts incantation to make a GPIO pin work under jessie/3.14-ti).

Winston is it ?

Anyway, you could use Charles S’ universal-IO device tree overlay(s)

to do this for you. I understand that they are built into the latest images ( for several months now ).

https://github.com/cdsteinkuehler/beaglebone-universal-io

I meant to demonstrate this and write up a mini how-to, but have been really busy for the last several months . . .

The 10K pull-up didn’t work. I didn’t think it would, the am335x drives the pins low during initialization and this is overcoming the pull-up [the outputs were never free-floating]. I think I should have used a MAX3222 and wired up the SHDN pin to a GPIO so that I could independently enable the level converter once the system is stable (assuming I can figure out the .dts incantation to make a GPIO pin work under jessie/3.14-ti).

Winston is it ?

Yes.

Anyway, you could use Charles S’ universal-IO device tree overlay(s)

to do this for you. I understand that they are built into the latest images ( for several months now ).

https://github.com/cdsteinkuehler/beaglebone-universal-io

I meant to demonstrate this and write up a mini how-to, but have been really busy for the last several months . . .

I think my issue is more fundamental. The issue is really that the RS232 peripheral is connected when the BBB boots, for those first few ms, before it’s even loaded u-boot, the pinmux is at it’s default “zero” state and the UART pins are thus low which the peripheral reads as a stream of 0’s, this continues until the dtb (I’m using jessie/3.14) is loaded that enables the UART via the pinmuxing.

I had even tried building a custom version of u-boot that enabled UART5 (whereas normally it only enables UART0 for the console). Sadly, it still isn’t quick enough for the peripheral not to see enough 0’s to cause a serial break.

Thanks!

If the actual driver has an enable pin, then take an active low
(during initialization) pin, pull it down with a further resistor
(just in case), and then run that through an inverter (if needed) to
the enable on the MAX3222.

That way, the default behavior is disabled (for the driver), and
during bootup, the behavior is still disabled until your code
specifically enables the driver.

Harvey

@Harvey

Ah, good one ! I was just thinking “inverter” when I saw your post, but I am not an electronics engineer by any stretch of the imagination . . . wasn’t sure it would work.

@Winston.

OK, my bad. I was actually thinking this could be the case, but was unsure. Harvey’s suggestions seems plausible though.

@Harvey

Ah, good one ! I was just thinking "inverter" when I saw your post, but I
am not an electronics engineer by any stretch of the imagination . . .
wasn't sure it would work.

I'll admit to being one....

I have a similar problem with a display and a display controller. If
the display were to be enabled before the display controller, it would
(and does....) violate several of the rules where the manufacturer of
the display says ... and don't do this.....

So the trick is to run a line from the processor to the display
through a gate, as well as the enable line from the display chip.

Once the processor sees that the display is being driven (it can ask
the display chip)... *then* it allows the display to be enabled. Helps
no end when debugging the display drivers since the power would be on
when the display is not set up.

In similar situations, the processor (not a BBB) is started with pins
that are effectively inputs, and may or may not be weakly pulled up
(think large value resistor to VCC). Pulling the enable line *down*
(it's enabled when up) and connecting that line to a processor means
that the display is disabled until the processor says so.... not
before...

Harvey