Welcome to the repository for the MCU programming of the Zimmer Test Bench being developed by a group of students from Polytechnique Montréal.
The board used for this project is the NUCLEO-H723ZG. The following instructions will guide you through the setup process to be able to setup the same type of CubeMX and PlatformIO projects.
The repo includes one main folder containing the CubeMX project configuration file and the PlatformIO setup file.
You will find the source and header files in the Core folder. Please be careful when writing new code as STM specifies certain blocks to write in.
This section presents the required steps to program the NUCLEO-F401RE board and integrate the CubeMX folder in VSCode.
- Open CubeMX and select New Project in the File tab.
-
Select the appropriate board in the list (in our case, it is the NUCLEO-F401RE).
-
Configure the CubeMX project as desired. Under the Project Manager tab, in the Project Location section, select your Git repo folder.
-
Under the same tab as before, in the Toolchain / IDE section, select STM32CUBEIDE.
-
Under the Code Generation tab, select Only copy the necessary library files.
-
You can then generate the code and confirm it has appeared in the right folder.
This section presents the setup for integrating a PlatformIO project in a CubeMX project folder.
After the project creation in CubeMX, add the created project to the Visual Studio Code workspace.
-
Create a new PlatformIO project with the desired board and assign the framework to be stm32cube. This will generate a platformio.ini file which regroups the linkage between the PlatformIO extension and the STM32 developement toolchain.
-
Copy the platformio.ini file in your STM32CubeMX generated project and add the following lines at the end of the file :
board_build.stm32cube.custom_config_header = yes
[platformio]
include_dir = ./Core/Inc
src_dir = ./Core/Src
These lines will direct the PlatformIO to compile files found in the Core folder of the generated CubeMX project.
- To add or modify hardware components, use the Generate Code button in the CubeMX application. To compile and program the written code, simply use the PlatformIO extension as explained in the following section.
This section presents how to build and program on the board the modified code in the Src and Inc folders generated by the stm32pio addon.
-
Open the CubeMX project from the PlatformIO extension as shown below.
-
To build your code, click on the
on the bottom of the VSCode window. To program your board, click on the 
on the bottom of the VSCode window.
If these options do not appear, simply reload the VSCode app. -
The use of STM32CubeIDE is also recommended for debug purposes. The use of VSCode is simply to have a nicer and more customizable IDE! You can still use the debug mode and other useful ressources offered in STM32CubeIDE.
As of the completion/demo of the project in May 2023, some nice features to have that have not been added due to time constraint are listed here:
-
Add of a soft reset button in the GUI. The app sometimes disconnects itself from the microcontroller (or ther other way around). Since the reset button is not accessible very easily when alone (under the test bench), implementing a soft reset command to send to the microcontroller would be suitable for testing purposes. Another workaround is to reprogramm the microcontroller if ever it gets stuck but it is less user-friendly.
-
Have a constant communication between the microcontroller and the GUI. As of now, communication between the app and the microcontroller only happens when manual control or automatic control are enabled. In an idle state or an error state, the microcontroller does not send information even though error states are programmed correctly. Implementing this logic of constant communication to constantly verify the state of the test bench would be preferable to constantly monitor its state.
-
Implement a reconnexion logic. In the GUI, the management of the connected object is not fully completed. A very-nice-to-have would be to implement further functionnalities of the Connect button in order to make sure it is always possible to connect to the microcontroller (maybe send a soft-reset command and then connect to the microcontroller to make sure connexion is established properly).
-
Email when error occurs and error handling in general. A considerable amount of the project was spent on making a functional prototype and not so much on error handling management (sorry!). Reviewing the error handling both in the app and the microcontroler code would be an essential next step for the project. It would also be a nice-to-have to send emails when tests are finished, at an important number of repetitions (kind of like milestones) or when an error occurs.
-
Implement a logging system. As of now, no information on the speed, position, direction or state of the test bench are logged in a text file or any other type of file. In order to be able to retrace bugs or to understand why a test failed at a certain point, logging all useful information somewhere would be ideal. All the setup for serial communication has been done, simply missing the logging part!