Bug report: code generation STM32L475 IOT board

[PADAM.1]

When I want to use the X-CUBE-BLE1.5.0.0 on STM32CubeMX, the file "b_l475e_iot01a1_bus.h/c" is not generated. Thus the project cannot be compiled.

To reproduce:

• create new project on B-L475E-IOT01A board
• option of Targeted Language: C++
• Initialize all peripherals with their default Mode: YES
• Additional Software: STMicroelectronics.X-CUBE_BLE1 (version 5.0.0):
  • Controller: checked,
  • HCI_TL: Basic
  • HCI_INTERFACE: USER_BOARD
  • Utils: Checked
• Wireless BlueNRG-MS: checked
  • Exti Line: SPBTLE_RF_IRQ_EXTI6 [BT module_SPI_IRQ]
  • Bus IO driver: SPI3
  • CS line: SPBTLE_RF_SPI3_CSN [BT module_SPI_CS]
  • Reset line: SPBTLE_RF_RST

See attached file...

[Silvio]

Hi,

thanks for reporting this issue. It will be fixed.

As workaround, I can suggest you to:

• clear the MCU pinouts, before creating a project with BLE in CubeMX for the B-L475E-IOT01A1, and
• set the Application Structure=Basic, before generating the code.

Please, see the attached .ioc file.

BR

Silvio

[blacix]

Hello,

that workaround does not work for me, I also tried the ioc you attached.

[Silvio]

Hello,

what type of error you are facing?

What version of STM32CubeMX are you using?

Did you try to create your project from scratch?

BR

Silvio

[blacix]

Hi Silvio,

I use Cube IDE ( from "About" page):

STM32CubeIDE Version: 1.3.1 Build: 6291_20200406_0752 (UTC)

STM32CubeMX 5.6.1.202004052303 com.st.stm32cube.common.feature.mx

I created the project from scratch as follows:

• new STM32 project
• I select the board: b-l475e-iot01a
• select c++, the rest is the default
• FW package version: STM32Cube FW_L4 1.15.1
• init peropherals with the default
• finish

If i select X-CUBE-BL1 components, for version 5.0.0, it displays errors for Controller and HCI_TL saying, the components have unresolved dependencies, and no solution found. See attached picture.

If I select 4.4.0, it says this version is not compatible with the current version of cube mx. see attached pic.

No other version option is listed.

I configure the pins as in the first post.

When I want to build, I get the follwoing with both configs:

• #warning BLUENRG_CONFIG not valid
• fatal error: b_l475e_iot01a1_bus.h: No such file or director

If I clear the pins as you suggested, it is all the same.

If I use your attached ioc, it is all the same.

I cannot change the app structure at code generation, it is disabled:

compile output:

arm-none-eabi-gcc "../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DDEBUG -DSTM32L475xx -c -I../Middlewares/ST/Middlewares/ST/BlueNRG-MS/includes -I../Middlewares/ST/Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Template -I../BlueNRG-MS/Target -I../Middlewares/ST/BlueNRG-MS/utils -I../Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Basic -I../Middlewares/ST/BlueNRG-MS/includes -I../Drivers/CMSIS/Include -I../Core/Inc -I../Drivers/BSP/CUSTOM -I../Drivers/CMSIS/Device/ST/STM32L4xx/Include -I../Drivers/STM32L4xx_HAL_Driver/Inc -I../Drivers/STM32L4xx_HAL_Driver/Inc/Legacy -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.d" -MT"Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.o"
../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_IFR.c:356:2: warning: #warning BLUENRG_CONFIG not valid [-Wcpp]
 #warning BLUENRG_CONFIG not valid
 ^~~~~~~
In file included from ../Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Basic/hci_tl.h:19:0,
 from ../Middlewares/ST/BlueNRG-MS/includes/hci_const.h:14,
 from ../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_gap_aci.c:18:
../BlueNRG-MS/Target/hci_tl_interface.h:33:10: fatal error: b_l475e_iot01a1_bus.h: No such file or directory
 #include "b_l475e_iot01a1_bus.h"arm-none-eabi-gcc "../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.c" -mcpu=cortex-m4 -std=gnu11 -g3 -DUSE_HAL_DRIVER -DDEBUG -DSTM32L475xx -c -I../Middlewares/ST/Middlewares/ST/BlueNRG-MS/includes -I../Middlewares/ST/Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Template -I../BlueNRG-MS/Target -I../Middlewares/ST/BlueNRG-MS/utils -I../Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Basic -I../Middlewares/ST/BlueNRG-MS/includes -I../Drivers/CMSIS/Include -I../Core/Inc -I../Drivers/BSP/CUSTOM -I../Drivers/CMSIS/Device/ST/STM32L4xx/Include -I../Drivers/STM32L4xx_HAL_Driver/Inc -I../Drivers/STM32L4xx_HAL_Driver/Inc/Legacy -O0 -ffunction-sections -fdata-sections -Wall -fstack-usage -MMD -MP -MF"Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.d" -MT"Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.o" --specs=nano.specs -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb -o "Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_updater_aci.o"
../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_IFR.c:356:2: warning: #warning BLUENRG_CONFIG not valid [-Wcpp]
 #warning BLUENRG_CONFIG not valid
 ^~~~~~~
In file included from ../Middlewares/ST/BlueNRG-MS/hci/hci_tl_patterns/Basic/hci_tl.h:19:0,
 from ../Middlewares/ST/BlueNRG-MS/includes/hci_const.h:14,
 from ../Middlewares/ST/BlueNRG-MS/hci/controller/bluenrg_gap_aci.c:18:
../BlueNRG-MS/Target/hci_tl_interface.h:33:10: fatal error: b_l475e_iot01a1_bus.h: No such file or directory
 #include "b_l475e_iot01a1_bus.h"

 As far as I can recall, it worked well with x-cube-ble1 4.2.x

[Silvio]

Hi blacix,

you could directly use the latest STM32CubeMX v5.6.1 to configure the B-L475E-IOT01A1 and generate a project for the STM32CubeIDE.

BR

Silvio

[blacix]

OK, thanks, I'll give it a shot.

[Silvio]

Hi,

you can for sure continue using STM32CubeIDE for your projects.

Clearly, the issue you faced will be fixed.

Thanks!

BR

Silvio

[blacix]

If I use the standalone mx ( which is the same version as the one in IDE though ) It works, well, almost...

The generated b_l475e_iot01a1_bus.c cannot be compiled, because it cannot find the configured pins, which are defined in main.h

Inlcuding main.h in that file solves the issue, but it is still very annoying, since a generated file needs to be modified after any change made to the mx project.

I guess, that's the reason for your suggestion of clearing the pins.

I hope this is going to be resolved soon because I will have to work a lot with this board...

Thanks for your help, and thanks in advance!

[PADAM.1]

Hi Silvio, blacix,

the problem of the not found "configured pins, which are defined in main.h" seems to be the same problem (or similar) as the one I reported in "BUG report on code generation STM32L476":

• If I rename the pins of the SPI (eg.: "BLE_SPI_MISO"), the project does not compile anymore, since the pin name is defined in main.h, but hci_tl_interface.c (and may be others?) do not include it.

May be this idea can help to find the solution...