This help request has two parts:
1. New Board files genererally, and
2. Porting problem to STMH747XI-DISCOVERY.
I am working with ChibiStudio and ChibiOS 21.11.0, from the distribution ZIP. No updates from the SVN.
I have tried to learn how to create new board configurations. It would be nice if board configuration could be clarified a bit.
This is board name specific example, but could be helpful for those trying to create their own boards? What I have learned (and done) :
- You need to create the board files. board.h and board.c. I have done this with board.chcfg and using the Generate File from Configuration Data was successful. board.mk also, and with correct directory references.
- You need to have compilation startup-files, for example: */os/common/startup/ARMCMx/compiles/GCC/mk/startup_stm32h7xx.mk. Fortunately this already exists in the ChibiOS project!
- You need to have chip support files ("HAL-OSAL"), for eg */os/hal/ports/STM32/ST32H7xx/*, stm32h7xx.h and chip specific stm32h747xx.h. These also exists, which is a blessing!
EDIT: These of course all come through hal/ports/[MF]/[board]/platform.mk descrition. - You need to have linker script for the chip: STM32H747xI.ld or STM32H747xI_M7.ld. This I have copied and modified, checking the memory areas from the RM. It also seems to match others, like H755xI. There are some variations memory block organsations, I have tested some from different *.ld-files, but those do not seem to be critical if you have the sizes ok.
- You of course need to have the project configuration files: chconf.h. halconf.h and mcucon.f. These I have created, and copied the clock tree from some STM32CubeMX settings - they seem to compile and "access" the board.
- And you of course have to have the Makefile to attend to all of the above.
- Extra: for me it looks like the CORE_CM7 (or CM4) has to be defined somewhere. At this stage I am happy to work with one core.
- In STM32H7 support thread Giovanni said also something about registry, which I believe is stm32_registry.h, and it does have the H7 support from the ChibiOS project, with H747. Possibly there are other files at this level as well? If required, I expect they exists, since the H7 support is as far as it is.
- And for OpenOCD you would need to have: <OpenOCD>/board/stm32h7-MYTEST, which only refers to target/stm32h7x_fual_bank.cfg and target/stm32h7x.cfg. Which do not seem to be very board specific.
Is this outlook somewhat correct? The Chip-files are of course critical, and don't think I would have been able to copy and modify them myself.
2. The specific effort with STMH747XI_DISCOVERY
I endend up having a new H747-DISC board. It probably was not very successful choice: over-equipped and less clear than some F7 or H7 NUCLEO. Anyway I am currently bound with the DISCOVERY board. My board files do not critically need most of the peripherals, so I am happy just to get the MCU working for now.
I am definitely not an MCU expert, but learning. I have ported some examples to F4 board previously, changing the mcuconf and makefiles and some pins etc. I have been successful. But I am not able to use the H747 board, even for the most basic blinker-demo.
I can compile the imported and ported demo project, and I can flash it to the board. I can run it with OpenOCD. It starts, but has an initialization assert immediately:
__early_init() --> stm32_gpio_init() --> rccResetAHB4() --> chSysHalt due to "peripherals not allocated".
Code: Select all
#if STM32_TARGET_CORE == 1
osalDbgAssert((RCC_C1->AHB4ENR & mask) == mask, "peripherals not allocated");
(It doesn't matter if I change the core.)
The debug breakpoint (yes, with -O0) does not show the RCC values, so I cannot see what is currently in there. The RCC and RCC_C# is in stm37h747xx.h, and is F3 reachable from ChibiStudio, so I expect it to exists in the compilation. The mask is 0x7FF, which is 11 bits, which would match the GPIOA through GPIOK. chconf.h does have HAL_USE_PAL. At least the very pins I want to use (just blinker LEDs at this point) are indeed defined as per the HW.
Any tips that I could try proceeding with? Where should the peripheral be allocated? I though there is little to configure with the PAL/GPIO? The stm32_registry.h does have the STM32_HAS_GPIO? defined through chip support definitions (STM32H747xx defined in board.h).
Later I will use some of the other peripherals, DAC, Serial and UARTs, but for now even getting the most basic blinker-demo would be a step forward.
The utmost simple blinker (with one blinker thread, one sleep, one LED, no input, no test-functions) based on the H755 demo still faults in the rccResetAHB4() osalDbgAssert. But if I turn the ENABLE_ASSERTS off, the code still runs.
The backtrace is the same when breakpointed into the stm32_rcc.h:925. To prove myself that it is not some flash memory haunting (due to earlier custom LD script versions), I made some trivial additions to the stm32_rcc code, and it was reached and breakpointed.