CubeMX, mixed C, C++, F767 Nucleo. Getting consistent errors: debugger tries to connect, has following error. Encountered a Socket Error, Exiting..

[Harvey White]

Getting the following error:

code compiles without problem. Code without a certain class compiles and can be downloaded and run. Code *with* class generates following error.

STMicroelectronics ST-LINK GDB server. Version 5.1.0

Copyright (c) 2018, STMicroelectronics. All rights reserved.

Starting server with the following options:

       Persistent Mode           : Disabled

       Logging Level             : 1

       Listen Port Number        : 61234

       Status Refresh Delay      : 15s

       Verbose Mode              : Disabled

       SWD Debug                 : Enabled

Waiting for debugger connection...

Debugger connected

Encountered a Socket Error, Exiting..

Debugger connection lost.

Shutting down...

1) has anyone seen this before?

2) why would something compile and then not download properly?, but with a socket error?

3) code is relatively complex, with a lot of derived classes (graphics application), not practical to post all of it here.

code added that crashes the download is a relatively simple class for a touch controller.

Have seen the same error before, seems related to something the compiler and linker are doing with C++ code. Never saw it when running C code only.

Main structure of program is main.c renamed to main.cpp, calls link cpp program, then calls only cpp programming unless calling HAL functions (which are C), or FreeRTOS, which are also C.

[Harvey White]

A bit of debugging seems to indicate that the removal of a virtual routine:

I2C/SPI -> IODRIVER -> touch_controller (mostly virtual) -> TSC2046 -> touch control object (where TSC2046 is a hardware driver)

I2C/SPI -> IODRIVER -> TSC2046 -> touch control object (where TSC2046 is a hardware driver)

seems to eliminate (or work around) the problem.

While it doesn't seem to make sense, could the compiler be putting virtual tables in memory that the linker can't download, and this gets somehow reported as a "socket error"?

Note that this is NOT the kind of error that causes a hard fault when run, those are simple bad pointers.

This seems to be something that the linker/compiler are doing.

no idea why.

[Tesla DeLorean]

Sounds like a GDB "Server" failure.

Pretty sure it isn't the fault of the compiler or the linker.

You'll lose connectivity in the debugger if you reprogram the pins involved in the SWD interface, or sleep the processor such that the same interface powers down.

Review the linker script (.LD) and map file (.MAP) to see what's being generated. Review the startup code, and how the constructors are functioning.

Consider more professional tools.

[Harvey White]

Yes, and I can't disagree. However, how come changing the code *reliably* crashes or not? Puzzled here.

Pins in the SWD are NOT used, very deliberately so. Ditto with processor sleeping.

I can comment out one line of code and it loads. Shut it down and 10 seconds later, code included, it crashes. 10 seconds later, code removed, it is fine.

That seems to rule out processor sleep or SWD pins.

What would you consider more professional tools other than Atollic and what ST Micro provides?

[Harvey White]

I’ve been working on a fairly complex project, F767 driving a 320x240 TFT touchscreen. The project was originally written in C, but without object inheritance, started to get too complex.

I have a number of graphics object classes, each a descendant of a node object (for linked draws). The graphics_object class itself has utility functions but not much else. Thus, the next descendant is a point, which has all the routines needed to draw a point at any place on a display. All other graphics objects descend from this.

The displays are descendants of either the SPI or I2C drivers through an IODRIVER class. The display _driver class itself is virtual, allowing a particular display to be accessed indirectly through a pointer maintained and assigned by a separate routine.

All of this is running under FreeRTOS, with tasks for an application, LED driving, battery charge icon, string widget icons and the like. A touch screen task monitors on screen buttons and calls appropriate routines or switches to other defined screens.

All was working well until the system started crashing with a hang in syscalls. Syscalls has an error routine that if there’s an exception, it goes and hangs, with enough of a history to find out what was crashing. New() was crashing. It came back with a null pointer (and was supposed to create an instance of each new graphics object). Malloc and pvPortMalloc did succeed in getting a pointer to memory (non nullptr).

That “problem�? was “fixed�? by making all the graphics data structures exist in ram (not accessed by pointers) so that the new() function wasn’t needed.

Now things went well enough until adding a screen routine caused the debugger to fail with a “socket error�?.

Rewriting to eliminate all of the remaining new() helped a bit, but the problem seemed to be traceable down to a particular routine where the display pointers were included in a system call for a hex dump object (it has lots of formatting possibilities).

Calling the routine with a default to the main display causes the error. Causing the routine to write to an internal string (and it was doing that anyway), works. Writing that string to the display also works. Directly specifying the display with the pointer to the display in the calling routine doesn’t work. I’m thinking that the debugger has some problems with virtual function calls and pointers.

Note that all of these routines compiled, linked, and would otherwise run if the offending call were taken out.

It’s possible that the debugger has problems with pointers in C++.

It’s possible that the debugger may be making assumptions that the compiler and linker (v 9.3.0 Atollic studio) are doing things one way, and they may not.

Is this a fix? no. Is this a workaround? Yes, so far.

[Harvey White]

Please see

Atollic 9.3 debugger has socket error, refuses to load.

for a possible workaround that seems to be reliable