BlueNRG-2 | Unable to debug over STLINK/V2 | Multiple Issue

[ANSHUMAN TRIPATHI]

Posted on June 28, 2018 at 13:48

Hi All,

Please help I'm stuck with this, I am currently having some difficulties while programming and debugging the BlueNRG-2 ''STEVAL-IDB008V2'' over STLink/v2.

PROBLEM FACED : When trying to debug and flash the code using TrueStudio getting following error message

Failure at line:13 in 'Target Software Startup Scripts'. Please edit the debug configuration settings. Error writing data to flash

Details:

Board : STEVAL-IDB008V2

BlueNRG2 Part Number :[/b] BLE232ESIDE Version : Version: 9.0.1, Build id: 20180420-1214Project : Imported from BlueNRG-2 Navigator ExamplesExample : BLE_SensorDemo_BlueMSappBuild Status : SuccessHardware Test : OK - Tested by flashing code using : 1. BlueNRG-2 Navigator over USB-Serial, and 2. BlueNRG-1 ST-Link Utility over STLINK/V2.

Additional Information:

Console Message while debugging

Atollic TrueSTUDIO gdbserver for ST-Link. Version 4.2.2 (WIN32 2018-02-26 16:20:21 15675)

Copyright (c) 2018, STMicroelectronics. All rights reserved.Starting server with the following options: Persistant Mode : Disabled LogFile Name : debug_log.txtLogging Level : 31Listen Port Number : 61234Status Refresh Delay : 15sVerbose Mode : Enabled SWD Debug : Enabled

Atollic TrueSTUDIO gdbserver for ST-Link. Version 4.2.2 (WIN32 2018-02-26 16:20:21 15675)

Hardware watchpoint supported by the target STM32 device: Flash size =256Enter STM32_AppReset() function NVIC_DFSR_REG = 0x00000009XPSR = 0xC1000000ST_LINK Major version =2 Jtag version =31ST_LINK VID=1155 PID=14152ST_LINK device status: HALT_MODEST_LINK detects target voltage =3.24 VoltST-Link device initialization OKWaiting for debugger connection...Waiting for connection on port 61234...Accepted connection on port 61234...Debugger connectedST_LINK device status: HALT_MODEReading 0x4 bytes of memory from addr 0x100006fa Reading 0x2 bytes of memory from addr 0x100006fa Enter STM32_AppReset() function NVIC_DFSR_REG = 0x00000009XPSR = 0xC1000000Flash erase: Address= 0x10040000, Length=92160 Flash write: Address= 0x10040000, Length=192 Programming flash.. STM32 device: flash programming successful 0x10040000 Flash write completed in 0.198000 seconds, 0.946970kB/sFlash write: Address= 0x100400c0, Length=2944 Programming flash.. STM32 device: flash programming successful 0x100400c0 Flash write completed in 0.301000 seconds, 9.551495kB/sFlash write: Address= 0x10040c40, Length=2960 Programming flash.. STM32 device: flash programming successful 0x10040c40 Flash write completed in 0.305000 seconds, 9.477459kB/sFlash write: Address= 0x100417d0, Length=2944 Programming flash.. STM32 device: flash programming successful 0x100417d0 Flash write completed in 0.304000 seconds, 9.457237kB/sFlash write: Address= 0x10042350, Length=2944 Programming flash.. STM32 device: flash programming successful 0x10042350 Flash write completed in 0.307000 seconds, 9.364821kB/sFlash write: Address= 0x10042ed0, Length=2944 Programming flash.. STM32 device: flash programming successful 0x10042ed0 Flash write completed in 0.311000 seconds, 9.244373kB/sFlash write: Address= 0x10043a50, Length=1896 Programming flash.. STM32 device: flash programming successful 0x10043a50 Flash write completed in 0.275000 seconds, 6.732954kB/sFlash write: Address= 0x100441b8, Length=108 Programming flash.. STM32 device: flash programming successful 0x100441b8 Flash write completed in 0.202000 seconds, 0.522123kB/sFlash write: Address= 0x10044224, Length=48 Programming flash.. STM32 device: flash programming successful 0x10044224 Flash write completed in 0.264000 seconds, 0.177557kB/sFlash write: Address= 0x10044254, Length=124 Programming flash.. STM32 device: flash programming successful 0x10044254 Flash write completed in 0.204000 seconds, 0.593597kB/sFlash write: Address= 0x100442d0, Length=66 Programming flash.. STM32 device: flash programming successful 0x100442d0 Flash write completed in 0.214000 seconds, 0.301183kB/sFlash write: Address= 0x10044312, Length=16 Flash write completed in 0.057000 seconds, 0.274123kB/sReading 0x20 bytes of memory from addr 0xf0000fd0 Reading 0x4 bytes of memory from addr 0xffffffff Reading 0x4 bytes of memory from addr 0xffffffff Enter STM32_AppReset() function NVIC_DFSR_REG = 0x0000000BXPSR = 0xC1000000

Startup Scripts -> Target Software Startup Scripts

♯ Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2/F4 microcontrollers

