2

I have a modem that I'm trying to get into. It's composed of two SoCs, both with UART headers. I was already successful trying to connect to the first SoC's UART, with my USB-to-UART CP2102 decoder chip happily both sending and receiving bytes at 115200bps 8N1, being dropped at a Busybox shell.

I hadn't had the same luck with the second SoC. It has the exact same physical header, and judging by the signal on the oscilloscope it seems to be the same kind of UART as the first one, that I can even decode some bytes manually, but the CP2102 seems unable to.

Here you can see the first four bytes sent on the TX line immediately when the board is powered on with a manual decoding, inferring that the signal is indeed UART with 0-3.3V levels, 115200bps (8.0 microseconds per bit), one stop bit and no parity bits:

Manual decoding of UART signal from oscilloscope

If my assumptions are right, the first four bytes are an ASCII "HELO". Superimposed on the image there's my manual decoding. B is the Start Bit, E is the Stop Bit, and I'm assuming the least significant bit comes first.

Some variations on the encoding settings have already been tried, like setting odd and even parity, using one or two stop bits, and even using a speed immediately above or below. The terminal, however, still shows nothing. I know that the decoder is working because it's happily receiving data when connected to the first SoC, but it does not decode anything from the second.

I disabled both hardware flow control lines and software flow control signals on the decoder, and I'm failing to see anything else that might be wrong, except some minor timing issues: the baud seems to have 8.6~8 microseconds instead of 8.0. However, I think that's still within the error margin.

The SoC in question is a Broadcom BCM68380, which someone already posted the bootlog on the internet and indeed it shows the same first four bytes: https://www.tripleoxygen.net/wiki/modem/rtf3505vw-gv

What could I be missing here? Why can't I decode this?

1 Answer 1

3

Answering my own question: just figured out that the board that the CP2102 decoder was mounted on had a LED wired to the RXD line. It happens that this board was poorly designed, and this LED was set to lit when the line was brought to LOW, and therefore the other pole of the LED was connected to the Vcc line.

The LED was then acting essentially as a pull-up resistor, and this second SoC had a very low sink current (unlike the first one), therefore rendering the LOW level "weak". Measuring the line level with a 10 MegaOhm probe showed that just with the probe load it was able to reach very close to 0V, but the line only got to 1.56V when it had the CP2102 plus the LED connected to it. Henceforth, the decoder chip was unable to detect this level as LOW, consequently unable to decode anything.

Removing the LED from the board fixed the issue. A careful design of the decoder board should have included a buffer FET between the LED and the RXD line. I don't remember where I bought the board, and it has no model/brand on it, so here's a reference photo:

Photo of the CP2102 board with the culprit LED highlighted

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.