Skip to main content
XPonc.1
XPonc.1
Associate II
October 1, 2020
Question

Having trouble with Bluetooth

  • October 1, 2020
  • 8 replies
  • 4264 views

Hey everyone,

I'm having trouble on my STM32WB55RG custom board.

Using version 1.7 of the Cube FW package, my board worked properly. But one day, my device was not discoverable in Bluetooth (I suspected that I deleted it whith my custom bootloader, but I verified the code and don't see how that's possible :\ ).

I looked into the copro binaries and everything seems fine...

I tried programming the examples that I had, but it does not work: my phone does not find the STM32WB.

I might have some old WB samples, as I had a problem with flash that was only related to the first samples (see here: https://community.st.com/s/question/0D50X0000AvfFNKSQ2/why-error-flashsr-is-set-and-block-erasing-flash-memory )

I have 3 other cards from the same batch where the memory section where the FUS is supposed to be is readable. Those 3 cards have a very suspicious behavior that I suspect being related to it... They are currently being transported to me

With all of that I am a bit concerned that my board is simply not usable

If you have any idea, I'd be glad to hear it...

Thanks for your help!

Xavier

This topic has been closed for replies.

8 replies

XPonc.1
XPonc.1Author
Associate II
October 1, 2020

I have a bit more insight on this:

The device does not advertise because it does not go into "APP_BLE_Init" which contains the advertising function.

Why doen't it go into that function? Because it does not go into "APPE_SysUserEvtRx".

Why doesn't it go into that function? Good question, everything seems set...

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 5, 2020

Could you download all the option bytes?

The RF stack not responding is my best hypothesis.

XPonc.1
XPonc.1Author
Associate II
October 6, 2020

Hey Remi,

I have dug a bit and the situation changed.

I have a custom bootloader at adress 0x08000000. My main app is downloaded at 0x0800A000. I redifine the vector table when I jump to the main app section.

When I download the main app at adress 0x08000000, Bluetooth works fine. When I download main app at 0x0800A000 and bootloader at 0x0800A000, the Bluetooth doesn't work, but all the other features from main app do.

Any idea?

Thanks,

Xavier

EDIT: typo

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 8, 2020

How did you define the vector table location? I suspect the vector table is not located at the right place.

You should modify the System_init function in the system_stm32wbxx.c file to set the SCB->VTOR to 0x0800A000. This is the location where the bootloader should jump at the end of its execution.

Then linker file is the file to adapt before any compilation. The Flash memory segment should be located at 0x0800A000 So that all code and data sections are placed correctly.

For example, with CubeIDE, in the file STM32WB55RGVX_FLASH.ld you have to specify the memory space in the following way.

/* Specify the memory areas */

MEMORY

{

FLASH (rx) : ORIGIN = 0x0800A000, LENGTH = 472k

RAM1 (xrw) : ORIGIN = 0x20000004, LENGTH = 191k

RAM_SHARED (xrw) : ORIGIN = 0x20030000, LENGTH = 10K

}

XPonc.1
XPonc.1Author
Associate II
October 8, 2020

Hey Remi,

That's exactly what I did, SCB->VTOR is defined at 0x0800A000 in system_stm32wbxx.c, and navigated through Keil linker options to make it placed at the right address.

My bootloader was developped for STM32F3, I then adapted it on STM32L4 and STM32F4 without any trouble. Even here, on STM32WB, the bootloader works, I can update my app without any problem, but the Bluetooth stack does not works.

Thanks,

Xavier

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 8, 2020

​Ok so back to the RF stack not active.

Could you show me the option bytes SFSA and SBRV to check their consistency?

XPonc.1
XPonc.1Author
Associate II
October 8, 2020

Hey Remi,

SFSA = 0xCB (reminder: STM32WB55RG, with full stack)

SBRV = 0x32C00

Those are consistent.

Just a reminder of what's really odd: when I compile the program at the address 0x0800A000 with bootloader at 0x0800000, Bluetooth stack doesn't work. If I don't have the bootloader (ie program at 0x08000000), the Bluetooth stack does work. I used a workaround, my bootloader is now at the end of flash memory, and app jumps to it, but it's not really what I want...

Option bytes remains the same when I program app at 0x08000000

Thanks a lot for your help!

Xavier

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 9, 2020

One point to clarify: do you launch the CPU2 during the bootloader?

Note that CPU2 can boot only once. If you launched the CPU2 too early in the bootloader phase , CPU1 will never receive the ready event.

The best is to launch CPU2 just before the bootloader jumps to CPU1 code.

is there any reason why you would want to launch CPU2 from the bootloader?

A reinit function also exists.

XPonc.1
XPonc.1Author
Associate II
October 9, 2020

Hey Remi,

That looks like it's the problem, as I don't receive the ready event in main app.

However I don't think I start CPU2 in bootloader (or do I?). I generated code with cubeMX for both bootloader and app, and I didn't include all the RF libraries in the bootloader.

How can I check if CPU2 is started in bootloader?

What is this reinit function?

Thanks a lot!

Xavier

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 9, 2020

​See in shci.h file

SHCI_C2_Reinit

 * @brief This is required to allow the CPU1 to fake a set C2BOOT when it has already been set.

 *       In order to fake a C2BOOT, the CPU1 shall :

 *       - Send SHCI_C2_Reinit()

 *       - call SEV instruction

 *       WARNING:

 *       This function is intended to be used by the SBSFU

 *

 * @param None

 * @retval Status

 */

 SHCI_CmdStatus_t SHCI_C2_Reinit( void );

There are also other interesting functions to interact with CPU2. But they should not be called from M4 application SW.

I am not use to creating a bootloader with CubeMX. So I dont know if it includes a launch of the CPU2.

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 9, 2020

On a usual configuration (bootloader at 0x00000000), the application running on the M4 core calls the appe_Tl_init() function to intitialize the system chanel to comunicate with the M0+ core and then it starts CPU2.

XPonc.1
XPonc.1Author
Associate II
October 9, 2020

Hey Remi,

I just went to try your solution,but I quickly met a big problem:

I cannot implement

SHCI_C2_Reinit();

 __SEV();

in my bootloader, since I don't have the file shci.c in my project. I don't have the appe_Tl_init function or its contents either.

So I tried to implement it at the start of my main app, with no success.

How can I know if CPU2 started in bootloader, is there any register that can indicates that to me?

Do you have any other idea about what could be my problem?

Thanks,

Xavier

Remi QUINTIN
Remi QUINTIN
Technical Moderator
October 12, 2020

shci.c file is under STM32Cube_FW_WB_V1.9.0\Middlewares\ST\STM32_WPAN\interface\patterns\ble_thread\shci.

Now if you concern is to include additional files that can draw other additional files, you can implement the same sequence somewhere at the beginning of the application. It should work. It is just a matter of waiting for the ready event ahead of the M0+ core completing its initialization phase.

A related question: why do you want to build your own bootloader?

XPonc.1
XPonc.1Author
Associate II
October 12, 2020

Yes, what I meant in my previous message was that I don't wan to include a lot of files in my project, I'd like it to be the most simple possible.

I tried to implement it at the very start of my application at 0x0800A000, but I had no success. How can I wait for the ready event of the M0+? How long should it take?

I use my custom bootloader because I use SD card for update: I plug my SD card with my new software on it, and if my bootloader detects a newer version on my SD card, it updates the application. If no newer version is detected, it jumps into tha app.

Terms & ConditionsAccessibility statement