Issue with rclc_support_init() on STM32H743ZI using FreeRTOS 10.3.1

[danielallstar]

Hello,

I'm encountering a similar issue as described in tickets #116 and #107 while working with an STM32H743ZI2. Specifically, the problem lies with the rclc_support_init() function, which does not appear to be functioning correctly. I've configured the settings in line with those mentioned in ticket #116.

The issue manifests as follows: after calling the rclc_support_init() function, the MCU exits the Task function but fails to return. When halting the debugger at various points, I've observed that the FreeRTOS functions vTaskSwitchContext() and vPortExitCritical() are being invoked.

It's worth noting that on another STM32 MCU using an older version of FreeRTOS (10.2.1), there were no issues. However, the STM32H743ZI2 MCU comes with FreeRTOS 10.3.1 as the default from MXCube. Since I managed to get micro-ROS working on a similar MCU I am quite certain I followed the right steps. I however suspect something changed in versions or there is some hardware incompatibility. It is mentioned that micro-ROS is compatible with the STM32H743ZI, so I am curious which versions/setup is used to make this work.

This problem appears to be a recurring issue that has been reported multiple times. The most recent suggested solution (#116) involves modifying the allocator functions, but this solution lacks clarity and hasn't resolved the problem for me. I have attempted to use custom functionsi instead of the microros_xx functions by using the standard C malloc, free, realloc and calloc without improvement. Also the FreeRTOS pvPortMalloc and vPortFree functions were attempted, but does not solve the problem.

When running the micro-ROS agent no sign of connection can be seen and no session is established, as is the case with my other MCU. The USB is connected since /dev/ttyACM0 is detected.

It's also worth noting that ticket #107 does not contain any suggestions on how to address this problem.

I would greatly appreciate any assistance or suggestions that could help me address this issue conclusively. Thank you in advance for your help.

[Hao-Lion-ZJU]

hello ， I'm having the same problem as you. It seems that the connect with agent is not well established yet. You can try a few more times on rclc_support_init(). That's what I did.

//broke unitl success
   do{
        ret =  rclc_support_init(&support, 0, NULL, &allocator);
        osDelay(1000);
    } while (ret != RCL_RET_OK);

[nikitax75]

Hello there @danielallstar encountering the exact same problem with the exact same MCU. Wondering if you fixed it.

Thanks

[danielallstar]

Hey, I did not solve that problem. You could try the solution of @Hao-Lion-ZJU, but I did not try that myself.

[nikitax75]

Thanks! Yeah, did try it, does not work and cannot work because the default task never resumes once it has entered rclc_support_init, which makes any retry strategy useless.

Also, tried using default allocators as suggested in #110 but it does not fix the problem. Seems that micro-ros support for the stm32h743 is essentially broken. I wished we didn't design a custom PCB thinking it would work...

[nikitax75]

~Wondering if the maintainer @pablogs9 can help. I'd love to help but not sure in which direction to go there. I'd also be really happy to pay for a bug bounty or some support if it can unlock the issue for everyone~ Found the issue upon activating FreeRTOS support in PlatformIO's debugger and debugging the task. Code examples call LOCK_TCPIP_CORE before initiating micro ROS which is wrong as micro ros locks the core itself: Result was mutex deadlock. Removing LOCK_TCPIP_CORE fixed the problem. I am having another issue with micro-ros-agent now, will see if I can debug it

[pablogs9]

Hello @nikitax75 could you open a PR for fixing the issue you mentioned?