bldc
bldc copied to clipboard
vedderb
Make VESC Protable to "any" Chibios supported MCU
Hi Guys,
i have here a hardware equipped with the STM32F446RE, which i thought could be nearly compatible with the used F405/7 but thats was not the case...
So i updated Chibios from version 3 to the latest release v20. See https://github.com/UNIMOC-Universal-Motor-Control/vesc-software/tree/chibios_portability for reference.
I now need to set the memory layout in the linker file. VESC original Linker File uses the following Flash layout.
flash : org = 0x08000000, len = 16k flash2 : org = 0x0800C000, len = 393216 - 16 /* NEW_APP_MAX_SIZE - CRC_INFO */ crcinfo : org = 0x0805FFF0, len = 8 /* CRC info */
Could some one explain the sections to me. For what are the first 16k used? Bootloader? Why does the flash2 not utillize all of the remaining flash? Is this because of the configuration storage? What else is is important to know about the flash layout?
Regards
Tec
IIRC the first 16k is used for user settings. In the code there is an "eeprom emulator" that lets you read and write the memory like if it were an eeprom, hiding the fact that you're working on a flash memory that can't erase a particular byte, it can only erase complete pages. The first few pages are small so that's why you use them for eeprom emulation.
From address 16k to about half the size the memory is where the current firmware is stored.
From about half the memory to the N-1 flash page, is where you store a new firmware update.
The last page of the flash stores the bootloader. When invoked, the bootloader checks that the new firmware stored in the second half of the flash is okay, and then proceeds to copy that image to the first half of the flash memory and reboots to complete the firmware upgrade.
is it still this one? https://github.com/vedderb/bldc-bootloader then it deserves the same treatment.
Yes, its that one. You don't really need a working bootloader to run a vesc firmware. If you flash the application firmware without bootloader with an STlink or via USB DFU, the controller will run without problems. You will only notice the lack of bootloader when you attempt a firmware from the GUI. I'm telling you this in case you want to leave the bootloader migration effort for later.
I will definetly not use the bootloader yet. The Port is runable now but i have several hardfaults which i need to find at first. When this is running i will do the same for VESC6 HW and try if i get this running again.
What about the ADC_SAMPLE_MAX_LEN? to fit the Vesc code in the RAM of the F446 i need to reduce it to 1500. Does anyone know if this affects vesc tool or some algorithms in the code? From my point of view it should not make any issues.
There would be no issues AFAIK, by default the GUI is setup for 1000 samples, and since in the firmware ADC_SAMPLE_MAX_LEN is set at 2000, you can change this in the GUI to display up to 2000 samples. In your case would be limited to 1500 at mc_interface_sample_print_data(), no big deal
Firmware runs on F446 but when I try to connect with vesc tool 2.06 I get the error that it can not read the firmware version. In the firmware I can see that it triggers the right command in the comm and sends back I packet with firmware version 5.02.
Any ideas appreciated.
Thanks
Tec
no clue what could be going on, but as a random thought... you may want to stick to a GCC version that we are sure works for vesc. AFAIK all the testing is done in gcc v7, and there were some hard to chase issues with particular versions of gcc v8. https://github.com/vedderb/bldc/issues/84#issuecomment-490600780
I will trace the traffic on the serial and have a look what's transferred.
I needed to update the usb handling as well. the usb config for chibios was missing several stuff which was added in the meantime. Now it Works!!!
Now i need to configure the hardware properly. I will keep u updated.
Very good, but for portability to F7, H7 and other you also need to change drivers. From ST SPL that are not available for new families to ST LL (low level drivers, part of CubeMX). https://www.st.com/en/embedded-software/stm32-standard-peripheral-libraries.html And/or use more ChibiOS drivers to be able to use other than STM32 chips.
I know. But when i do all that stuff at once the pull request will be to huge to handle. My goal now is to have my hardware running and get all the other hardwares to build so that others can test this. At this point i would open a pull request.
Next Step would then be to get rid off the SPL and only use CHibios HAL. From what i know now of the code this is perfectly possible because all used SPL drivers are available from Chibios aswell. But for all of this u need to change the hw configurations layout. But this i would do in seperate pull requests to keep changes small and testable. But this hole OS update an achitechure change needed to be one
Has any one looked at my branch? https://github.com/UNIMOC-Universal-Motor-Control/vesc-software/tree/chibios_portability What do u think about using one folder for each hardware with seperate makefile, chibios config files and board files?
I like the seperation of hardware config files and seperate makefiles. i use similar constructions for cross platform projects
do you plan a "master" makefile to do thinks like "make hw60" ?
Hi.
First of. Great work on this, All of this. You people rock! EV future here we come!
Will this port work for the Teensy 4.0? How will a go about making it work. Any pointers would be greatly appreciated.
ChibiOs is running on T4: https://github.com/greiman/ChRt
I got the answer I was looking for. No need for T4, STM32 works just fine 👍
https://github.com/greiman/ChRt/issues/12
Hi,
basically it can work BUT there would be a lot of work needed to rework all the ST standard peripherial library references in the code. I stopped that effort because the support for STM32F446 is fine for me.
Thanks a LOT for doing this, I am about to start porting the code over to run on the STM32H743, Its an M7 running at 480MHz. If I only need to rework the use of the peripheral libraries then that will save me a lot of time :D
Hi Tech, yes the old st lib is the only dependency which prevents that. Please keep me updated.
Just been trying to get this setup in an IDE, looks like you used STM32CubeIDE? Do you have a project file for it? (Not sure what folder I should be pointing it at to get it working properly) I see the make files for each hw so I guess you added each hw folder as a project?
Sorry for a million questions, I am used to Keil so eclipse is a bit jarring!
The ide should not matter. I used stmcubeide with the project files in the top level folder of the project. Then I used build configurations with change the base folder for make to the current hardware configuration folder. To build eclipse just called make -j all in that folder.
I can supply u withe the project files next week.
No worries, got it all working now and can debug on my nucleo board. Will keep you updated on my progress.
ArduPilot would love to interface with this project.
Vesc already supports uavcan if ardupilot does.
This issue is more about running the motor controller code on mcu's other than the stm32f405/7
F446 works for others more work is needed. All the references to spl should exchanged with chbios Hal drivers.
ArduPilot would love to interface with this project.
Vesc already supports uavcan if ardupilot does.
We want to run VESC as a library inside the autopilot
Could anyone update me on the status of this issue. I might be interrested to continue the port to a new chibios version.
