Jump to content

Rock Pi 4B+ UART/UART4 no data


Vdue

Recommended Posts

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 by Vdue
typos
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 

 

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines