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

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.

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.