P-NUCLEO-WB55 bricked on heart rate demo

MLang.7 · ‎2021-01-31

Hello,

today I just ran the heart rate demo and suddenly the board seems to be bricked. The onboard debugger is running, but the CubeIDE is unable to start a GDB server. Using the ST-LINK utility I wasn't able to establish any connection to chip. So is it bricked?

Remi QUINTIN · ‎2021-02-16

Are you able to connect to the board via the Cubeprogrammer tool? If yes what are the option bytes?

MLang.7 · ‎2021-02-16

No, it says ST-LINK error (DEV_CONNECT_ERR). Meanwhile I bought 2 more boards. First of all I tryed to connect to them via the ST-Utility which failed, but as suggested CubeProgrammer is able to cennect. Then I tried the HearRate demo on the first of the 2 new boards. It ran for maybe 1 or 2 seconds until the debug session crashed. On the third board I tried the p2p server demo which doesn't kill the board. I ordered a WB55 chip as well for replacement. In retrospect I guess I should have ordered more.

Remi QUINTIN · ‎2021-02-17

Before going any further, can you show me the option bytes on your board?

Then can you use the application binary (.hex file) in the binary directory. you should be able to connect to your board with the ST BLE Sensor application on your mobile. This would check whether your board is broken or not. I am not expecting the chip to be broken by your experiment.

When running the application in debug mode with CubeIDE, did you try to connect to the device with your mobile?

Did you activate some traces with those settings in app_conf.h?:

#define CFG_DEBUG_BLE_TRACE 1

#define CFG_DEBUG_APP_TRACE 1

Did you manage to set a breakpoint somewhere in the code?

Are you able to relaunch the heart rate application?

MLang.7 · ‎2021-02-17

"He's dead Jim": As I mentioned before, none of the debug/programming tools is able to establish a connection to the target, hence I can't show you the option bytes of the dead specimens. What I can provide to you is the option bytes of the remaining specimen.

As I mentioned before, this demo was the first program I ever used on the two boards. It hit the first breakpoint at the beginning of the main.c and then crashed after just 2 seconds. There was no time for any connection attempt.

Meanwhile I tried to revive the boards by flashing the coprocessor, as described in the STM32CubeWB Getting started manual. But again, no signs of live.

I don't know what happend to these 2 boards, I hope not all are nucloes are afected by it

Remi QUINTIN · ‎2021-02-17

Regarding the second board you managed to connect with the CubeProgrammer tool via USB port (or was it via SWD port?), did you set set a jumper in between pin 5 and 7 of connector CN7. This is mandatory to start from the bootloader and connect in USB mode with the CubeProgrammer tool.

On the third board programmed with the p2pserver application, are you able to see that board with the name P2PSRV1 using the ST BLE Sensor application on your mobile.

For the first one, I have no idea why it looks bricked after using CubeIDE in debug mode. Same thing => can try to connect with the cubeProgrammer tool either in USB mode or in SWD mode. I have joined to this post a document clarifying those points.

MLang.7 · ‎2021-02-18

I was able to reset all tweo boards an they are running now. p2p server demo runs and I can see the boards with my smartphone.

Still, they are crashing when running the heart rate demo.

Remi QUINTIN · ‎2021-02-18

If you load the BLE_HeartRate_reference.hex file located in the binary directory at address 0x08000000, are you able to connect to the board with your mobile and see the heart beat?

If you can see it, then the issue is with CubeIDE.

Are you able to catch the point where it crashes? can you get the value of the program counter (PC) and the stack pointer (SP)?

Remi QUINTIN · ‎2021-02-18

Crash => hard fault or infinite loop? Is the CPU alive or is it dead?

MLang.7 · ‎2021-02-19

Running the .hex file the board immediately crashes after reset. The CPU seems to be dead, no connection via Debuggers possible.

Ok, here lies the problem. In app_debug.c in APPD_init GPIOA is configured as analog pins. Unfortunately these pins

are used as SWD pins for debbung hence the system crashes. The CFG_DEBUGGER_SUPPORTED flag is set in app_conf.h but somehow ignored.

I just commented the else clause and the prgramming was ruinning - at least once the board showed up on my smartphone

#if(CFG_DEBUGGER_SUPPORTED == 1)
  /**
   * Keep debugger enabled while in any low power mode
   */
  HAL_DBGMCU_EnableDBGSleepMode();
  HAL_DBGMCU_EnableDBGStopMode();
 
  /***************** ENABLE DEBUGGER *************************************/
  LL_EXTI_EnableIT_32_63(LL_EXTI_LINE_48);
 
#else
  
  GPIO_InitTypeDef gpio_config = {0};
 
  gpio_config.Pull = GPIO_NOPULL;
  gpio_config.Mode = GPIO_MODE_ANALOG;
 
  gpio_config.Pin = GPIO_PIN_15 | GPIO_PIN_14 | GPIO_PIN_13;
  __HAL_RCC_GPIOA_CLK_ENABLE();
  HAL_GPIO_Init(GPIOA, &gpio_config);
  __HAL_RCC_GPIOA_CLK_DISABLE();
 
  gpio_config.Pin = GPIO_PIN_4 | GPIO_PIN_3;
  __HAL_RCC_GPIOB_CLK_ENABLE();
  HAL_GPIO_Init(GPIOB, &gpio_config);
  __HAL_RCC_GPIOB_CLK_DISABLE();
 
  HAL_DBGMCU_DisableDBGSleepMode();
  HAL_DBGMCU_DisableDBGStopMode();
  HAL_DBGMCU_DisableDBGStandbyMode();
 
#endif /* (CFG_DEBUGGER_SUPPORTED == 1) */