STM32CubeIDE: Throws "Failed To Enable SWI" Error on Some Projects

Garnett.Robert · ‎2022-04-23

Hi,

I have three projects, running on an STM32H7B3I-DK Discovery board.

They Are:

Complex - Using TouchGFX, a lot of I/O, timers, ADC's I2C, SPI and the other project is simple using only the ADC's. Throws SWV error

Simple - No TouchGFX using ADC 1 and ADC 2 Only No SWV Error

Simple - Using Touch GFX and no other I/O No SWV Error

When I debug the complex project I get an error: "Failed To Enable SWI - SWV will be disabled for this debug session" When I debug the simple project the error does not occur.

Obviously it is something in the build of the complex project that is causing this. The debug settings are identical for each project and are shown in the screen shots attached.

The console output for the debug build is:

STMicroelectronics ST-LINK GDB server. Version 6.1.0

Starting server with the following options:

Persistent Mode : Disabled

Logging Level : 31

Listen Port Number : 651234

Status Refresh Delay : 15s

Verbose Mode : Enabled

SWD Debug : Enabled

InitWhile : Enabled

COM frequency = 24000 kHz

Target connection mode: Under reset

Reading ROM table for AP 0 @0xe00fefd0

Hardware watchpoint supported by the target

ST-LINK Firmware version : V3J9M3

Device ID: 0x480

PC: 0x8000bb4

ST-LINK device status: HALT_MODE

ST-LINK detects target voltage = 3.27 V

ST-LINK device status: HALT_MODE

ST-LINK device initialization OK

Stm32Device, pollAndNotify running...

SwvSrv state change: 0 -> 1

Waiting for connection on port 61412...

Waiting for debugger connection...

Waiting for connection on port 61410...

Accepted connection on port 61410...

Debugger connected

Waiting for debugger connection...

Waiting for connection on port 61410...

GDB session thread running

GdbSessionManager, session started: 1

Accepted connection on port 61410...

Debugger connected

Waiting for debugger connection...

Waiting for connection on port 61410...

GDB session thread running

GdbSessionManager, session started: 2

Stm32Device, closeDevice() entry

GDB session, device event: 5

Stm32Device, pollAndNotify stopped

Stm32Device, closeDevice() exit

------ Switching to STM32CubeProgrammer -----

-------------------------------------------------------------------

STM32CubeProgrammer v2.10.0

-------------------------------------------------------------------

Log output file: c:\users\admin\appdata\local\temp\stm32cubeprogrammer_a35960.log

ST-LINK SN : 002D00483438511534313939

ST-LINK FW : V3J9M3

Board : STM32H7B3I-DK

Voltage : 3.27V

SWD freq : 24000 KHz

Connect mode: Under Reset

Reset mode : Hardware reset

Device ID : 0x480

Revision ID : Rev Z

Device name : STM32H7A/B

Flash size : 2 MBytes

Device type : MCU

Device CPU : Cortex-M7

BL Version : 0x90

Memory Programming ...

Opening and parsing file: st-link_gdb_server_a35960.srec

File : st-link_gdb_server_a35960.srec

Size : 212.70 KB

Address : 0x08000000

Erasing memory corresponding to segment 0:

Erasing internal memory sectors [0 25]

Erasing memory corresponding to segment 1:

Erasing external memory sector 0

Download in Progress:

�� 0%

�� 100%

File download complete

Time elapsed during download operation: 00:00:00.804

Verifying ...

Read progress:

�� 50%

� 2%� 4%� 6%� 8%� 10%� 12%� 14%� 16%� 18%� 20%� 22%� 24%� 26%� 28%� 30%� 32%� 34%� 36%� 38%� 40%� 42%� 44%� 46%� 48%� 50%� 52%� 54%� 56%� 58%� 60%� 62%� 64%� 66%� 68%� 70%� 72%� 74%� 76%� 78%� 80%� 82%� 84%� 86%� 88%� 90%� 92%� 94%� 96%� 98%� 100%

Download verified successfully

------ Switching context -----

COM frequency = 24000 kHz

Target connection mode: Under reset

Reading ROM table for AP 0 @0xe00fefd0

Hardware watchpoint supported by the target

ST-LINK Firmware version : V3J9M3

Device ID: 0x480

PC: 0x8000bb4

ST-LINK detects target voltage = 3.30 V

ST-LINK device status: HALT_MODE

GDB session, device event: 6

Stm32Device, pollAndNotify running...

GDB session, device event: 3

GDB session, device event: 1

GDB session, device event: 0

NVIC_DFSR_REG = 0x0000000B

The debug console output is:

GNU gdb (GNU Tools for STM32 10.3-2021.10.20211105-1100) 10.2.90.20210621-git

License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software: you are free to change and redistribute it.

There is NO WARRANTY, to the extent permitted by law.

Type "show copying" and "show warranty" for details.

This GDB was configured as "--host=x86_64-w64-mingw32 --target=arm-none-eabi".

Type "show configuration" for configuration details.

For bug reporting instructions, please see:

<https://www.gnu.org/software/gdb/bugs/>.

Find the GDB manual and other documentation resources online at:

<http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".

Type "apropos word" to search for commands related to "word".

Warning: the current language does not match this frame.

set *(int *)0xE000EDFC=*(int *)0xE000EDFC|0x7F0

set *(unsigned int *)0x5c001004|=0x3f

Temporary breakpoint 3, main () at G:/ShorttClock_V2/ShorttClock_V2/Core/Src/main.c:124

124 MPU_Config();

I turned logging on in the debug config, but it didn't produce the file listed in the console output:

c:\users\admin\appdata\local\temp\stm32cubeprogrammer_a35960.log

There was a file called LWSDebugOut.txt created at the same time as the debug session. It was 11 MByte and too large to attach.

I have the following questions:

How does the IDE decide that the SWI is unavailable?
Where should I look in my project for the cause of the error?
I am connecting under hardware reset from the debugger so the processor should be in the reset condition making all IO default and therefore the SWI should be OK, is this correct?
Is it possible I have a pin-out clash with the SWI interface?
Is there a possible problem with the start-up file or HAL_Init?

Any ideas on what might be the problem?

best regards

Rob

Markus GIRDLAND · ‎2022-04-26

Hello there,

I believe the problem might be in the port number. In the STM32H7B3I_DISCO project the port number 651234 is used instead of the default 61234 which makes the port number way too big.

View solution in original post

Markus GIRDLAND · ‎2022-04-26

Hello there,

I believe the problem might be in the port number. In the STM32H7B3I_DISCO project the port number 651234 is used instead of the default 61234 which makes the port number way too big.

Garnett.Robert · ‎2022-04-26

Hi Markus,

Yep! You are right.

I must have had another senior's moment.

I had a support ticket on this, could you close it for me please.

Sorry to waste your time on silly mistakes.

Thanks

Rob

Markus GIRDLAND · ‎2022-04-27

Hello Rob,

Those tickets are not managed at my level so unfortunately I can't close it for you. If you communicate through the OLS interface and mention that it's solved I'm sure they'll be happy to have an "open-and-shut" case ��

Also, even if it was an easy mistake to correct this time the amount of information coupled with the screenshots always makes these things easier to analyze, so thank you for that. Happy to help!

Garnett.Robert · ‎2022-04-27

Hi Markus,

I will put a comment through the OLS.

I always try to provide as much info as I can. In fact framing the question is often much harder than the solution. I have put together complicated questions a number of times then, because you have to go through a logical process to do this you actaully come up with the answer without actually having to post the question.

best regards

Rob