embeddedRTPS-STM32

embeddedRTPS-STM32 copied to clipboard

Thanks for all authors! But I just cannot reproduce the behavior of the ertps-stm32.

Here is the issue.

Env

• hardware: stm32f767zi
• toolchain: gcc8-2019-q3
• cubeIDE: v6.4 with FW_V7 v1.16.0
• network: ubuntu2004(192.168.1.104), stm32(192.168.1.103), router(192.168.1.1)
• source: https://github.com/ZhenshengLee/embeddedRTPS-STM32/commit/3b983a3f749dd122cee7de7e9de3be87dd8b2c2f

Steps

change setting according to https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/blob/master/readme.md

delete auto-generated Src/main.c (not main.cpp) edit Middlewares/Third_Party/LwIP/system/arc/cc.h l41 as follows //#define LWIP_PROVIDE_ERRNO #define LWIP_ERRNO_INCLUDE <sys/errno.h> edit Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_eth.c l1877 as follows macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_ENABLE;

• change thread prio in stm32/rtps/include/rtps/config.h

       const uint8_t SPDP_WRITER_PRIO = 24;
        const uint8_t SPDP_MAX_NUMBER_FOUND_PARTICIPANTS = 5;
        const uint8_t SPDP_MAX_NUM_LOCATORS = 5;
        const Duration_t SPDP_LEASE_DURATION = {100, 0};

        const int MAX_NUM_UDP_CONNECTIONS = 10;

        const int THREAD_POOL_NUM_WRITERS = 1;
        const int THREAD_POOL_NUM_READERS = 1;
        const int THREAD_POOL_WRITER_PRIO = 24;
        const int THREAD_POOL_READER_PRIO = 24;

• change ip setting in stm32/rtps/thirdparty/lwip/lwipcfg.h

#define LWIP_PORT_INIT_IPADDR(addr)   IP4_ADDR((addr), 192,168,1,103)
#define LWIP_PORT_INIT_GW(addr)       IP4_ADDR((addr), 192,168,1,1)
#define LWIP_PORT_INIT_NETMASK(addr)  IP4_ADDR((addr), 255,255,255,0)

• change ip setting in stm32/rtps/include/rtps/config.h

const std::array<uint8_t, 4> IP_ADDRESS = {192,168,1,103};  // Needs to be set in lwipcfg.h too.

• change ip setting in stm32/Src/lwip.c

