Hi,
I am having issues debugging my STEVAL-IDB008V2 board using the ST-LINK/v2 debugger through Keil v5. When I try to load the program in Keil, I get the error message: ''No target connected'' or the error message ''Error while accessing a target ressource. Ressource perhaps not available or a wrong access was attempted''.
I am able to connect to the board using the BlueNRG-1 ST-LINK Utility.
What I tried so far:
-Erase the chip before loading the program -Loading the program when the board runs the bootlader (DI07 set HIGH, DL2 ON) -Loading the program when the board runs the flash application (DI07 set LOW, DL2 OFF) -Loading the program when the board is in DFU USB (RESETIN set LOW, DL2 flashes) -Loading the program with different debug settings (Normal, with Pre-reset, under Reset) and clock settings -Updating the FW of the ST-LINK/V2
My current settings for the Debug tab:
Debug Adapter: ST-LINK/V2 Serial Number: 50FF71067871515218580667 Version HW: v2 Version FW: V2J32S7
Target Com: Port SW Clock Req: 1.8MHz Clock Selected: 1.8Mhz
Debug: Connect & Reset Options: Connect: Normal Reset: Autodetect Reset after Connect (checked)
Cache Options: Cache Code(checked) Cache Memory(checked)
Download Options: Verify Code Download (unchecked) Download to Flash (unchecked)
SW Device: ID CODE: 0x0BB11477 Device Name: ARM CoreSight SW-DP
Furthermore, as you can see from the debug settings, the ST-LINK/V2 is recognized in Keil and Keil identifies the BlueNRG-2 as 0x0BB11477 (IDCODE)/ ARM CoreSight SW-DP (Device Name).
Any help would be much appreciated.
Cheers, Xavier
The first step is always to try with the ST-Link Utility.
If the ST-Link Utility can't connect, then you know you have a fundamental issue - nothing to do with Keil.
If the ST-Link Utility can connect, then it's time to investigate Keil & its settings ...
Make sure the code you are running doesn't go into a low power mode or otherwise turn off the processor.
Why wouldn't you download and verify?
The ST-LINK Utilities has a rudimentary debugger, does that work?
Hi Andrew,
Thanks for the reply. I am indeed able to connect to the ST-LINK/V2 using the BlueNRG-1 ST-LINK Utility, which is a special kind of ST-Link Utility designed for the BLUENRG chips. So it seems my problem is with the Keil software.
As you can see, I posted the details of my settings when trying to debbug. Do you see anything wrong with these settings?
Thanks, Xavier
Hi there,
Thank you for answering.
I am currently testing on the example project "ADC_Polling" from the BlueNRG1_Periph_Examples found in the BlueNRG-1_2 DK which from my understanding does not go into Low Power Mode (no reference is made to any BlueNRG_Sleep commands in the code).
I checked the download and verify options, and I still was not able to load or debug in Keil.
As for the ST-LINK debugging, if you are referring to the "Core Panel", I am indeed able to read the core registers and to step into the program.
Any more help would be greatly appreciated.
Hi Xavier,
I have the same problem as you described with Keil and BlueNRG-2 board. I will be very grateful if you can share the issue with me in the case you funded it !
Regards, Victor
Hi Victor,
I managed to flash and debug the board using the TrueStudio IDE instead of Keil. Furthermore, you should try to debug your issue using a BlueNRG1_Periph_Examples such as ADC Polling. Other examples such as BLE_SensorDemo use the JTAG pins to communicate with the LSM6DS3 and make the debugging process impossible.
Hope that helps, Xavier
Dear Xavier,
Thank you for shared information, this will definitely save a lot of time!
I too have this exact problem with the same devkit and ST-LINK/v2 debugger. I was under the assumption the BLUENRG-2 was supported by uVision.
I just wanted to also note that the ST-Link Utility works fine, program/erase & debug. The problem lies with uVision.
I can also confirm everything works out of the box with TrueSTUDIO.
That doesn't line up with:
"Other examples such as BLE_SensorDemo use the JTAG pins to communicate with the LSM6DS3 and make the debugging process impossible"
If the JTAG (sic?) lines are being corrupted by the hardware, then no debugger is going to be able to get around that, surely?!