VisualGDB with STM32L476RG Nucleo - visual-studio

Question

I setup Visual Studio 2015 with VisualGDB, and setup an LED Blink project using the HAL, as described in this example: http://visualgdb.com/tutorials/arm/stm32/stm32l4/
The tools installed correctly, and the my project follows the example exactly, including Step 6, and then up through Step 7. However, after setting a breakpoint and attempting to run to it per Step 8, I get the following in the Output window:
Open On-Chip Debugger 0.9.0 (2015-10-08-15:57)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select <transport>'.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v10 VID 0x0483 PID 0x374B
Info : using stlink api v2
Info : Target voltage: 3.263434
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
adapter speed: 4000 kHz
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
adapter speed: 4000 kHz
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
adapter speed: 4000 kHz
Warn : Padding 4 bytes to keep 8-byte write size
target state: halted
target halted due to breakpoint, current mode: Thread
xPSR: 0x61000000 pc: 0x2000004a msp: 0x20020000
Warn : block write succeeded
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x01000000 pc: 0x0800027c msp: 0x20020000
Error: Memory write failure!
At the same time, I get a dialog pop-up that states: "The memory location used for the stack is not writable. Please check the device type and the linker script. You can disable automatic stack checking via VisualGDB Project Properties"
Looking in the .map file that was generated during the build, there is nothing near 0x61000000 or anything at 0x01000000. There is a _estack = 0x20020000.
I added a -N to the linker flags (LDFLAGS := -Wl,-N,-gc-sections), to see if this would affect anything, and id didn't.
Any ideas on what may be wrong?
Thank you in advance.

Answer 1

The "The memory location used for the stack is not writable" error occurs when VisualGDB tries to test whether the end-of-stack (_estack - 4) is writable.
If you switch the GDB Session window to the All GDB Interaction mode, you will see that VisualGDB is trying to write a random value there and then checks whether it can be read back:
-data-evaluate-expression "&_estack"
^done,value="0x20020000"
-var-create - * "*((void **)0x2001fffc)"
^done,name="var1",numchild="0",value="0x80002ad ",type="void *",has_more="0"
-var-assign "var1" 0x1b5bfd22
^done,value="0x1b5bfd22"
-data-evaluate-expression "\*\(\(void\ \*\*\)0x2001fffc\)"
^done,value="0x1b5bfd22"
If it does not, most likely you have selected an incorrect device while creating your project (e.g. your device actually has 32KB of RAM while you have selected a device with 64K of RAM). There can also be a bug in the VisualGDB device definitions.
You can find this out by comparing the address of _estack from your linker script with the end address of the RAM described in your device datasheet.