Hi @Sumanth,
I do not have a Cubie A7A, so I cannot confirm the A733 pin mapping itself, but the boot hang you describe has come up on several Radxa boards and the cause is almost always the same: the 40-pin UART is also U-Boot’s console, and U-Boot stops the boot as soon as a single character arrives on RX during the Hit any key to stop autoboot window. A sensor that starts sending at power-on does exactly that, and so does a floating wire acting as an antenna. The board is then sitting at the U-Boot prompt, which from the outside looks like a hang.
Earlier reports of the same failure on other Radxa boards:
You can confirm it in a couple of minutes, and the wiring for the test is the important part. UART is always cross-wired, so the wire that hangs your board is the one going into the board’s RX. For the test, leave exactly that wire off and capture the log one-way:
(A) Normal console wiring, and the direction that stops autoboot
Board USB-TTL adapter
TX (pin 8) -------------> RX
RX (pin 10) <------------- TX <-- one character here stops U-Boot
GND (pin 6) -------------- GND
(B) Capture only. Use this for the test: the board can never receive anything.
Board USB-TTL adapter
TX (pin 8) -------------> RX
RX (pin 10) (no wire) TX <-- leave this one disconnected
GND (pin 6) -------------- GND
(C) Your radar
Radar Board
TX ----------------------> RX (pin 10) <-- the line that hangs the boot
RX <---------------------- TX (pin 8)
GND ----------------------- GND
Wiring points that catch people out: TX always goes to RX and never TX to TX; GND must be common between all three devices; do not connect the adapter’s VCC/5V pin if the board has its own supply; and the radar must be 3.3 V logic, since 5 V TTL on an RK/A733 pin is out of spec even when it appears to work.
With wiring (B) and the radar still connected, capture the boot log. If you see U-Boot print the autoboot countdown, then a few garbage characters, then a => prompt, that is your hang.
Three ways to fix it, in the order I would try them:
- Keep the radar TX off the pin until the board has booted. A series switch, or a small FET or buffer enabled from a GPIO after boot, is enough.
- Disable the autoboot interrupt:
CONFIG_BOOTDELAY=-2 when you rebuild U-Boot, or bootdelay=-2 in the environment if your build lets you save it.
- Add a 10k pull-down on the RX line, or a buffer that is only enabled after boot, so noise cannot reach the SoC while U-Boot is counting down.
About “no UART data is received even after boot”: if that UART is the console, Linux is very likely still holding it. Check /proc/cmdline for console=ttyAS2,... and check whether a login service is attached with systemctl status serial-getty@ttyAS2. Anything the radar sends is consumed by the console and the getty, so both have to go before the port is usable for a sensor. If the header exposes another UART, moving the sensor there and leaving the console UART alone is much less painful.
One more failure mode worth ruling out, if you ever see no console output and no power LED at all: on ROCK 5C the header pins 8, 10, 27 and 28 sit in the PMUIO domain (VCC_3V3_PMU, always on), and an external device driving one of those pins while the board is unpowered back-feeds that rail through the SoC ESD clamps, so the PMIC never starts. If your radar has its own supply, power it from the board instead, or gate it, so it can never drive the pin before the board’s own rails are up. The two are easy to tell apart: an interrupted autoboot gives you a normal boot log that stops at the U-Boot prompt, back-feeding gives you nothing at all.
If it is neither, post the boot log captured over TX only, plus /proc/cmdline and dmesg | grep -i uart. With that, the pin mapping question becomes much easier to answer as well.
Which physical header pins are actually mapped by sun60iw2p1-uart2.dtbo on Cubie A7A?
Does Cubie A7A require disabling the boot console beyond console=ttyAS0 to safely use UART RX pins?
Are GPIO UART RX pins 5V tolerant?
Is there a recommended non-console UART exposed on the header that is safe for always-transmitting devices?
Are there any known issues with UART RX lines on the A7A when external devices send data immediately at power-on