You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When auto-generating code from .ioc configurations using STM32CubeIDE (1.9.0) the order in which peripherals are created is not fixed. We observed that rosserial_stm32 only works if the DMA is initialized BEFORE the UART connection
MX_DMA_Init();
MX_USART2_UART_Init();
If you have this the other way round, you get connection errors using rosrun rosserial_server serial_node _port:=/dev/ttyACM0 _baud:=115200.
[ INFO] [1655841703.653152322]: Opened /dev/ttyACM0
[ INFO] [1655841705.653483835]: Opened /dev/ttyACM0
[ INFO] [1655841707.653914306]: Opened /dev/ttyACM0
[ INFO] [1655841709.654372123]: Opened /dev/ttyACM0
We don't know how to force the initialization order or how to handle this in rosserial_stm32. But this problem may be related to #33, #22 and other connection problems.
The text was updated successfully, but these errors were encountered:
When auto-generating code from
.ioc
configurations using STM32CubeIDE (1.9.0) the order in which peripherals are created is not fixed. We observed that rosserial_stm32 only works if the DMA is initialized BEFORE the UART connectionIf you have this the other way round, you get connection errors using
rosrun rosserial_server serial_node _port:=/dev/ttyACM0 _baud:=115200
.We don't know how to force the initialization order or how to handle this in rosserial_stm32. But this problem may be related to #33, #22 and other connection problems.
The text was updated successfully, but these errors were encountered: