Hi
I want to summarize known hw issues to point bpi-team to it and get bundled rensponse
V1.1:
@sinovoip can you give statements on these and when they are fixed?
Hi frank，
When powered on, if the uart tx is pulled high, it will cause this
We will remove R171 and R173 in the next SMT
This is an error caused by negligence when we first time SMT, and we have contacted the customer for repair. The same issues will not occur in future.
Hi simon,thanks for info
Ftdi and cp21xx is also reported to have the uart-wifi issue,but only with v1.1. i have no such issue with v1.0 and a cp2102 (edit: sry it is cp2104,cp2102 fail). So something has changed in v1.1. If it will be fixed in next rev it’s ok. I was not sure you’re working on it.i will try to compare v1.1 shematic with v1.0.
Edit: the circuit above is same in v1.1 and v1.0. So probably not the cause for the issues.
As steven told you，v1.1 are only adding hole for 2230 nvme, moving bootswitches together, add common usb2 and a sata power connector. We also bought pl2303 to test v1.0 and v1.1, both will have this issues. Also discussed this with steven, he recommend ftdi.We have tested ch340,cp2102,FT4232, all are ok.
Is there maybe ETA for 1.2? as at least the has stock https://pl.aliexpress.com/item/1005004716456913.html
hi, @simon, ch340G seems not working too, have one from r2pro-tests, currently have a larger ft232RL connected with mini-usb…i hope the CH340E i ordered recently working…cp2102 is also failing…cp2104 works,but found no small ones on ebay or aliexpress for in-case use
is there any other small usb2uart adapter having mounting-holes and micro-usb/usb-c connector working here? any way to fix this problem (in future hw-revs)?
For metal case i guess it needs some ventilation holes and holes for mounting a (40x40mm) fan. And selecting fan voltage by a switch (without soldering) would be nice.
I just tried my CH340G out, and no it doesn’t work.
Did you ever find out if that works?
These ch340 i ordered were 5v and not 3v3 so i have them not tested on r3.
So working are cp2104 (hard to get) and ft232rl
I actually use a CH341, that is primarly a SPI programmer. But tit has a UART jumper and RX TX pins to use it as an emulator.
You can shoot two birds with one stone with having thing like that. Just look for the version that has UART switch or jumper set.
For CH341 you also have to make sure it can operate with 3.3V signal level, you can easily kill the RX on the SoC be feeding it with 5V.
Why would you even need to feed any voltage? GND and I/O is enough.
EDIT.
I got it, There are boards with logic selection. Mine is only 3.3V.
Found some time to verify rst/factory-button again…i can now read the values from uboot (initial 1,pressed 0) on my v1.1 board with plugged m.2 nvme
So this is fixed
I have ESP-01S connected to my board, normally with the GND disconnected as I don’t want to leave the wifi to serial available all the time.
So my board crashes sometimes, and it seems to be a CH340 one.
Maybe the better hack I see for an ESP-01 
What firmware do you use?
My USB to Serial-TTL adapter is a DSD-TECH SH-U09C5 with 4 selectable TTL levels and a lot of pins I have never used! https://www.deshide.com/product-details.html?pid=303205&_t=1661493660
what is the state of the serial connection/ WLAN problem?
I’m using a MAX3232 to connect the BPI-R3 v1.1 via RS232 to my PC.
only power ups are affected. A reboot instead has no effect. I.e. WLAN keeps working OK or keeps failing dependend on the state of the initial power up.
so the BPI-R3 for me apparently misinterprets a connected TX (producing some voltage) as strapping pin which prevents WLAN from working later. Strapping pins only are scanned within a few seconds after a power up and NOT after a warm reboot. That’s why you may reconnect TX on the fly a few seconds after power up and everything works like a charm.
permanently grounding the TX serial line via an 1K resistor lowers the voltage sufficiently enough to workaround the issue in all situations.
UPDATE: a 3.2k resistor still is sufficient to work around the problem. Higher values don’t safely work around though (at least for MAX3232)
Imho state on r3 state have not changed.
You mean tx on r3 side or on your adapters side?
You have connected tx/rx to gnd on your adapter or somewhere on r3?
a 3.2k resistor simply anywhere between BPI-R3/TX (e.g. TX on BPI-R3 serial pin header) and ground works.
BPI-R3/RX is not affected at all. I.e. RX line may stay connected at any time (even without work around) and has no impact on the issue
so my theory is: the BPI-R3 firmware scans the voltage on TX (instantly after power up) and if there is detected a ‘high state’ WLAN fails later (i.e. wlan0/wlan1 devices are missing). If you power up the board with disconnected TX but manually connect a few seconds later (long before the first kernel messages appear) the problem does never occur. So the firmware scans the strap at the very beginning of a power up.
The value of the resistor would depend on the value of the pull-up resistor used on the uart. It would not always be the same on every uart.
Easiest fix is get another uart.
correct. The value of the workaround-“pull-down” resistor depends on the “strength” of the voltage inadvertently produced on the TX line (originating from the connected serial adapter).
I have no choice. I must use my MAX3232 (only for level shifting) to connect over RS232. The workaround described above simply works. But basically works for all other serial adapters as well. That’s enough for me ATM. Thanks for listening.