Rock Pi 4B+ UART/UART4 no data

[Vdue]

I am in the process to migrate a project from a Raspberry Pi 4B to a Rock Pi 4B+. Among others external devices shall be connected via WiFi AP, I2C, 1-Wire and UART to the Rock Pi. To emphasis, the system is running healthy on a Rasberry. I managed to get WiFi AP and 1-Wire up and running on the Rock Pi. Now I got stuck with UART/UART4.

Armbian 22.11.1 Bullseye with Linux 5.15.80-rockchip64

I enabled UART4 via Armbian-Config. Therefore, /boot/armbianEnv.txt shows:
...
overlays=i2c7 uart4 w1-gpio
param_w1_pin=GPIO4_D6
param_w1_pin_int_pullup=1
...

I can take a jump wire and bridge the TX-pin (GPIO1_B0, Pin#19) and RX-pin (GPIO1_A7, Pin#21). When sending bytes to the TX-pin I am receiving them instantly on the RX-Pin. That indicates to me the UART4 is working. On my system the serial port is /dev/ttyS4, with a baud rate of 1000!!. (I am doing this test via Node Red using a standard serial node)

However, if I connect my TTL-signal cable to the RX-pin (TX disconnected), I do not see anything the RX-Pin (however this setup works on the Rasberry).

I have done the same test on UART (/dev/ttyS2) with same result, not showing anything.

 

I have no experience in Armbian or Rock Pi and would appreciate any hint into which direction to look.

 

Is the unusual baud rate of 1000 a problem, or

do I need some pull-up resistors or

do I need to compile another dtbo driver like for the 1-wire?  

Edited January 5, 2023 by Vdue
typos

[Myron]

Can you please provide diagnostic logs for the Rock Pi 4B+ with ...

armbianmonitor -u

... and post the link here.  It'll may help others determine what the issue is.

[Vdue]

Sorry for the late replay, but your system only allows one message within 24h. Please find enclosed the link to the: Armbianmonitor file

[atone]

5 hours ago, Vdue said:

your system only allows one message within 24h

This measure serves to fight spam and will be relieved as soon are your membership request has been approved.

 

ff370000.serial: ttyS4 at MMIO 0xff370000 (irq = 46, base_baud = 1500000) is a 16550A

Did you tried with a baud rate of 1500000?

[Vdue]

Yes I tried 1500000 and that looks to me the hardcoded baud rate for /dev/ttyS2 in /boot/boot.cmd

 

The device only communicates with baud 1000 (it's a Votronic solar charge controller)

 

If I am doing a config in Node Red 1200-8N1 and an then in terminal $ stty -F /dev/ttyS4 I am getting:

speed 1200 baud; line = 0;

min = 1; time = 0;

-brkint -icrnl -imaxbel

-opost -onlcr

-isig -icanon -iexten -echo -echoe -echok -echoctl -echoke

 

with Node Red 1000-8N1 and $ stty -F /dev/ttyS4:

speed 0 baud; line = 0;

min = 1; time = 0;

....

 

and stty -F /dev/ttyS4 1000 produces

tty: invalid argument ‘1000’

 

Now I can pinpoint 1000 Baud is a problem, can this be overcome without putting a ISP32 data collector in-between 

 

[atone]

On 1/5/2023 at 10:45 AM, Vdue said:

the unusual baud rate of 1000

According to this posts here, here and here  the baud rate depends on the clockrate and setting an unsual baud rate such as 1000 would imply overcloking (or underclocking) the CPU. But that's a lot of assumptions from me, so I hope that someone with more knowledge and experience will answer.

 

Edit: simplification.

[atone]

14 hours ago, Vdue said:

invalid argument ‘1000’

It seems that the baud rate parameter is being actively refused, as it's probably not allowed in a predefined list.

 

On 1/5/2023 at 10:45 AM, Vdue said:

I am doing this test via Node Red using a standard serial node

That could be the standard serial node...

 

14 hours ago, atone said:

ttyS4 at MMIO 0xff370000 (irq = 46, base_baud = 1500000) is a 16550A

... or the driver.

[Vdue]

2 hours ago, atone said:

... or the driver.

Atone, thanx for all your efforts. I solved it.

 

It's embarrassing to admit it was a ground issue. The Raspberry and the Rock Pi are sitting next to each other. The Raspi was powered under a real world scenario via a car battery and all devices were connected to the same ground (minus) terminal. I made a short cut for the Rock Pi, which I powered for this test via 15W wall power supply. Therefore, Rock Pi and devices were connected to different ground and that is bad, very bad indeed. And the Rock Pi even works with the odd 1000 Baud config. Why this is the case I do not understand but I do not care it works.

 

Thanx again for your efforts.

[Vdue]

1-wire, WiFI AP and UART are now nicely working.

 

Now I am facing a new problem with I2C, which I do not get to work. I enabled i2c7 via armbianEnv.txt and connected the device SDA cable to I2C7_SDA (Pin #3) and SCL cable to I2C7_SCL (Pin #5) and obviously the power cables to the device. 

 

nano /boot/armbianEnv.txt

....
overlays=i2c7 uart4 w1-gpio
param_w1_pin=GPIO4_D6
param_w1_pin_int_pullup=1
....

 

dmesg|grep i2c

[    1.719815] i2c_dev: i2c /dev entries driver
[    1.720785] i2c 1-0011: Fixing up cyclic dependency with ff880000.i2s

 

ls /dev/*i2c*

/dev/i2c-0  /dev/i2c-1	/dev/i2c-3  /dev/i2c-4	/dev/i2c-7

 

i2cdetect -y 1

     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- -- 
10: -- UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
70: -- -- -- -- -- -- -- -- 

 

 

I think I am close, but which essential config am I missing ?

 

The armbianmonitor file is here: link

[atone]

To query i2c-7:

i2cdetect -y 7

[Vdue]

YES, how stupid can a user be. Thanx it works.