STM32MP157-DK2: Problem with UART7 when used with OPENAMP framework.

[USama1]

We are a connecting a sensor to M4 side and reading the data through UART7. UART7 is enabled for M4 by modifying the Linux Kernel Device tree and TF-A .dtsi files.

Device tree file for TF-A is generated through STM32CubeMX. and Placed the generated files in the /fdts folder of TF-A(Which was downloaded from stm git) and built it and loaded to the board using the given procedure.

We are able to read the UART data correctly when OPENAMP_Init() is not used.

This is blocker for our project and urgent help would be appreciated.

Thank you.

[Olivier GALLIEN]

Hi @USama​ 

For efficient support would you be ok to share dts files and M4 project source code ?

You can send it to me with a private message if you prefer.

Else please give us some insight about your application :

What HAL you use to manage the UART ?

Are you using printf redirection ?

Does the communication A7/M4 working when OpenAMP_Init() is done ?

Thanks

Olivier

[USama1]

Hi @Community member​ ,

I have sent the source code.

Both the OpenAMP and UART are working individually but not working when used in the same program. and We are not using any printf redirection. To manage UART, we are using the source generated with CubeMX.

Thank you.

Best Regards,

Upendar

[Olivier GALLIEN]

Hi @USama​ 

Thanks, got your project.

First assumption would be you may stay stuck in OpenAMP_init ()

Could you please better describe behavior when OpenAMP_Init() is there.

Complete application hang or application runs fine but just UART7 stuck ?

Did you try step by step debug on M4 ?

Else some traces on Linux side can be good to verify this assumption.

Please enable following dynamic trace :

echo -n 'file stm32_rproc.c +p' > /sys/kernel/debug/dynamic_debug/control

echo -n 'file stm32-ipcc.c +p' > /sys/kernel/debug/dynamic_debug/control

echo -n 'file remoteproc*.c +p' > /sys/kernel/debug/dynamic_debug/control

echo -n 'file virtio_rpmsg_bus.c +p' > /sys/kernel/debug/dynamic_debug/control

echo -n 'file virtio_ring.c +p' > /sys/kernel/debug/dynamic_debug/control

And share dmesg content after M4 firwmware start.

Thanks

Olivier

[USama1]

Hi @Community member​ ,

When I use OpenAMP_Init(), I am not getting proper data through UART7. I was able to read the header information with RP Lidar without OpenAMP_Init() but with it, I only get 0's.

I tried debugging but couldn;t understand much of OpenAMP code.

I will try dynmaic tracing from Linux side.

Thank you.

Best Regards,

Upendar Reddy

[Olivier GALLIEN]

Hi @USama​ 

Reading your code didn't trig any evidence about your issue.

One assumption would be an overlap of stack on the ipcc area.

Can you try to extend _Min_Stack_Size in .ld file ?

When you said you get 0 in case of OpenAMP, where did you get it ?

On Linux user side after sendmessageToA7 ?

Or right after getDeviceInfo ? ( breaking you m4 code and reading )

It may be useful to use the rproc trace to instrument your code. ( log.h/log.c lib)

Please enable it adding __LOG_TRACE_IO_ as precompile variable.

Then use printf or log_info at key steps in your code.

You can refer to Cube package example OpenAMP_TTY_echo for a reference code using it.

Hope it help,

Olivier

[Olivier GALLIEN]

Forgot to mention that you can also remove all code related to VIRT_UART1 as it seems you do not use it.

Olivier

[Olivier GALLIEN]

Hi @USama​ 

Did you manage to instrument your code with log traces ?

Else, it will require sometime in order we reproduce your issue.

Keep you posted

Olivier

[USama1]

Hi,
I have sent the dmesg log file. But didn't do the logging in the code.
If you have any sample project with OpenAMP and a peripheral interface, please provide us the code.
Best Regards,
Upendar

[Olivier GALLIEN]

Hi @USama​ 

Thanks for your trial about stack. We can eliminate this assumption.

Several other suggestions for trials :

• Move begin function where you initialize UART after OpenAMP_init()
• Try to use another UART like UART3 ( availlable on raspberry extension connector)
• Perform a step by step debug with SW4STM32 in UART function trying to investigate the problem
• As already suggested before instrument your code with log trace
• how is your sensor powered ? Did you check it is still properly powered for the OpenAMP scenario where you get 0s data ?

Hope it help

Olivier

[Olivier GALLIEN]

Hi @USama​ 

I have generated a project from scratch with CubeMX using UART7 and OpenAMP and didn't notice any issue with UART7 when OpenAMP is initialized.

Did you manage to instrument your code or perform a step by step debug in order trying to catch something ?

Looking at your project we have noticed a problem with DMA2 you initialize in M4 side while not assigned to m4 context in DeviceTree.

Could you please also tell us how is powered your sensor ?

Did you check it's still properly powered in case you get 0s ?

Hope it help

Olivier

[USama1]

Hi Olivier,   ​  Thanks for the feedback.  I am currently building a new image with generated device tree files.​ ( I am following a method given in How to Build your machine)   ​  I am assuming you also ​did the same thing.   ​  I didn't do the code instrumentation as of now.  I am trying establish UART communication with another DK2 board and assess the issue if there is any problem with the sensor.   ​  ​May you could share some info on device tree build.    ​  Best Regards,   Upendar Reddy​​

[Olivier GALLIEN]

Hi @USama​ 

Sorry I'm a bit lost. In your original post you mentioned you properly followed a procedure to rebuild dts and TF-A ...

And now I understand you didn't ? Can you please clarify ?

Thanks

Olivier

[USama1]

Hi Olivier,
There are multiple ways given to build the dts files​. Earlier I used Developer Package method.
Based on your feedback on DMA2 not being in m4 peripherals, now I chose to build Distribution package method.
Sorry for confusion.
How did you build your dts files from CubeMx?
Best Regards,
Upendar​

[Olivier GALLIEN]

Hi Upendar,

Since you don't target to modify the kernel configuration or need to add specific package to the distribution the Developer package method look faster for me.

But both might work.

I think you went through https://wiki.st.com/stm32mpu/wiki/STM32MP1_Developer_Package to setup your environnement

Then https://wiki.st.com/stm32mpu/wiki/How_to_cross-compile_with_the_Developer_Package#Modifying_the_Linux_kernel_device_tree

Don't forget to use the tips to add green light on in kernel DT and a custom trace in TF-A to quickly confirm you are well booted on your new generated files.

Note that issue around DMA2 does not come from a problem of compilation but rather a problem of configuration in CubeMX.

Hope it help

Olivier

[USama1]

Hi Olivier,

Do mean to suggest to modify the given dts file(stm32mp157c-dk2.dts) with cubeMX generated file? I tried a different way. Placing the cubeMX generated dts file in the dts folder and adding the name in Makefile. But that seems not be working.

and Yes. I did enable the green LED in dts file. The light is glowing. But when i checked the status of the USART3 peripheral using

cat /proc/device-tree/m4\@0/m4_system_resources/serial\@4000f000 , result came as disabled even though it is enabled.

And there are multiple device trees exist in the kernel, and while booting up it is asking which one to take. But the one i added is not coming there. How can i configure that?

I know its all too messy right now. I need little bit help in understanding these things. :)

Thank you.

Best Regards,

Upendar

[Olivier GALLIEN]

Hi,

2 solutions :

1- compile the dts generated by CubeMX then once .dtb copied on target rename it with the default applied one stm32mp157c-dk2.dtb

2 - you can create a new configuration entry in /boot/extlinux/extlinux.conf you can select during boot

Olivier