cancel
Showing results for 
Search instead for 
Did you mean: 

How to configure STM32 F401RE, F767ZI boards for Bluetooth X-NUCLEO-IDB04A1

NKNAv
Associate II

Good evening everyone,

I'm a newbie to the STM32 (well, actually to this level of programming micro-controllers), but I'm trying to do my best (it's for my master thesis).

Nevertheless I have to ask you for a little bit of help, if you don't mind.

I've got two boards, a F401RE-64 and a F767ZI-144. For now what I have to do is to implement a bluetooth communication with the expansion board X-NUCLEO-IDB04A1, so I'm trying to understand how it works.

As toolchain I have TrueSTUDIO with the CubeMX plug-in (for the blinking led demo works fine), but when I try to compile and run the SensorDemo of X-Cube-BLE1 start the problems.

I follow the pdf in the X-Cube-BLE1's Documentation folder for the CubeMX configuration.

After that I import the project in TrueSTUDIO and build it.

Two warnings appear:

#warning BLUENRG_CONFIG not valid [-Wcpp] bluenrg_IFR.c

Invalid project path: Missing project folder or file: \F767_Bluetooth_Test\Packs for Source path

For the first one I undestood that I have to add a macro in the pre-processor, but where exactly? I've tried under C/C++ Build -> Settings -> Tool Settings -> Assembler -> Symbols and C/C++ General -> Preprocessors Include Paths, Macros etc. -> Entries -> CDT User Setting Entries and seems to work, but I would like to know which is the truly dedicated location for the input of this kind of macros.

For the second problem, well I don't really know what to do. The Packs folder indicated is the one created by CubeMX when adding the BLE packages. But it resides in another path, while here seems that must be in the project's folder. I even tried to include its path, but doesn't work. I overcome the problem in a tricky why, by copying the folder Packs in the project, but gives only inclusion errors (i.e.: fatal error: host_config.h: No such file or directory blood_pressure_collector.c /F401_Bluetooth_Test/Packs/STMicroelectronics/X-CUBE-BLE1/4.2.0/Middlewares/ST/BlueNRG-MS/profiles/Central/Src/blood_pressure_collector); I suppose because they're too deep in the paths?

Said so, if I try to debug with the two warnings the run returns something like this:

Temporary breakpoint 2, main () at ..\Src\main.c:120

120  MX_GPIO_Init();

but from the app BlueNRG sometimes seems reachable (connecting gives error btw).

I tried with the .bin file of SensorDemo for the F401RE and everything works fine.

Sorry for the wall of text, but I think it's better to explain in details the problem. And thanks to whoever could reply and help me!

3 REPLIES 3
alok
Senior

Hello,

Please try to run the existing projects from the X-CUBE package for the boards supported. The X-CUBE-BLE1 support NUCLEO-F401RE  as the default example and available toolchain. So, please use System Workbench for STM32 which is also GCC based tool chain. Later you can port the project to TrueSTUDIO and compare the project settings

You can then check the difference in the IOs, SPI connection between NUCLEO-F401RE and NUCLEO- F767ZI-144. You need to make corresponding changes in the STM32F767ZI project

Hope you also noted that X-NUCLEO-IDB04A1 is NRND

In addition, since your request is not for BLE-Mesh in particular, you may miss-out some good feedbacks here vs if you had put your request in "Interface and Connectivity ICs" forum

NKNAv
Associate II

Thanks for the reply.

I'll try to do what you suggest, and perhaps repost this in the right section, if I may.

I know it's NRND, but it's the one available in the university.

NKNAv
Associate II

Okay, seems that I have an update.

I tried as you suggested with System Workbench, but when debugging gives the following log:

Open On-Chip Debugger 0.10.0-dev-00015-gaaf1808 (2018-11-13-13:07)

Licensed under GNU GPL v2

For bug reports, read

http://openocd.org/doc/doxygen/bugs.html

srst_only separate srst_nogate srst_open_drain connect_assert_srst

Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD

adapter_nsrst_delay: 100

adapter speed: 1800 kHz

Info : clock speed 1800 kHz

Info : STLINK v2.1 JTAG v32 API v2 M22 VID 0x0483 PID 0x374B

Info : using stlink api v2

Info : Target voltage: 3.273594

Info : Stlink adapter speed set to 1800 kHz

Info : STM32F401RETx.cpu: hardware has 6 breakpoints, 4 watchpoints

Info : accepting 'gdb' connection on tcp/3333

Info : Stlink adapter speed set to 1800 kHz

adapter speed: 1800 kHz

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x080004d4 msp: 0x20018000

configuring PLL

Info : Stlink adapter speed set to 4000 kHz

adapter speed: 4000 kHz

Info : device id = 0x10016433

Info : flash size = 512kbytes

Info : Stlink adapter speed set to 1800 kHz

adapter speed: 1800 kHz

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x080004d4 msp: 0x20018000

configuring PLL

Info : Stlink adapter speed set to 4000 kHz

adapter speed: 4000 kHz

target halted due to breakpoint, current mode: Thread 

xPSR: 0x61000000 pc: 0x20000046 msp: 0x20018000

Info : Stlink adapter speed set to 1800 kHz

adapter speed: 1800 kHz

target halted due to debug-request, current mode: Thread 

xPSR: 0x01000000 pc: 0x080004d4 msp: 0x20018000

shutdown command invoked

Info : dropped 'gdb' connection

I've seen that I could change the clock speed in the .cfg debug file, bu still gives the same kind of error (without 4000 kHz part).