Error: E31 Remote Failure Reply, when starting code in debug mode

[NKupe]

Hello all, I am currently trying to get my STM32F411RE code working in Atollic TrueStudio. This project leverages the use of DMA and CMSIS-DSP which are all working in TrueStudio to find freqeuncy outcomes. The issues at hand is that I can upload my code to the STM32 board in the debug mode, but that this crashes once I attempt to resume the code and execute the main loop.

I upload the code to the board using the ST32 Cubeprogrammer CLI, which downloads and verifies the code without any hiccups. It then switches over to the ST-Link which executes the setup code and stops at the (auto inserted per GDB) breakpoint just before the main. Executing the code then yields:

TraceCaptureStart and SWV event set to APP_TRUE
ST-LINK device status: RUN_MODE
 
ST-LINK device status: Failed to get status, Target not responding, retrying...
Target is not responding, retrying....
 
ST-LINK device status: Failed to get status, Target not responding, retrying...
Target is not responding, retrying....
 
ST-LINK device status: Failed to get status, Target not responding, retrying...
Target is not responding, retrying....

It then keeps repeating those 2 lines until it times out and kicks me back to the editor environment.

Then by using the GDB Trace option (inside the debug configurations) I was able to find that the resulting error is

Warning: remote failure reply: E31

which by searching around (on this forum) yielded that this is an error with the GDB server. I tried to run the GDB server as a remote client, but this yielded the exact same issues. This link shows the GDB trace code up until the breakpoint (https://pastebin.com/9kygHtwD), whilst this link shows the code after proceeding past the breakpoint by resuming the code execution (https://pastebin.com/tHNwR7Hy).

I am now wondering if perhaps it has something to do with the code itself? I have included my total code here (https://pastebin.com/XWsS7urd), whilst the setup() and main() can be found here (https://pastebin.com/Lj24zvge).

Because of these errors I also have to erase my chip (ST-Link or STCubeProgrammer) after debugging before I can upload my code again; I presume this is because of the board not being shutdown correctly with the debugger crashing? Or would I need to do this always?

EDIT: as per my reaction in the comments, I have tried to upload a newly generated project (from CubeMX) onto the board and I still get the same issues. So it is either something to do with my toolchain or it is due to the STCubeMX standard code

[Tesla DeLorean · Accepted solution]

Low power modes where debug interface is turned off. ie WFI

Reconfiguring of pins used by the debug interface.

Debugger breaking real-time deadlines for interrupt/peripheral service.

DMA operations which continue which CPU stalled in debugger waiting for human interaction.

Check connect under reset options, or BOOT0=HIGH settings, if your code blocks debugger connection/programming.

[NKupe]

As for the low power modes, I have not intentionally set up any of them in the user code, but perhaps such a mode is instigated by the code generated by CubeMX when the chip is idling?

Regarding the reconfiguring of pins, I use the USB micro B connector on the board with ST-Link for debugging. So I dont think it is possible to change the pins?

EDIT: I have since tried to flash a completely empty project on to the board, using only code that was generated by the STCubeMX. I still get the same errors, so either it is due to boiler plate code that STCubeMX produces or it has got something to do with the ST-Link / STCubeProgrammer itself

[NKupe]

I have since figured out that the issues lies with the startup scripts in the debug configuration. The Target Software Startup Scripts I had for my debug that caused the crashing is:

# 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
#monitor flash set_parallelism_mode 2
 
# Set character encoding
set host-charset CP1252
set 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

Whilst the code that lets me run the main loop in the debugger is:

# Set flash parallelism mode to 32, 16, or 8 bit when using STM32 F2F4 microcontrollers
# 2=32 bit, 1=16 bit and 0=8 bit parallelism mode
monitor flash set_parallelism_mode 2
 
# Load the program executable
load		
 
# 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

I am not sure yet what is faulty about the first code, but I will evaluate it and post my findings

[NKupe]

Evidently this issue was caused by my use of the GPIO_Init code block as default generated by the CubeMX program. Removing or uncommenting this block solved the issue for me, weirdly enough.

However, I have now run into an issue where including

arm_rfft_fast_init_f32(&fftInstance, 1024);

will yield me the error

 Why could this be happening? I need the aforementioned code to initialize the FFT, right? It does not give me this error if I only uncomment that particular line (L 139)

[NChor.1]

Put a jumper on your ST Link V2(VDD(19) and TVCC(1))