Hello, every developments. I know the .elf file normal process is loading in the flash and running to RAM. Now I want to generate the elf file without flash. It running to RAM by host computer. How can I do? Thanks!
You want to run SITL on a PC? Then compile SITL on the PC and run it. Instructions are on the wiki.
I suspect this is about porting to a board without flash, like some H7’s or the stm32mp1 (which has flash on the a7 core but not the m4 core, and loads m4 firmware to ram via the a7 on boot).
I want it run in stm32mp157 Cortex4. I find can add #define HAL_NO_FLASH_SUPPORT TRUE comment in hwdef.dat file. But the generate .elf head file find that it still have the viraddr in 0x08000000. It should setting the addr begin in RAM addr with 0x30000000. Have any guide?
I want it run in stm32mp157 Cortex4. I find can add #define HAL_NO_FLASH_SUPPORT TRUE comment in hwdef.dat file. But the generate .elf head file find that it still have the viraddr in 0x08000000. It should setting the addr begin in RAM addr with 0x30000000. Have any guide?
Before trying to get ArduPilot running on that mcu you’ll need to add ChibiOS support for it: I believe the m4 core is similar to the stm32L4, which ChibiOS already supports.
I’d treat this as two separate projects:
- ChibiOS support for the m4 core; and then
- Loading ArduPilot to RAM from external flash.
As an alternative to adding ChibiOS support for the mp1, you could port ArduPilot to an rtos that already supports it (Zephyr would be a good option), but that’s a much bigger job.
I comparison the Pin define of the MP1-Cortex4 and F427, they are the same. My first step is to running the .elf file to mp1 without care about the peripheral. But is get error, although I set the “HAL_NO_FLASH_SUPPORT TRUE”, but in the .elf file also have the addr 0x08000000.
afaik HAL_NO_FLASH_SUPPORT isn’t active in the autopilot firmware builds: just IOMCU and perhaps some of the lower end AP_Periph targets.
The flash addr is controlled by the hwdef parser (chibios_hwdef.py or something like that). I think it uses 0x08000000 plus whatever additional pages are necessary based on the mcu type and hwdef. You would have to modify that file to use a lower addr.
I also thing it was hard work. Have any flight control systems more suitable for porting?
BetaFlight/iNav are bare metal so no rtos to port, but you’d still need to do the board support. Basically, there’s no shortcut here: there’s just more work that needs to be done to support the stm32mp1 than I think you want to do.