void MX_LWIP_Init(void)
{
  /* IP addresses initialization */
  IP_ADDRESS[0] = 192;
  IP_ADDRESS[1] = 168;
  IP_ADDRESS[2] = 1;
  IP_ADDRESS[3] = 103;
  NETMASK_ADDRESS[0] = 255;
  NETMASK_ADDRESS[1] = 255;
  NETMASK_ADDRESS[2] = 255;
  NETMASK_ADDRESS[3] = 0;
  GATEWAY_ADDRESS[0] = 192;
  GATEWAY_ADDRESS[1] = 168;
  GATEWAY_ADDRESS[2] = 1;
  GATEWAY_ADDRESS[3] = 1;

• add printf to serial according to microROS project https://github.com/micro-ROS/freertos_apps/blob/galactic/microros_nucleo_f767zi_extensions/Src/main.c

Expected

../embedded_rtps_test show something/

Actuall

• ../embedded_rtps_test waiting

Creating RTPS Participant...
Creating Participant...
Created Participant succesfully.
Creating RTPS reader on topic:TOLINUX
Creating FastRTPS Writer on topic TOSTM
Successfully created writer.
Waiting for reader match with STM32...

• ping failed
• arp -a show something with 192.168.1.103

? (169.254.169.254) at <incomplete> on enx000ec6cac70c
? (192.168.1.105) at 00:e0:4c:36:0f:51 [ether] on enx000ec6cac70c
? (192.168.1.101) at <incomplete> on enx000ec6cac70c
_gateway (192.168.157.254) at 00:00:5e:00:01:02 [ether] on wlxe84e0663b980
? (192.168.1.103) at <incomplete> on enx000ec6cac70c

disable the wifi makes no different of the result.

• wireshark capturing no packets from 192.168.1.103

• I added the tasklist function to show the thread report below

Hi,

do I understand correctly that you are not able to ping the STM?

If you are unable to ping the STM then something with your network or lwip config on the STM side is wrong. Can run your project without starting embeddedRTPS (comment out https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/blob/f21d3fa74b6034833d81638f1d10a331cae2ad97/stm32/Src/main.cpp#L535) and see if you are able to ping the STM?

@akampmann thanks for your quick reply!

do I understand correctly that you are not able to ping the STM?

Yes, ping 192.168.1.103(stm32) outputs unreachable

If you are unable to ping the STM then something with your network or lwip config on the STM side is wrong. Can run your project without starting embeddedRTPS

Yes, I can ping the stm32 without starting embeddedRTPS, is there something wrong with the prio setting of threads? I've print the task info above.

This behavior happens also in microROS-ertps demo in https://github.com/micro-ROS/micro_ros_stm32cubemx_utils this issue is related https://github.com/micro-ROS/micro_ros_stm32cubemx_utils/issues/46

As for this repo, I've changed some code, but I believe the changing is about

• static ip resetting
• cubemx upgrade
• print2serial and gettaskinfo function.

You can check with this https://github.com/ZhenshengLee/embeddedRTPS-STM32/commit/3b983a3f749dd122cee7de7e9de3be87dd8b2c2f

Thanks.

I will have a look and come back to you. I haven't been running embeddedRTPS on the STM32 code for a while. I've been mainly developing for the Xilinx UltraScale+ Cortex R5.

@ZhenshengLee I've created a new branch that tracks the latest embeddedRTPS, CubeIDE, fw v1.16.2, FastDDS v2.3.2 (probably also works with the latest version):

https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/tree/feature/track_latest

STM32 is now able to talk again to the Linux side, could you give it a try on your side?

I seem to have sporadic issues with pinging the STM, but that occurs regardless of including embeddedRTPS, please let me know if you observe the same behavior.

Hi @akampmann

Great Library! Extremely cool to see the RTPS-DDS running on a Micro-controller

I have been trying to get the example project working (the new branch called /feature/track_latest) and i have had some issues trying to get the example working. I have used the branch as is and set my Unix machine Networking Information to:

Address: 192.168.1.104 Network: 255.255.0.0 Gateway: 192.168.1.104 DNS: 192.168.1.104

I have also been using the latest version of FastDDS

I have connected the STM32F7 directly to my computer and noticed that it was hanging when it was trying to match the publisher and subscriber.

I did some debugging and found that it was failing to join IGMP multicast group (The printf verbose debugging is extremely useful). Inside the STM32F7 in the stm32f7xx_hal_eth.c file i had to change

macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_DISABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_PERFECT;

to macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_ENABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_NONE;

After changing this i was able to successfully join the IGMP group however i now get the error "ParticipantProxyData deserializtaion failed" when the handleSPDPPackage function is called.

I haven't found the cause of the "ParticipantProxyData deserializtaion failed" but am continuing to debug. If you have any comments on potential causes or tests to help narrow the problem down it would be great to hear them!

Cheers

Jay

STM32 is now able to talk again to the Linux side, could you give it a try on your side?

@akampmann Thanks for your quick reply!

I am on my vacation now, I'll give it a test in 10 days.

@jayvanmali thank you for trying out the new branch and providing feedback. I'm curious why the changes to the MAC configuration were not necessary on my side.

Regarding the deserialization failure: Could you please try FastDDS v2.3.2? That is the exact version that I tested on my side. There are probably changes to the SPDP messages in newer FastDDS version which have not been incorporated in embeddedRTPS yet. Such changes were also necessary in the past. I will try to find time to look into this. Meanwhile, could you try 2.3.2 on your side and come back to me?

Hi @akampmann, Thanks for your prompt reply.

Im currently away at the moment, but will test it with the FastDDS v2.3.2 version when i'm back (with in a day or so).

In regards to the MAC configuration changes, Once i get the example working, I will change it back to the same settings are provided in the example and see if it works. This should help understand the MAC configuration change.

Cheers

Jay

Hi @akampmann

So i have installed FastDDS v2.3.4 (I couldn't find the files for v2.3.2) and i still get the error:

[SPDP] ParticipantProxyData deserializtaion failed

Just to be safe, i cloned the files from GitHub (And swapped to the /feature/track_latest branch) and did the following (Determined by trial and error as well as the github read-me):

1. Setup my Unix IP to 192.168.1.104.

2. Deleted the G_Test folder (It was causing compilation issues).

3. Changed the name if the file config_stm to config and updated the IP address to 192.168.1.103 (The STM32 IP set by LwIP).

4. Added the IGMP flag to netif->flags in ethernetif.

5. Changed SPDP_WRITER_PRIO, THREAD_POOL_WRITER_PRIO, THREAD_POOL_READER_PRIO to be 24.

6. Updated Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_eth.c to change:

   macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_DISABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_PERFECT;

   to

   macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_ENABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_NONE;

Here is a copy of the log from terminal: debuglog.txt

If you have any comments on potential causes or tests to help narrow the problem down it would be great to hear them!

I'm still making my way through debugging and will let you know when i manage to get it working!

Cheers

Jay

@jayvanmali

this has most likely to do with the recent changes introduced that avoids adding remote locators that are not on the same subnet as embeddedRTPS. Could you please try to change this line to:

https://github.com/embedded-software-laboratory/embeddedRTPS/blob/68915c8ccc744db171a202182dce2ef55b7728ca/src/discovery/ParticipantProxyData.cpp#L187

to

return true;

The function returns false to indicate that the locator is not added, but that return is incorrectly causes the deserialization to stop. It worked on my side because since the first remote locator transmitted by remote participants was on the local network....

Do you mind confirming that this fixes the issue on your side?

I will then create a fix on the master branch shortly.

@jayvanmali

I've updated https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/tree/feature/track_latest to incorporate the fix. It works for me on the Cortex R5 now. Would you mind giving it a try on your side?

Hi @akampmann

Great! ill give it a test a bit later this afternoon, Thanks for looking into it so quickly!

@ZhenshengLee I've created a new branch that tracks the latest embeddedRTPS, CubeIDE, fw v1.16.2, FastDDS v2.3.2 (probably also works with the latest version):

https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/tree/feature/track_latest

STM32 is now able to talk again to the Linux side, could you give it a try on your side?

@akampmann

The code has been altered to https://github.com/ZhenshengLee/embeddedRTPS-STM32/tree/outdoor/feature/track_latest/ to get a better debug experience.

• Tested with fastdds2.3.4, everything is OK
• linux side receiving well, sending well
• ping stm well
• stm side, doesn't konw if it works well

issue

the serial output behavior(the callback of rtpstest thread) is abnormal

expected

received data from Linux is output per second

actual

a lot of received data from Linux flushes out for once

screenshot

see the timestamps from the ternimal

screenshot

comment

is the serial or the callback work abnoraml?

Great! ill give it a test a bit later this afternoon, Thanks for looking into it so quickly!

EDIT: the test happens in 2022-0509-08:41 of your timezone, after your branch being updated for @jayvanmali 's issue

zs@zs-3630:~$ TZ='Europe/Berlin' date
2022年 05月 09日 星期一 08:41:15 CEST

@ZhenshengLee I've created a new branch that tracks the latest embeddedRTPS, CubeIDE, fw v1.16.2, FastDDS v2.3.2 (probably also works with the latest version):

https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/tree/feature/track_latest

STM32 is now able to talk again to the Linux side, could you give it a try on your side?

@akampmann

issue

oh, hello_world coredump after around 10 minutes

screenshot

screenshot

I seem to have sporadic issues with pinging the STM, but that occurs regardless of including embeddedRTPS, please let me know if you observe the same behavior.

@akampmann

after a 2-hour test of ping, I think there's no issue of the ping function of the stm

here is my board and toolchain info:

• nucleo stm32f767zi
• stm32ide 1.9.0
• gcc: 10.3-2021.10 (builtin of the ide 1.9.0)
• stm32cubemx 6.2
• stm32cubeFW_F7 v1.16.2

screenshot

screenshot

@akampmann

I think your new branch https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/tree/feature/track_latest of work can be merged as the basic function(ping and rtpstest) has been recovered.

So, after the feature branch being merged into master

• this issue be closed
• two new issues be created to track the received data from Linux issue and "hello_world coredump" issue I mentioned above
• @jayvanmali would you agree that the ParticipantProxyData deserializtaion failed issue being tracked standalone?

issue

the serial output behavior(the callback of rtpstest thread) is abnormal

expected

received data from Linux is output per second

actual

a lot of received data from Linux flushes out for once

screenshot

see the timestamps from the ternimal screenshot

comment

is the serial or the callback work abnoraml?

@ZhenshengLee Can you add a newline character at the end of the output? Maybe the output buffer is only cleared and transmitted once full or after occurrence of a new line:

printf("Received data from Linux\n");

---

@jayvanmali would you agree that the ParticipantProxyData deserializtaion failed issue being tracked standalone?

@ZhenshengLee @jayvanmali This should be fixed on the latest master.

---

oh, hello_world coredump after around 10 minutes

@ZhenshengLee Could you please run with gdb and provide the output of backtrace once it runs into the segmentation fault?

Hi @akampmann @ZhenshengLee

I have tried the new commit and the error for ParticipantProxyData deserializtaion failed has disappeared, however i still cant seem to get an output on either side. Wireshark shows that both the Unix machine and the STM32 are sending RTPS packets to 239.255.0.1 so i am not completely sure why i am not getting an output. The debug log however seems to freeze just after the ./hello_world linux application is started so i suspect it may be something to do with the RTOS threads.

Ive attached the RTPS debug log: RTPS_DEBUG.txt

Im also curious to know why i have to adjust the stm32f7xx_eth.c and the ethernetif file to successfully join the IGMP group. @ZhenshengLee did you have this issue when running this example?

@jayvanmali Are you running this by any chance in a virtual machine? Could you provide a wireshark recording of the entire interaction?

Im also curious to know why i have to adjust the stm32f7xx_eth.c and the ethernetif file to successfully join the IGMP group. @ZhenshengLee did you have this issue when running this example?

Nope, during my test, I did not change anything in eth setting of the stm32.

Hi @akampmann

I'm running this on a Linux laptop with a HP USB-C to RJ45 Adaptor as the laptop does not have a Ethernet Port.

I have attached the RTPS Log from the STM32F7 and the Wireshark Recording:

RTPS Log: STM32_Log.txt Wireshark Log: Wireshark_Recording.zip

After it appears to freeze, the pinging does not work anymore, I am doing some debugging to workout where its locking up but i cant immediately see anything failing.

Be happy to try any suggestions you recommend.

Cheers

Jay

Hi @ZhenshengLee

That is interesting, Are you able to confirm if your stm32f7xx_eth has promiscuous mode enabled?

macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_ENABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_NONE;

Can you also check your ethernetif and see if you have the IGMP flag set: NETIF_FLAG_IGMP

if i don't enable these i cant seem to join and IGMP group.

Much Appreciated

Jay

Hi @akampmann

I'm running this on a Linux laptop with a HP USB-C to RJ45 Adaptor as the laptop does not have a Ethernet Port.

I have attached the RTPS Log from the STM32F7 and the Wireshark Recording:

RTPS Log: STM32_Log.txt Wireshark Log: Wireshark_Recording.zip

After it appears to freeze, the pinging does not work anymore, I am doing some debugging to workout where its locking up but i cant immediately see anything failing.

Be happy to try any suggestions you recommend.

Cheers

Jay

@jayvanmali

Something is off with the IP address configuration. The subnet assumed by embeddedRTPS is wrong (it sends messages to 192.168.42.44 (thus it assumes that this locator is on its own subnet)), but IP packets are actually sent from 192.168.1.103.

Can you confirm that the IP addresses here:

https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/blob/6f9e84ac621153f3df0c9bb5fd9a473ae6f02585/stm32/LWIP/App/lwip.c#L69

And here:

https://github.com/embedded-software-laboratory/embeddedRTPS-STM32/blob/6f9e84ac621153f3df0c9bb5fd9a473ae6f02585/stm32/Core/Inc/rtps/config.h#L39

match?

Currently configuring the IP address is a bit messy, as it has to be changed in two places. That is mainly because there does not seem to be a consistent way of configuring the IP address of the lwIP interface on different platforms (its different on the Cortex R5). I will have to add an assert at some point to warn of this misconfiguration during embeddedRTPS init.

This is just an FYI. I've confirmed feature/track_latest branch could work well in my environment as is (just changing the IP address). I have the utmost respect for @akampmann 's work!!

@takasehideki thank you so much!

@jayvanmali did you have a chance to look at the IP config?

Hi @akampmann

Apologies for the delayed response. I have been away for the past week and will back end of this week, Ill confirm the branch then and let you know my findings.

Cheers

Hi @jayvanmali did you have a chance to try the fix?

Hi @akampmann, apologies for the delay, An Illness left me out of action for a while. I'll test it within the next day and report back, I'll attach the trace log and Wireshark log as well

Cheers

Jay

Hi @akampmann

I've started trying the fixed, but have had network issues on the F7 which i have narrowed down to hardware issues, I'll continue testing the fix when i get access to a second F7 (within a day or so).

Cheers

@jayvanmali

That is interesting, Are you able to confirm if your stm32f7xx_eth has promiscuous mode enabled?

macinit.PromiscuousMode = ETH_PROMISCUOUS_MODE_ENABLE; macinit.MulticastFramesFilter = ETH_MULTICASTFRAMESFILTER_NONE;

yes, you can check in https://github.com/ZhenshengLee/ros2_mcu/blob/0cdedf3f9f07599bb58fbd42e61ac5204fdfddd0/libs/custom_stm32f767zi_ertps/Drivers/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_eth.c#L1877-L1878

Can you also check your ethernetif and see if you have the IGMP flag set: NETIF_FLAG_IGMP

yes, you can check in https://github.com/ZhenshengLee/ros2_mcu/blob/0cdedf3f9f07599bb58fbd42e61ac5204fdfddd0/libs/custom_stm32f767zi_ertps/LWIP/Target/ethernetif.c#L241