[BUG] ping failed and rtps test failed.

[ZhenshengLee]

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: ZhenshengLee@3b983a3

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

[akampmann]

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

embeddedRTPS-STM32/stm32/Src/main.cpp

Line 535 in f21d3fa

startRTPStest();

) and see if you are able to ping the STM?

[ZhenshengLee]

@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 micro-ROS/micro_ros_stm32cubemx_utils#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 ZhenshengLee@3b983a3

Thanks.

[akampmann]

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.

[akampmann]

@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.

[jayvanmali]

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

[ZhenshengLee]

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.

[akampmann]

@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?

[jayvanmali]

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

[jayvanmali]

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

[akampmann]

@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.

[akampmann]

@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?

[jayvanmali]

Hi @akampmann

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

[ZhenshengLee]

@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]

@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