How to send/receive multi-count IVC data frame?

I have set up the communication between CCPLEX and SPE based on the official example(l4t r32.7.3) .
But when I used the following command to deliver data:

sudo bash -c "echo 012345680000000000000000000000000000000000000000000000000000000000 > /sys/devices/aon_echo/data_channel"

I got a error:

tegra-aon-ivc-echo aon_echo: Message is greater than the frame s4
bash: line 0: echo: write error: Invalid argument

I know this error is related to the following code.
In tegra194-aon.dtsi, the frame size and frame count are controlled by

ivc_aon_echo@0 {                                                                                                                                          
            reg = <0x00000>, <0x10000>;
            reg-names = "rx", "tx";
            nvidia,frame-count = <16>;
            nvidia,frame-size = <64>;

My sending data size is 66 bytes which exceeds 64 bytes. This may be the reason of this error. However, I also want to know how to send a multi-count frame by the echo command or other manners. Since frame-count parameter is defined, a multi-count frame (max frame size = 16*64 = 1024 bytes) could also be sent I think.

you are right. Pre-defined message is 64-byte in length, and that’s only for reference.
To send larger messages, there are several ways, but some of them may need more coding.

  1. Easy way is to split the larger message into two, or more.
  2. Re-define the frame size/count. It needs updates from both Linux driver and SPE firmware side.
  3. Reserve an extra memory block as shared memory for bulk data sharing between CCPLEX (Linux) and SPE (FreeRTOS). You can check the current data_channel logic as an example.


1 Like

Thanks for your help. @jachen
But, you don’t answer my question fully. My question is that how to send a multi-count frame by the echo command or other manners if I don’t modify any both Linux driver and SPE firmware. In other word, how to understand this dtb attribute: nvidia,frame-count = <16>; ? Can I split the larger message into two, or more but send those messages(a multi-count frame) simultaneously? ’nvidia,frame-count‘ controls something, but I don’t understand it. According to my understanding, the official example creates a 16*64=1024-byte shared memory block. But now I only can exchange 64-byte data(one count frame). There should be a solution exchanging a two or more counts-frame under the official settings. This is what bothers me the most.

a simple way is to send multiple messages.
For example:
echo ‘0000…’ > xxx/data_channel
echo '1111…; > xxx/data_channel

frame-count is pre-defined in kernel/FreeRTOS side, and the buffer will be accessed within this range.
I’m not sure about your question by ’

But now I only can exchange 64-byte data(one count frame)

Every echo in Linux side will trigger a receive event in FreeRTOS side.


1 Like

I seem to understand your explanation. nvidia,frame-count = <16> means that the system creates 16 buffers (buffer0~buffer15), and the size of each buffer is 64-byte. If SPE does not read the data sent from CCPLEX in time, the data will be temporarily stored in the buffer, making the used buffer count increase. Is my understanding correct?

Your understanding is basically correct.
SPE has a task to check the message. Generally, when an echo in Linux side is executed, FreeRTOS will retrieve the message.

Please note that the data_channel is just a reference for demo. For real applications, you may have to consider several aspects, like sync, to make sure the messages are not overriden (buffer overrun), etc.


1 Like

Is ‘Sync’ as you mentioned equal to Hardware Synchronization Primitives (HSP) mentioned at TRM manual?


Is ‘Sync’ as you mentioned equal to Hardware Synchronization Primitives (HSP) mentioned at TRM manual?

No. It’s more like a software implementation. Please note that there’s no handshaking between CCPLEX and SPE R5 for data exchange through data_channel. You may have to develop extra logic to prevent losing messages. For example, if CCPLEX keeps pushing message, whereas SPE fails to retrieve messages in time, some errors may happen.


1 Like

Thanks for your help.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.