Having trouble with Bluetooth

[XPonc.1]

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

[XPonc.1]

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]

Could you download all the option bytes?

The RF stack not responding is my best hypothesis.

[XPonc.1]

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]

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]

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]

​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]

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]

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]

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