I am trying to switch the MCU in NUCLEO-F767ZI board from LQFP144 package to LQFP176. By following this link, I largely got the new custom board to work, but I am having a bit trouble on where to store the newly generated board files.
According the linked page, we should be able to store the configuration files for custom board outside mbed-os folder by adding the modifying the default CMakeLists.txt. The problem is I don’t see such file in project’s root folder. If I just create a CMakeLists.txt file with the following two lines:
add_subdirectory(TARGET_CUSTOM) # This is the new line to add
add_subdirectory(${MBED_PATH}) # This line already exists
I get the following error during compilation:
[ERROR] In file included from .\mbed-os\cmsis\device\rtos\source\mbed_rtx_handlers.c:23:
In file included from ./mbed-os/platform/include/platform\mbed_interface.h:23:
In file included from ./mbed-os/targets/TARGET_STM\device.h:38:
A second question is where to store other modified files. The custom board will use different pin for RMII_TXD1 (PG14 instead of PB13 in NUCLEO_F767ZI). I can get this to work if I store a modified stm32f7_eth_init.c file inside mbed-os folder:
There might be some other files that we need to slightly modify. So my question is, how do we manage these modfied files? Storing them inside mbed-os folder doesn’t seem like a good idea.
I am not sure about Mbed OS, but this is possible to do with Mbed CE. We have a custom target example showing how to make custom targets (though it does need to be updated a bit regarding memory banks). Regarding changing the Ethernet pins, that can be done by copying this file into your own project, editing it to fit your needs, then attaching it to the custom target for your board.
Basically a custom_target.json file as instructed by official documentation, plus a folder with descriptions for customized target with CMakeList.txt. Presumably Mbed Studio will include automatically include all files and folders under root directory when building.
The only problem so far is, even with the following content in custom-targets\CMakeList.txt:
If I switch back to a built-in target such as NUCLEO-F767ZI, I will get the following errors when building:
[Error] @0,0: L6200E: Symbol HAL_ETH_MspInit multiply defined (by BUILD/NUCLEO_F767ZI/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_STM/TARGET_STM32F7/TARGET_NUCLEO_F767ZI/stm32f7_eth_init.o and BUILD/NUCLEO_F767ZI/ARMC6/custom-targets/CUSTOM_F767BI/stm32f7_eth_init.o).
[Error] @0,0: L6200E: Symbol SetSysClock multiply defined (by BUILD/NUCLEO_F767ZI/ARMC6/mbed-os/targets/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/TARGET_NUCLEO_F767ZI/system_clock.o and BUILD/NUCLEO_F767ZI/ARMC6/custom-targets/CUSTOM_F767BI/system_clock.o).
[Error] @0,0: L6200E: Symbol SetSysClock_PLL_HSE multiply defined (by BUILD/NUCLEO_F767ZI/ARMC6/mbed-os/targets/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/TARGET_NUCLEO_F767ZI/system_clock.o and BUILD/NUCLEO_F767ZI/ARMC6/custom-targets/CUSTOM_F767BI/system_clock.o).
[Error] @0,0: L6200E: Symbol HAL_ETH_MspDeInit multiply defined (by BUILD/NUCLEO_F767ZI/ARMC6/mbed-os/connectivity/drivers/emac/TARGET_STM/TARGET_STM32F7/TARGET_NUCLEO_F767ZI/stm32f7_eth_init.o and BUILD/NUCLEO_F767ZI/ARMC6/custom-targets/CUSTOM_F767BI/stm32f7_eth_init.o).
[Error] @0,0: L6200E: Symbol SetSysClock_PLL_HSI multiply defined (by BUILD/NUCLEO_F767ZI/ARMC6/mbed-os/targets/TARGET_STM/TARGET_STM32F7/TARGET_STM32F767xI/TARGE
Supposedly, the if condition that checks target label should exclude the CUSTOM_F767BI subfolder, but somehow that is not honored.
Can someone know CMake advise what I am missing here?
This is because Mbed Studio doesn’t use CMake, and it seems like it never will at this point sadly. It’s just including those files unconditionally because they’re part of your project.
Thanks for pointing this out. I saw CMakeLists.txt in every folder under mbed-os, so assumed Mbed Studio uses CMake. With only another 1.5 years before Mbed officially shuts down, I doubt anything will be done to Mbed Studio at all. I guess it is time to get Other tool chain to work then.
There is no reason for doubts. The MbedStudio is without development for 3-4 years. All last development was done for KeilStudioCloud and MbedCLI2.
And the Cmake implementation in Mbed OS was working but only with Mbed CLI 2.
And the CMake in Mbed-OS is not really smart, there were several discussions about using static rather than interface libs. Jamie’s improvements in CE are really great, I can also recommend to try it.
Do you know of any tutorials that can get mbed-cli v2 to work? I spent a few hours on it, so far unfortunately cannot get it to work on either Windows 11 or Ubuntu or WSL. There seem to be endless errors here or there.
I guess for now I am stuck with the abandoned Mbed Studio, at least it works out of box.
I just found mbed-tools can actually compile projects created by itself on my setup. They just don’t work with the existing projects created by Mbed Studio, probably because of all the missing CMakeLists.txt files.