On my side, I’m using the Dahlia carrier board (sometimes I also use the development board, but I don’t think it matters here) with the Verdin Mini and the serial cable connected to my computer (X18 USB type C on the Dahlia carrier board), so I can see both linux terminal and the UART from the M4.
I use picocom with a baud rate of 115200 to /dev/ttyUSB3 and /dev/ttyUSB2 to check the messages.
Same here, I use the “echo” command to test the RPMSG. This week I’ve also tested a container with python to write to /dev/ttyRPMSG30, if you want to check:
After running the echo command on linux, can’t you see any messages on the /dev/ttyUSB2?
After running the echo command on linux, can’t you see any messages on the /dev/ttyUSB2?
Yes, I see on /dev/ttyUSB2 that Cortex-M receives the message Get Message From Master Side : ...
But, then, Cortex-M echoes back the same message to /dev/ttyRPMSG30 and I’m not able to see it from the Linux side.
If I run cat /dev/ttyRPMSG30 I see a lot of empty lines and some messages, and I’m not sure this is ok.
EDIT:
I tried to deploy a python container as you did, but I use ApolloX extension and it fails for the same reason as the node.js sample.
Is there any document describing how to build and deploy python container with command line?
I could reproduce this issue. I think is caused by the “cat” itself and how it read the bytes from the buffer. I believe that “cat” reads one byte at a time and causes the buffer to be refreshed each time, causing an infinite loop.
Instead, I created a python script that writes to the buffer, waits a bit (I chose 1 second to make things easier), and then reads the echo message and it works as expected.
#!python3
import serial
from time import sleep
def main():
for i in range(10):
try:
with serial.Serial("/dev/ttyRPMSG30", 115200, timeout=1) as ser:
ser.write("Toradex Test! {}".format(i).encode())
sleep(1)
print("Bytes waiting in buffer: " + str(ser.in_waiting))
read = ser.read(ser.in_waiting)
print("Msg received: " + str(read))
print()
except Exception as err:
print(err)
if __name__ == "__main__":
main()
We can see all the message on the M4:
Get Message From Master Side : "Toradex Test!" [len : 13]
Get Message From Master Side : "Toradex Test!" [len : 13]
Get Message From Master Side : "Toradex Test! 0" [len : 15]
Get Message From Master Side : "Toradex Test! 1" [len : 15]
Get Message From Master Side : "Toradex Test! 2" [len : 15]
Get Message From Master Side : "Toradex Test! 3" [len : 15]
Get Message From Master Side : "Toradex Test! 4" [len : 15]
Get Message From Master Side : "Toradex Test! 5" [len : 15]
Get Message From Master Side : "Toradex Test! 6" [len : 15]
Get Message From Master Side : "Toradex Test! 7" [len : 15]
Get Message From Master Side : "Toradex Test! 8" [len : 15]
Get Message From Master Side : "Toradex Test! 9" [len : 15]
And then it echos back the message:
Bytes waiting in buffer: 15
Msg received: b'Toradex Test! 7'
Bytes waiting in buffer: 15
Msg received: b'Toradex Test! 8'
Bytes waiting in buffer: 15
Msg received: b'Toradex Test! 9'
Note on my code that I first check how many bytes are waiting in the buffer and then reads all the bytes at the same time, so the whole buffer gets consumed.
I’m also using ApolloX here. I just create a python sample from the template and added my code to main.py. added pyserial to the requirements file and shared the device under the docker compose file:
This a new overlay that was added into our repository a couple of weeks ago, so in order to get this automatically you will have to install TorizonCore 6.2 from the nonstable releases.
If you want to use it with the 6.1, you can also copy the source code and compile it yourself. This should work as well, as 6.2 is not stable yet.
Hi @hfranco.tx
I’m going to test the container after this issue is solved.
I’m going to upgrade TorizonCore to 6.2 since I want to stay aligned in this stage of my development.
You wrote about a file named verdin-imx8mp_hmp_overlay.dts (and usually imx8mp stays for iMX8M-Plus), but the link points to a file which is named verdin-imx8mm_hmp_overlay.dts (and usually imx8mm stays for iMX8M-Mini).
Is the file the same for Mini and Plus variants of the Verdin?
Hi @hfranco.tx
in the next few weeks I’m going to move my focus on the Plus (I’m in touch with sales office to evaluate the best solution), because the new requirements from the management involve two ethernet interfaces (and the HDMI).
Do you see any issue in having remoteproc/rpmsg working on Torizon for the Plus?
Let me know, because this is essential for the project.
Thanks
We have an overlay that is under review right now for the Plus, it should be merged on the device-tree repository in a few weeks. I can share it with you if you need it.
RPMSG works with the Verdin Plus, but to see the messages we need to disable the UART4 because the cortex M7 uses these pins. However, on the Plus, UART4 is also used for WiFi/BT control, as stated on its datasheet:
The Wi-Fi module is connected over a 4-bit SDIO interface with the i.MX 8M Plus SoC. It uses the
USDHC1 instance of the SoC. For Bluetooth Audio, an additional I2S interface is available between
the SoC and the Wi-Fi module, which uses the SAI5 instance of the SoC. The Bluetooth UART
signals (RX, TX, RTS, CTS) signals are connected to an alternate location of the UART4 of the SoC.
This interface can only be used if the Verdin standard UART_4 (M7 debug port) is not in use. It is
either possible to use the M7 debug UART or the Bluetooth UART simultaneously
So by using the debug port of the M7, you will lose this functionality. However, this port is usually only used for debugging, once you have your code running inside the M7 you can disable this debugging port or you can route the debug port of the M7 to a different UART that is available (although I never tried this option).
Now a note about the remote proc, currently it’s not working with our BSP 6/TC 6, only BSP 5/TC 5. We already have a ticket internally to investigate this issue, although I don’t have any updates right now. This doesn’t exclude the option of using the u-boot to load the binary, of course, but if you need the remote proc feature this can be an issue.
Do you mean that we need to disable UART4 on the TorizonCore side? Or something different?
Is UART4 disabled in the standard device tree included with TorizonCore?
If not, how can I disable it?
The overlay for the Plus was not merged yet, only for the Mini. I’ll keep you updated and can help with your overlay if needed.
In order to see the messages coming from Verdin Cortex-M7, this peripheral needs to be disabled from Linux. Can you share which hardware version are you using? Is it Wifi BT or the version without wifi?
