2023-06-05 10:53 AM
I have integrated Micro-ROS into the m4. I have it working such that I am able to publish sensor data and receive it from other nodes. However Micro-ROS takes up a quite a bit of space, 70+ KB. In their documentation it is target at mid tier micro controllers. I am trying to add the parameter server and that pushes the .text over the 128KB limit. I am wondering if it is possible / advisable to recompile the system image to allow for larger text space for the co processor. I believe their are some changes to make to the device tree memory section among other places. My possible options I see would be:
I saw on some other posts that the m4 shouldn't really be running any protocol stacks since they tend to eat up large amount of memory and that they should be handled by the A7. Any advice / thoughts / information / guidance would be much appreciated.
Thanks
Solved! Go to Solution.
2023-06-06 12:35 AM
Hi @Hammy ,
have you looked to:
The hard limit for Cortex-M4 is 448KB for code+data+vectors (assuming no DMA buffers for Linux nor IPC buffers).
I guess you could tailor your overall system using the above pages.
Regards
2023-06-06 12:35 AM
Hi @Hammy ,
have you looked to:
The hard limit for Cortex-M4 is 448KB for code+data+vectors (assuming no DMA buffers for Linux nor IPC buffers).
I guess you could tailor your overall system using the above pages.
Regards
2023-06-08 11:20 AM
Hi @PatrickF
Thank you for that information 😀 That looks like the solution to my problem. I will try to adjust the sizing to fit my project. If it works and eventually I want to publish my results as a guide / demo project so other people can get Micro ROS running on the STM32MP1 more easily. I think it would be nice to have a FreeRTOS + Micro-ROS + ROS2 stack running on the STM32MP1 for some robotics applications.
I asked the MPU support team as well and this was their reply.
The M4 has to execute form the internal SRAMx memory area. This means that, in theory, 452KB is available to the M4 to be used for code/data space. The default build of OpenSTLinux defines areas of that memory to be used for mailbox in order to support IPCC:
from the board device tree:
mcuram2: mcuram2@10000000 {
compatible = "shared-dma-pool";
reg = <0x10000000 0x40000>;
no-map;
};
vdev0vring0: vdev0vring0@10040000 {
compatible = "shared-dma-pool";
reg = <0x10040000 0x1000>;
no-map;
};
vdev0vring1: vdev0vring1@10041000 {
compatible = "shared-dma-pool";
reg = <0x10041000 0x1000>;
no-map;
};
vdev0buffer: vdev0buffer@10042000 {
compatible = "shared-dma-pool";
reg = <0x10042000 0x4000>;
no-map;
};
mcu_rsc_table: mcu_rsc_table@10048000 {
compatible = "shared-dma-pool";
reg = <0x10048000 0x8000>;
no-map;
};
mcuram: mcuram@30000000 {
compatible = "shared-dma-pool";
reg = <0x30000000 0x40000>;
no-map;
};
retram: retram@38000000 {
compatible = "shared-dma-pool";
reg = <0x38000000 0x10000>;
no-map;
};
The figures/entries above will need to be modified to adjust their sizes which will free up some memory and it really depends on how you would like to implement IPC. If you just want to prove things out first, without interacting with Linux, adjust the .ld (linker file) to give more memory to .text and launch you code using the "engineering mode" debug session -> https://wiki.st.com/stm32mpu/wiki/STM32_MPU_ROM_code_overview#Developer_-28also_known_as_-22engineering-22-29_mode
Regards,
MPU support team