DISCO TEMPLE

This is a workspace for developing with the STM32F746G-DISCO evaluation kit, providing a Makefile-based project supporting the HAL and CMSIS layers, plus per-peripheral BSP configuration.

The source layout is similar to a STM32CubeIDE project generated from a STM32CubeMX configuration, even the build pathes are the same. The .project, .settings/*, and .cproject files are there thus you can open it in STM32CubeIDE, thanks to "File/Open Projects from File System..."

It's done to document how to set-up a project from scratch, because there is no STM32CubeMx nor STM32CubeIDE examples to start with. And starting a project with STM32CubeMx is a frustrating experience for new comers: empty project won't toggle LED1 as intended, you have to understand the HAL/CMSIS/BSP sandwich, comparing projects is difficult...

---

Layout

• Middlewares: for Third_Party/lvgl only (TODO).
• templates: pristine project templates.
• template.env: you must update it with your STM32CubeIDE workspace, the FW source repo...
• create-project.sh: creates a new project in the STM32CubeIDE workspace from a template.
• create-patch.sh: creates a patch set between a template and a project.

---

Needs

1. Install an ARM toolchain. I'm using Canonical's (they provide builds for Linux, OS X and Windows).
2. Install a GDB server: stlink, OpenOCD, others ?
3. Install STM32F7 Cube Package, update template.env with the path of the installed sources, probably ~/STM32Cube/Repository/STM32Cube_FW_F7_Vx.y.z.

Steps 1 and 2 are not necessary in case you want to use STM32CubeIDE only.

Build with arm-none-eabi-9-2020-q2-update and STM32CubeIDE 1.6.0 9614_20210223_1703(UTC). Under UBUNTU 18.04 and 20.04, Windows 10.

TODO: not all combination tested yet, WSL.

---

Building a test project

1. Check template.env for revelant configuration
2. Create a template based project with create-project.sh script
3. Build with make or STM32CubeIDE

For now, only one template, with or without FreeRTOS.

create_patch.sh generates patches to recreate your project from a brand new one.

ACHTUNG ! It temporary moves the project, and call "make erase" in it !

DO NOT BLINDLY APPLY THEM ON A TEMPLATE ! You still have to handle the project name where it appears, or if a file name contains the project name, you have to change the patch accordingly.

---

Debug

A GDB server that connects to the ST-Link, one of the following:

• ST-LINK GDB server, only for ST-Link, distributed with STM32CubeIDE.
• it's open source clone, available from ubuntu 20.04 repo.
• OpenOCD, source code there, version from ubuntu 20.04 repo should support ST-Link and STM32F7xx (SWV ?).

Revelant configuration for ST-LINK GDB server can be found in this file, alongside a script. A real installation is still needed, at least for flashing process wich call XYZ (hardcoded).

A GDB client connects to the server through a TCP connection, all tested solution are based on arm-none-eabi-gdb. The command to load and start the debug session can be found in this file.

In addition to the TUI mode, two GUIs are evaluated: STM32CubeIDE and Nemiver.

TODO: hard to use SWO outside STM32CubeIDE, trying Eclipse Standalone Debugger and gdbgui

---

Simple project discovery

We will try to write and modify code in the Core directory ONLY.

• the startup code, should not change that much, just maybe the vector table to update with the IRQ handler name you've changed. These are declared as weak symbols.
• the HAL configuration header where you enable/disable BSP modules, set the clocks speeds with HSE/HSI and LSE/LSI. Other revelant configurations are:
  • TICK_INT_PRIORITY.
  • USE_RTOS.
  • USE_HAL_XYZ_REGISTER_CALLBACKS.
  • USE_FULL_ASSERT and the assert_param macro definition.
  • MAC/PHY address and other ETH relative config.
• the HAL initialization code (what MSP and PPP stand for ?)
• the IRQ handlers
• the system initialization code, called just before main, to setup the memory (external RAM, FLASH...), relocate interrupt vector table, setting clocks
• the application entry point, the error handler, and asset_failed definition

LD1 -> SB8 -> ARD_D13 -> PI1 SW1 -> SB6 -> B_USER -> PI11

LVGL

The LVGL portage need display and input drivers.

1. tft.c is the for the display, it declares the display buffer static lv_disp_buf_t disp_buf_1;, which is initialized right after. The rendering function is static void ex_disp_flush(lv_disp_drv_t*, const lv_area_t*, lv_color_t*), it is registered as a callback by disp_drv.flush_cb = ex_disp_flush;
2. touchpad.c for the capacitive touchscreed input. It only contains a function to read the input, there bool touchpad_read(lv_indev_drv_t*, lv_indev_data_t*), registered as callback with indev_drv.read_cb = touchpad_read;

Then, to run the GUI, two functions must be periodically called:

1. lv_tick_inc to increment the LVGL internal tick counter in ms. Must be called with the nb of ms ellapsed since its last call.
2. lv_task_handler to grab pending inputs if any, and updates the GUI.

TODO: LV_LVGL_H_INCLUDE_SIMPLE

---

TODOs

• Keep CubeMX comments and layout in main.c, stm32f7xx_hal_msp.c and others
• printf plugged to SWO
• debug configurations for other servers, without SWO, GUI, detailing SWO, copy necessary dbg ressources into new project.
• Handling 3rd part libraries: FreeRTOS and LVGL with git submodules
• Makefile documentation.
• harmonizing STM32CubeIDE and make compile flags.
• How to automate Cube repo installation.
• STM32CubeMx config.

---

Credits

Released by JFA for ENGENEO under License Apache V2

Originates from this jaz303 repo.

Probably some inspirations from this mofosyne repo too.