-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi there Shu et al.
On 2014-11-03 22:12, Shu Liu wrote: > You don't have to remove the whole U15. You can just give a 3.3V > pull-up to the 4th PIN on the J1 connector. Then the board will not > be stuck at the UBOOT anymore. Really? My first hunch after reading Andrew and Marcus' posts was also that the RX line just needed to be tied down. But after seeing that R165 already does this, my suspicion was that it might be caused by the SN74LVC2G241 doing some hiccups on the CPU during early power because of OE and _OE being constantly active. This is contradicted of your above experience, or at least also makes the noise dependent on the 241's 1A input, which agreed does also seem plausible. Inserting a "pull up" as you suggest, however does make this and R165 a voltage divider keeping the B_UART0_RX input on ~1.4V (at least when 3V3 and DGND has stabilized). Have you tried if the uart0 port is functional after this modification? Inspired by your input I've now done more tests which confirms your experiences. Find them here; http://www.mikini.dk/index.php/2014/11/beaglebone-black-periodic-boot-failure-fixing-b_uart0_rx-with-voltage-divider Funny thing though, I tried increasing the pull down done by R165 (100k->45k), that didn't alleviate the problem as I kind-of expected. Could the issue be that DGND and/or 3V3 actually isn't stable in periods where the 241 has power and is gating 1A through to 1Y? > My question is how to fix it from software perspective? In u-Boot > source, how can we make sure it is not stuck? I've yet only skimmed the posts about the software fix, as I prefer understanding the problem fully before settling on a fix. I regard issues like this as a hardware flaw, and it needs to be fixed in hardware. There might be software workarounds that can mend the symptoms on already existing boards, but that is part 2 for me so I'm not there, yet. One suggestion could be that the uart driver/uboot itself flushes the uart fifo during initialization, so that uboot only reacts on input made during the execution of the code that checks for interactivity. My guess is that the fifo gets filled with characters generated from noise early during power up, and it just sits there until uboot comes around yanking it out and interpreting it. I haven't looked at the uboot code yet, so this is pure speculation. Regards, - -- Mikkel ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUWLpWAAoJEJ2luFWzaTSaMEIIALOoGbABZn5F8Vbi9FQI92P/ I8PFMNp06ybldLHDORJpWpXRnOjIm2Ix5xSFKH5loyUqatoTjeg9ASfAB8m0AeKl JcD/c8lkzC8Z91Ygm7vZtx6SC/09VXuWSd6x6mWvzf1tI9NmCaMReGMalvrLN58X CxfFriqliE9qouI3kOHIJp8FVAmyMFnzxOukgIpU56LV8xTOWwNIot7Q4dK9GXIg Twv+VPzKtSfW5mqKZKP6fhHqGmifWYcV19VI5onue0/rpBrPQM6w4NoJFOcRjTVA ijAuWiDTsgh5/949VOHJl5ansB9KqMn8DJe/2cBrCREUgBSB1B3yKxNa1kzDP2I= =SB8K -----END PGP SIGNATURE----- -- 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.
