X-NUCLEO-IDB05A1 with STM32F4-DISCOVERY

[Mario Simunic]

Posted on January 08, 2018 at 14:35

Hi,

I'm trying to port (use) X-NUCLEO-IDB05A1 board with STM32F4-DISCOVERY.

I've begun developing this project by modifying SensorDemo for Nucleo-L053R8 board.

I'm using Keil-MDK v5.25 (Lite). STM32F4 project is build by generating 'base' with CubeMX (Clock, pinout, SPI, I2C. UART). Then, using Keil, BSP is added (stm32f4_discovery.c for BSP_ functions). Build was ok.

Then, Middleware is added and modifications are made to some .h files in order to use dicovery board, in project options it's defined USE_STM32F4_DISCO and modification to cube_hal.h to use STM32F4xx.hal instead of stm32l0xx_hal.

I've succeeded to build modified project, but application hangs waiting for response from SPBTLE-RF.

I think something is not working as supposed to regarding SPI and/or interrupts.

I'm new to embedded development and ST discovery/nucleo tools, so probably I'm missing some details.

Whole thing of porting SensorDemo for STM32L0 to STM32F4 is not so simple and clear and whole thing about HAL / cube / cube_HAL / BSP and all sorts of redefinitions in the originating project is foggy and unclear to me.

After calling BlueNRG_SPI_Init() instead of MX_SPI_Init() - generated by the CubeMX, I have hard time to find simple functions to make SPI loopback and test if SPI is working correctly.

Is there anybody who is tried to make X-NUCLEO-IDB05A1 (SPBTLE-RF) work with STM32F4-Discovery?

#stm32f4 #ble #idb05a1 #spbtle-rf #x-nucleo-idb05a1 #stm32f407 #stm32f4-discovery #stm32f407vg

[Tesla DeLorean]

Posted on January 08, 2018 at 19:47

>>

Is there anybody who is tried to make X-NUCLEO-IDB05A1 (SPBTLE-RF) work with STM32F4-Discovery?

Doubt it, seems the most tortuous path. I suspect most would start with a board that has an Arduino shield connector like the NUCLEO-64 or 144 platform STM32F4 parts, or the STM32F469-DISCO or STM32F412-DISCO type boards. I've done that for the LRWAN tree. I'd use an F4 NUCLEO as a waypoint when pivoting to the family from an L0 or F0 tree. Porting HAL code has a rather high critical mass, ie a lot of things you've got to change and get right for it to build and function properly.

Make sure you have interrupt handlers in stm32f4xx_it.c that call into the HAL abstraction properly. Check the vector table to confirm IRQ Handler names for a specific part.

Check clocks, pins and AF (Alternate Function) mux selections.

[Bogdan Golab]

Posted on January 08, 2018 at 21:19

The topic is about integration of CubeMX and BSP drivers. I did it for many DISCO boards and described it:

https://community.st.com/0D50X00009bMM7ESAW

 

Look also into other posts.

It's more or less the process as follows:

-I reverse engineer the BSP example delivered by ST but created manually - TO DISCOVER what resources are used (e.g. I2C)

-I run CubeMX to enable those resources (e.g. I2C, etc)

-copy BSP files to the project folder

-add include search paths to your project (subfolders in BSP folder)

-add *.C files from Drivers folders (subfolder of the BSP folder) to satisfy linker

-then work with the API (you can just cheat from the original BSP examples)

It takes some time but as you can see in many project I published it is feasible for more complex stuff like LTDC, FMC, etc.

[Bogdan Golab]

Posted on January 08, 2018 at 21:21

And also it might be interesting:

https://community.st.com/0D50X00009XkYoaSAF

[Mario Simunic]

Posted on January 08, 2018 at 22:11

Hi Golab,

Thank you for the suggestions, they are helpful.

I've basically made most of the modification you suggested. Now goes the ugly part. If I make a change to the project using CubeMX and generate new code, only part of code will stay preserved (user code between comments). Other part of changes is need to be made again, ie. manually added files to project, include paths, project defines.

As I have several faculty projects in same time, this one will be put on hold.

I just want to comment on CubeMX.

At the time when I was choosing this project with BLE and STM32F4-Discovery I didn't have X-NUCLEO-IDB05A1 nor the experience, so I looked for documentation online. One can find this 'advertising' of X-NUCLEO-BLE1 as BLE software extension for STMCube. Later on I discovered that there is no way to integrate X-CUBE-BLE1 into CubeMX.

So, basically, one can't generate project with BLE using CubeMX for *any* device.

May be someone from ST can look into the problem of regenerating the project code and (at least for Keil-MDK project) preserving manually added project files, defines and paths (Project options - C/C++).

[Bogdan Golab]

Posted on January 10, 2018 at 07:48

Problem of not supporting BSP packages was brought up several times on this forum. Those who are interested (as me) after spending days got used to;). Believe me, the HAL stuff is not simple but we have no choice if we decide to play with STM32. I switched to LL now just for fun to learn low level details but it's not easier. Everytime (regardless what drivers you use) it's better to understand what is going on under the hood.

[Mario Simunic]

Posted on January 10, 2018 at 15:00

Golab.Bogdan wrote:

... Everytime (regardless what drivers you use) it's better to understand what is going on under the hood.

Generally, I couldn't agree more. Just in my case this approach requires total shift of focus, but HAL and drivers are out of scope of this project.

I had a choice. I made my decision based on information spread on ST's web site. It's my wrong judgement, but nothing is lost, I'm learning.Thank you for the help.

[tTAGN]

Hi everybody

someone can give me an example of code for SPBTLE-RF connected via SPI to a discovery for example STM32F407 ??? or one in the same family?

Thanks in advance for helping