Loading...
 

Zephyr project on STM32

   Zephyr Workbench, a VSCode extension to manage Zephyr on STM32.
It enables users to easily create, develop, and debug Zephyr applications.
Main features:
  • Install host dependencies.
  • Import toolchain and SDK.
  • Create, configure, build and manage apps.
  • Debug STM32.
You can directly download it from the VSCode marketplace
For more details, visit the Zephyr Workbench

System Workbench for STM32


Relevant header included but fails with "unknown type"

I am porting a wifi example from STM32Cube_FW_L4_V1.11.0 into my own project. The STM example and my project are both using the B-L475E-IOT discovery kit which has an onboard wifi module accessed via SPI. I generated my project skeleton code for SW4 using STM32CubeMX by selecting the relevant board and enabling relavent SPI HAL so that all is included in the project folder.

The code fails to compile complaining that the type SPI_HandleTypeDef is not defined in the es_wifi_io.h file that I copied to my project.

The es_wifi_io.h file includes stm32l4xx_hal.h, which in turn includes the project specific stm32l4xx_hal_conf.h, which defines HAL_SPI_MODULE_ENABLED and in turn includes stm32l4xx_hal_spi.h which is where SPI_HandleTypeDef is defined. All these appear correctly in the project, and the SW4 project C/C++ Build settings list all relevant include paths for these files.

The STM32Cube example works fine, but my project complains about this missing type. Is there something I am missing in the project settings that could be causing this?

Regards
Mikael

I resolved this issue not long after posting.

The issue was inclusion order though I don’t understand why.

wifi.h ported from the example in my project appears to need to be included in main.c, and not main.h even though main.h is included in main.c. This is not consistent with the example but at least it works..

France

Hi Mikael,

I think the problem is not related to include order but to where exactly is the wifi.h file and how it is included. I suspect wifi.h to be in the same directory as main.c, while main.h is in another directory. If you do the include using quotes, then the compiler search first alongsides the file that do the include, so including from main.c may work while from main.h it may fail.

Note also that projects generated from CubeMX tend to include linked files, that appear at one place in the project explorer but are ine fact somewhere else on the disk... This may cause the same kind of problems.

To check for this you should look at your project directory from the Windows file explorer to check where exactly are located the files (you may also check a specific file by right-clicking it in the project explorer then “Properties...”, if it’s a linked file it will be shown in the first tab).

Hope this helps clarifying things,

Bernard (Ac6)


 

Newest Forum Posts

  1. Можно ли установить камин на балконе или лоджии? by Grand3kpdErorb, 03:38
  2. reservation car service Seattle by Jamesprede, 2025-05-01 10:06
  3. Last day: drone bonus by Danielrug, 2025-04-19 16:55
  4. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-25 07:37
  5. SPI on Nucleo_STMH533RE by royjamil, 2025-03-23 11:31
  6. SPI on Nucleo_STMH533RE by higginsa1, 2025-03-23 09:33
  7. Configuring DMA for ADC in SW? by sam.hodgson, 2025-03-04 12:58
  8. Insightful Perspectives on This Subject by davidsycle, 2025-03-04 05:45
  9. Build a project in "release" mode by info@creosrl.it, 2025-02-20 18:12
  10. Build a project in "release" mode by info@creosrl.it, 2025-02-20 17:05

Last-Modified Blogs