cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WB5MMG: Cube Monitor RF refuses to connect

vishalkeshavamurthy
Associate III

We are using an STM32WB5MMG in a product, We needed to run a few BLE tests for compliance needs and came across the BLE transparent mode to help with BLE tests. 

In accordance with the ReadMe under BLE_TransparentMode inside STM32WB5MM-DK, we have undertaken the following steps 

  • Updated FUS to stm32wb5x_FUS_fw.bin at 0x080EE000
  • Updated soft device with stm32wb5x_BLE_Stack_full_extended_fw.bin to 0x080C7000
  • Modified BLE transparent Mode to change USART pins being used to PA9 and PA10 though Cube MX

vishalkeshavamurthy_1-1753783537554.png

Updated FUS and Stack 

vishalkeshavamurthy_2-1753783634962.png

Updated VCP_TX and VCP_RX

 

The CubeMonitor-RF software refuses to connect with the device however 

 

vishalkeshavamurthy_0-1753783507320.png

Unable to connect 

No changes are done to the transparent mode example with the exception of UART pin update. ioc file PDF attached 

 

 

10 REPLIES 10
FilipKremen
ST Employee

Hello,

could you please share the modified project, so I could try to reproduce it on my side?

Thank you.

 

Best regards,

ST support

Hello @FilipKremen 

Appreciate the offer to help thanks! 

I am using the project as is from the latest (V1.23.0) release of Cube Repo [[LINK]]

Specifically I am building the STM32WB5MM-DK/Applications/BLE/BLE_TransparentMode project with 1 modification, changing of default USART pins to PA9 and PA10 to fit my custom board. Original GIT link here [[LINK]]. Also attached is the ICO file where the pin change is done for regenerating the project 

I have already attached a screenshot of the CubeProgrammer window in the thread above, showing my FUS and BLE stack updated correctly. 

Please note that I had to update both the FUS and stack as instructed, the other example projects also did not seem to be advertising as expected, I ran out of time today to investigate further 

 

Also, can the FUS not be downgraded once upgraded? I was unable to downgrade and retest the board with our known functioning FW

 

vishalkeshavamurthy
Associate III

Hi Adding to this thread, 

 

The same modified application works fine with Older FUS (V1.2) and stm32wb5x_BLE_Stack_full_fw.bin

vishalkeshavamurthy_0-1753852192091.png

 

vishalkeshavamurthy_1-1753852210491.png

 

However this does not appear to enable Connecting capabilities under ACI Utilities, perhaps due to the full extended stack not being used. 

The UART modified binary for transparent mode is also attached 

 

FilipKremen
ST Employee

Hello,

transparent mode application requires stm32wb5x_BLE_Stack_full_extended_fw.bin.

You can find more information about FUS on our Wiki page.

STM32WB Firmware Upgrade Service - stm32mcu

I tested the example project with same stack version, and it worked fine. However, I also got a message that the device is not responding. I connected the board to STM32CubeProgrammer and clicked on "Start wireless stack" and then I downloaded the application again and it works fine. Can you please try it again with the steps I mentioned? Thank you.

I'm also attaching my modified project (USART - PA9/10).

Best regards,

Filip Kremen

 

 

vishalkeshavamurthy
Associate III

Hi @FilipKremen 

Thank you for the links, I am aware of the stack requirements and had setup the device with the appropriate Stack 

I also updated the Cube Programmer to the latest version 

Like stated initially 

  • Updated FUS to stm32wb5x_FUS_fw.bin at 0x080EE000
  • Updated soft device with stm32wb5x_BLE_Stack_full_extended_fw.bin to 0x080C7000
  • Used the binaries shared by you 

The code unfortunately is still not connecting in spite of starting the Wireless stack like suggested 

vishalkeshavamurthy_0-1753877181525.png

 

When I started the Wireless stack manually I also noticed in the cube programmer logs the wireless stack failing to start, could this be the cause?

vishalkeshavamurthy_1-1753877814593.png

Like stated before all the examples work fine with older V1.2 FUS and corresponding V1.17.1.1 wireless stack 

I am inclined to believe that the way I have setup the FUS / Wireless stack could have some issue since other examples such as Heartbeat also do not appear to be working. 

Would it be possible to please verify on your end if your FUS and Wireless stack match mine? I have zipped the FUS, Wireless stack and the App Binary(Same as the one you shared) for you to confirm, logs from Cube Programmer added 

 

 

FilipKremen
ST Employee

I'm using the same versions. After downloading the application, please try to reset the board.

I had to reset my board before connecting to STM32CubeMonitorRF.

Also, can you please try to download the project directly from STM32CubeIDE?

Thank you.

Best regards,

Filip Kremen

vishalkeshavamurthy
Associate III

Hi, 

I tried downloading the example project directly without any modifications though CubeIDE and discovered that the device is entering a hard fault 

 

vishalkeshavamurthy_0-1753883325430.png

vishalkeshavamurthy_1-1753883522942.png

 

Like I still suspected, there could be something wrong with my FUS/Soft-Device Binaries

 

 

vishalkeshavamurthy
Associate III

@FilipKremen , I made another observation that I figured was worth sharing 

 

I updated the CubeProgrammer to the latest version , took a fresh set of boards, updated the FUS and stack along with your application Binary. 

The example worked as expected on both boards, and connected with cubeMonitorRF software once. 

But both boards have since stopped working since a power cycle. Even starting the Wireless stack manually, or resetting the boards manually is not helping

I am assuming that I might be entering hard fault again, would it be possible that I have some option byte set different from the default that is causing the soft device to crash? 

FilipKremen
ST Employee

Hello,

did you manage to solve the issue?

Could you please try to download the stack again? Or try it again with older version?

Also, if you could share the option bytes, thank you.

 

Best regards,

Filip Kremen