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

[Winfred LU]

Hi Attila,

Yes, you can access M0 via SWD in bootloader mode.

Actually, you can access it anytime when: 1) the device is not in sleep/standby mode, and 2) IO9/10 work as SWD pins.

To force the device in bootloader mode is just to make sure these 2 conditions are satisfied.

Alternately, other options are available, for you to easier using ST-Link tools:

• Add some delay at the beginning (i.e. on main() function add Clock_Init() followed by a delay of 2 seconds: Clock_Wait(2000)):
  • Reset the BlueNRG-1,2 and run the flash procedure from selected IDE IAR in a time of 2 sec.
• Perform a mass erase of the device using the BlueNRG-1 Flasher tool (which uses the BlueNRG-1,2 UART bootloader) and the program the selected application (with SLEEPMODE_CPU_HALT sleep mode parameter)

--

Regarding to I2C for IO7, you are correct. Please choose another pin (like IO5) instead.

Personally, I think it is a design flaw to have I2C normal function sharing with the Boot pin.

Thank you.

Best Regards,

Winfred

[KTarc]

Hi

the funy things is, Segger JLINK EDU works without any tricks, why? It is able to start debuging, no matter of the CPU state. STLINk should be able too.

BR

KWT

[Winfred LU]

Possibly it is because that the Reset pin is controlled properly.

Please refer to Target | Settings | Mode in ST-Link utility,

For the mode "Connect with Pre-Reset", it is useful in many cases like when the target contains a code that disables the JTAG/SWD pins.

[MRey.1]

I know it's old, but were you able to solve this problem? I'm facing the same now

[Winfred LU]

Please try to erase the flash firstly.

[MRey.1]

Thanks for the response. I tried to erase it with Keil and BLUENRG-X Flasher, it says that it erased successfully, but it still can't be read

Besides, if I try to erase by pages, it fails, so I believe it can't actually erase the chipI've also tried resetting with BOOT in high, but there were no differences so far