3,3V and 5V shorted together would most certainly have been something undesirable. Pity that the FTDI only puts out 5V on that header and not a voltage level that is the same as the signal level.
The purpose of the buffer which was to prevent current coming from the the FTDI signals and powering the processor when power was off and the FTDI cable was still plugged in. It actually made it worse when we tried a pullup. So the weak pulldown was a compromise. If we ever do another revision, which is doubtful with all those clones out there, I would consider adding a pullup on the other side of the buffer again and see if we can get it to work. You could create a pullup by using a voltage divider between the 5V rail and ground and connecting your pullup to that. Or you can add look at adding pullup via SW on the RX pin. Gerald On Thu, Aug 13, 2015 at 6:38 PM, Colin Bester <bester.co...@gmail.com> wrote: > I just took a look at Rev C schematics and there is a 100K pulldown on the > RX pin so I wouldn’t have expected pulling directly to ground to make it > any worse. All in all 100K is not much of a pull down, but I do agree that > pull up is what you want - that at least is idle state on a serial line > (from what I recall). My gut feel would be to use around a 3K resistor > would should allow plenty headroom for hooking up a serial monitor if you > ever wanted to - its a real pity that there is no convenient 3V3 on the > monitor header. > > ~C > > On Aug 13, 2015, at 6:25 PM, AQG Chris <cwal...@gmail.com> wrote: > > I'll chime in again too - we originally tested our 3v3-rx jumper with a > direct connection, but then decided it might be nice to keep the ability to > use the serial debug port. Right now we've got a 470 ohm resistor pulling > rx up, which seems to allow communication over serial still. We also tried > values of 220 through 1kohm and were still able to send characters to > uart0. 100 ohm was too low to send anything over serial. I've not done > extensive reboot testing yet with each of these, but we will likely settle > on either 470 or 1kohm. > > If you probe the RX pin of the BB with nothing attached, we find 0v. The > TX pin (both on the BB and on the FTDI board we attach to the BB) is at > 3.3v by default, and we've also noticed that the problem never occurs when > we're hooked up to uart0 with our FTDI chip adapter. That made pulling the > line up rather than down an attractive option. We did try pulling RX down > to ground at some point, but the very first test I did after that resulted > in power LED on but no boot. > > We still haven't done a mass deployment, so for now I'm taking our smaller > testing runs and experiences like Ivan's to guide us. Sidenote - yes, we > have noticed eth0 not showing up as well, although it's not critical for > our application. > > On Thursday, August 13, 2015 at 4:04:34 PM UTC-7, Colin Bester wrote: >> >> In my case I am running 3.8.13-bone68 and system is pretty darn solid if >> it does start up. I have not seen Ethernet fail nor have I had any random >> reboots, but occasional I do have a device not power up when power is >> applied. We have not been able to determine a consistent cause and I am not >> convinced it's due to the mentioned RX pin as I am pretty sure I saw that >> this pin is pulled low (which I still think is wrong polarity) on rev C >> boards. >> >> In addition, we have physically blocked off the PWR button and only >> expose the reset button via a small pin hole in our enclosure. >> >> >> >> On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com >> wrote: >>> >>> Hi Robert, >>> >>> > Please confirm which kernel your running >>> >>> 3.8.13-bone71 (updated beginning of last June) >>> >>> > There's a big thread on this list, where a bunch spend about 2 weeks >>> bisecting the v4.1.x kernel to find the cause of the "random" reboot.. >>> >>> I don't have an issue though with random reboots - the reboots are >>> initiated on purpose by my application (because of the eth0 problem) - but >>> as described 2 in 30,000 reboots failed. >>> >>> Cheers, >>> Ivan >>> >>> > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to a topic in the > Google Groups "BeagleBoard" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/beagleboard/aXv6An1xfqI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > beagleboard+unsubscr...@googlegroups.com. > For more options, visit 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 beagleboard+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Gerald ger...@beagleboard.org http://beagleboard.org/ -- 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
