2020-02-09 08:20 PM
I have an application for Nucleo-H7A3ZI-Q which causes "ST-LINK device status: LOCKUP" very early into an execution, as early as 2/3 of the way into initialized data section copy loop in startup.s.
STMicroelectronics ST-LINK GDB server. Version 5.2.3
Copyright (c) 2019, STMicroelectronics. All rights reserved.
Starting server with the following options:
Persistent Mode : Enabled
LogFile Name : debug.log
Logging Level : 31
Listen Port Number : 61234
Status Refresh Delay : 15s
Verbose Mode : Disabled
SWD Debug : Enabled
Hardware watchpoint supported by the target
SWD frequency = 4000 kHz
ST-LINK Firmware version : V3J0S0
Device ID: 0x480
PC: 0x8040eac
ST-LINK device status: HALT_MODE
ST-LINK detects target voltage = 3.26 V
ST-LINK device status: HALT_MODE
ST-LINK device initialization OK
Waiting for debugger connection...
Waiting for connection on port 61234...
Accepted connection on port 61234...
Debugger connected
Wrapping read detected. Addr: 0xfffffffe; Length: 4
TraceCaptureStart and SWV event set to APP_TRUE
ST-LINK device status: LOCKUP
Enter STM32_AppReset() function
NVIC_DFSR_REG = 0x00000009
NVIC_CFGFSR_REG = 0x00000000
XPSR = 0x01000000
Error! Failed to read target status
Debugger connection lost.
Shutting down...
Client gdb gives E31 error and drops connection.
The same application, linked with data segment shifted few K bytes aft gives hard fault as early as few steps into the execution, immediately at the entry of the first bl call after sp initialization.
Well, the behavior is inconsistent, but the LOCKUP is really annoying.
What is the general cause of the LOCKUP behavior?
Any info would be appreciated.
EDIT
Some additional info
STLINK-V3 is flashed with V3J6M2, but the gdbserver is displaying "ST-LINK Firmware version : V3J0S0".
The application is over 512KB in flash size.
Solved! Go to Solution.
2020-02-10 08:19 PM
Self followup.
The issue seems to be resolved for Nucleo-H7A3ZI-Q with a combination of following software versions.
STLINK-V3 firmware
V3J6M2
(Now the gdbserver correctly reads the version.)
STLINK-gdbserver
5.4.0
Came with an installation of STM32CubeIDE 1.2.0 (or possibly 1.2.1; I came to notice the combination works after upgrading to 1.2.1)
Path to the working executable is as follows.
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.macos64_1.1.0.201910081157/tools/bin/
2020-02-10 08:19 PM
Self followup.
The issue seems to be resolved for Nucleo-H7A3ZI-Q with a combination of following software versions.
STLINK-V3 firmware
V3J6M2
(Now the gdbserver correctly reads the version.)
STLINK-gdbserver
5.4.0
Came with an installation of STM32CubeIDE 1.2.0 (or possibly 1.2.1; I came to notice the combination works after upgrading to 1.2.1)
Path to the working executable is as follows.
/Applications/STM32CubeIDE.app/Contents/Eclipse/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.macos64_1.1.0.201910081157/tools/bin/