♯ Uncomment next line, 2=32 bit, 1=16 bit and 0=8 bit parallelism mode&sharpmonitor flash set_parallelism_mode 2

♯ Set character encoding

set host-charset CP1252set target-charset CP1252

♯ Reset to known state

monitor reset

♯ Load the program executable

load

♯ Reset the chip to get to a known state. Remove ''monitor reset'' command

♯ if the code is not located at default address and does not run by reset. monitor reset

♯ Enable Debug connection in low power modes (DBGMCU->CR)

set *0xE0042004 = (*0xE0042004) | 0x7♯ Set a breakpoint at main().tbreak main

♯ Run to the breakpoint.

continue#bluenrg-2 #ide #bluenrg #ble #truestudio #stlinkv2

[Tesla DeLorean]

Sorry, bumping old zombie unanswered questions off my feed

[Dilbert K]

I just start with this board and having same issue...

Using both IAR and ST-Link Utility, could not connect to the EV board.

btw, I am using the cable come with the STLink... any mod require ??

[Dilbert K]

OK...got it working in IAR after few reset...

After lower the frequency in BlueNRG-1 ST-Link Utility also works now.

[Dilbert K]

Correction : further debug, even IAR would not work running debugger for project "BLE_SensorDemo_BlueMSapp"... Anyone able to get ST release working with debugger ??

[Xavier B.]

Anyone? I am facing the same issue using Keil uVision 5

[ASchu.4]

Hi!

Any updates? Just developed a board with bluenrg-232 and after the first programming cycle, i can't program, erase etc anymore.. I use Keil 5, programmed the MCU-s with BlueNRG-1 ST-link utility. Somewhere i read buy a Segger J-link, and it will solve the problem.

[Winfred LU]

Hi Dilbert,

Did you debug with the default DK "BLE_SensorDemo_BlueMSapp" project?

Probably it was because the device entering standby state, which disabled SWD pins (IO9 and IO10).

To recover this situation, the following options are recommended:

1) Disable deep sleep by changing call to BlueNRG_Sleep() as follow:

• BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0) -—> BlueNRG_Sleep(SLEEPMODE_CPU_HALT, 0, 0);
• In this mode, CPU will never goes to sleep and debug access is always granted. Application has to be modified and execution time may be different

2) Use a GPIO to wakeup the system and grant access to the debugger. User may need to change the call to BlueNRG_Sleep() as follow:

• BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0); -—> BlueNRG_Sleep(SLEEPMODE_NOTIMER, WAKEUP_IO13,(WAKEUP_IOx_LOW << WAKEUP_IO13_SHIFT_MASK)); /* Example for wakeup on IO13 low level */
• When debugger access is wanted, user should force the wakeup I/O (IO13 in the example) low and then use the “Attach to running target�? in the debugger. 

Please refer to BlueNRG-1,2 Debugging Tips for more details:

C:\Program%20Files%20(x86)\STMicroelectronics\BlueNRG-1_2%20DK%203.1.0\Docs\BlueNRG-1_Debugging_Guidelines\BlueNRG-1_Debugging_Guidelines.html

Best Regards,

Winfred

[Winfred LU]

Hi Schulcz,

It sounds like the same issue,

that after your firstly programming, the device entered sleep or standby state, which disabled SWD pins (IO9 and IO10).

Could you please try:

• Put the IO7 pin high and then reset the BlueNRG-1,2 device

This action will make UART bootloader activate and allow you to program again.

The following options are also recommended for debugging:

1) Disable deep sleep by changing call to BlueNRG_Sleep() as follow:

• BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0) -—> BlueNRG_Sleep(SLEEPMODE_CPU_HALT, 0, 0);
• In this mode, CPU will never goes to sleep and debug access is always granted. Application has to be modified and execution time may be different

2) Use a GPIO to wakeup the system and grant access to the debugger. User may need to change the call to BlueNRG_Sleep() as follow:

• BlueNRG_Sleep(SLEEPMODE_NOTIMER, 0, 0); -—> BlueNRG_Sleep(SLEEPMODE_NOTIMER, WAKEUP_IO13,(WAKEUP_IOx_LOW << WAKEUP_IO13_SHIFT_MASK)); /* Example for wakeup on IO13 low level */
• When debugger access is wanted, user should force the wakeup I/O (IO13 in the example) low and then use the “Attach to running target�? in the debugger. 

Please refer to BlueNRG-1,2 Debugging Tips for more details:

C:\Program%20Files%20(x86)\STMicroelectronics\BlueNRG-1_2%20DK%203.1.0\Docs\BlueNRG-1_Debugging_Guidelines\BlueNRG-1_Debugging_Guidelines.html

Best Regards,

Winfred

[ASchu.4]

Hi Winfred,

At first thanks for your answer. I made a custom board, with other USART pins. I just tried the GPIO Toggle project(without any energy management functions), and i bricked two processort.

I Will try to put the processor into bootloader mode, but can i acces the M0 via SWD in bootloader moder?

Another question: if i have an external pullup resistor on IO7 for I2C the processor always will go into bootoader mode?

Bests,

Attila