2019-06-03 03:58 PM
I have tried debugging some of the BLE example projects for the Nucleo-WB55, specifically the BLE_HeartRateFreeRTOS and BLE_TransparentMode examples. During debug, the erase, program, and verify steps all complete successfully, but then shortly after, I start seeing "Target is not responding, retrying..." message and finally an error message about not being able to read the target. When I try to reprogram the device either through the debugger or STM32CubeProgrammer it fails saying "No device found on target."
What is going wrong? How do I recover the board?
The only way I've been able to recover is to copy a .bin I compiled from the Zephyr project for the WB55 to the ST_LINK drive and let it program that way.
The CM0 is running the stm32wb5x_BLE_Stack_fw.bin.
Solved! Go to Solution.
2019-06-05 01:50 PM
For anyone else that runs into this problem, I fixed it by changing some #define values in app_conf.h. Change "CFG_DEBUGGER_SUPPORTED", "CFG_DEBUG_BLE_TRACE", and "CFG_DEBUG_APP_TRACE" from 0 to 1, recompile, and load the firmware.
If you need to get your nucleo target responding again, copy the .bin file to the ST_LINK drive. The .bin is a zephyr rtos "hello world" binary that prints to the COM port, only for the NUCLEO-WB55.
2019-06-03 04:07 PM
Watch for things like allowing the code to go into sleep or low power modes, these power off the debug interface, and the debugger can't talk to it any more. Same thing if you reconfigure the debug pins.
Strap BOOT(0) pin HIGH, and reset so it executes the load in ROM rather than whatever you've put in FLASH.
2019-06-04 09:08 AM
Thanks for the reply and suggestions. I'm not sure that this is the issue though. I'm using the examples provided by ST and have not modified the Nucleo board at all. Shouldn't these work without any issues?
I am able to run some of the examples without any problems, like the BLE_Beacon example for one, but other examples put my board in a bad state.
Any other ideas?
2019-06-05 01:50 PM
For anyone else that runs into this problem, I fixed it by changing some #define values in app_conf.h. Change "CFG_DEBUGGER_SUPPORTED", "CFG_DEBUG_BLE_TRACE", and "CFG_DEBUG_APP_TRACE" from 0 to 1, recompile, and load the firmware.
If you need to get your nucleo target responding again, copy the .bin file to the ST_LINK drive. The .bin is a zephyr rtos "hello world" binary that prints to the COM port, only for the NUCLEO-WB55.
2019-06-06 04:30 AM
Hello,
All examples have been delivered with the debugger enabled ( CFG_DEBUGGER_SUPPORTED set to 1 in app_conf.h) except the HeartRate example which is the only one configured by default to provide the best power consumption.
If you need to get back the debugger, you need to set back CFG_DEBUGGER_SUPPORTED to 1 in app_conf.h. Obviously in that case, the consumption will be higher than the best you could achieve.
Regards.
2019-06-06 08:37 AM
Thanks @Christophe Arnal that's helpful!
I have a related question though. Is there a reason that I'm unable to reprogram if the CFG_DEBUGGER_SUPPORTED flag is set to 0, or a way to fix this? I have tried with STM32CubeProgrammer and the debugger. It just tells me "No device found on target".