What is the best way to debug both ends of a communications link?

[Harvey White]

Windows 10, CubeMXIDE 1.12.0

Mixed C/C++, STM32L562 processor on custom board.

using STLINK V2 and V3 debugging.

Common software installed as links, configuration file and main.c are really the only unique files that I provide. Configuration file is a bunch of #defines to switch in hardware and software features. All other files that I provide are identical, working equally well on both ends of the system (Root and new node).

I'm debugging both ends of an NRF24L01 mesh network at the same time, watching how each module responds (SPI interface). It's done, the mesh works but needs some refinement, but the communications sequences and responses are working properly.

Hardware debuggers work well with each, but as far as debugging both ends of the link at the same time, I'm wondering if there is an easier way.

With both projects in the same workspace, there is a problem with each debugger pulling up a "copy" of the source (it's the same). There's no really obvious way to tell which is which for the linked files, and I end up with two files in the editor that are out of sync. Any suggestions about that?

When debugging, the breakpoints are not separated by processor (and could be, and perhaps should be). This makes life difficult as well. Common software is working differently depending on the function, but the main loops are still identical. Breakpoints do not readily identify which processor is what, even though they are detailed in the thread descriptions. I'm looking for more obvious.

Any suggestions on the programs in the same workspace method?

I've also got the system set up with two instances of the IDE, which is better when identifying which processor is which. Needs dual monitors, but that's less of a problem than otherwise.

breakpoints would and are separate, so that is less of a problem.

The difficulty I see is in file synchronization. Changing one instance of a file for one processor does not automatically change the instance in the other IDE. Granted, when the software is recompiled, the file on disk changes.

However, that is not necessarily picked up by the second IDE. Since the natural inclination is to debug programs for each processor in the separate window, there are file synchronization problems.

Any comments about this method?

I'm suspecting that I might be missing something, but normally, I do not have two simultaneous debug sections running (and I foresee lots of them when I get into board to board communications). Surely there are people who do this a lot, so what am I missing? I have no real desire to change operating systems, but I'm used to FreeRTOS, know where the bodies are buried, and AZURE does not like C++, and I don't like AZURE queues. A topic for another time.

What's the better method?

[Pavel A.]

You can create a new eclipse workspace (temporary) and run two instances of CubeIDE debugger.

Of course, use two monitors if this is more convenient.

In every CubeIDE instance keep only one project open and close the other one to avoid confusion. If you think some file is out of sync, press F5 (refresh) or re-index. Use your version control software to detect unwanted changes.

> There's no really obvious way to tell which is which for the linked files

Open the properties of a file, go to the Resource tab, it shows the real (resolved) file path.

If you think this is too complicated, imagine that other folks have to debug dozens of CPUs at once - and be relieved ))

[Harvey White]

I was hoping that someone, somewhere had come up with a plugin, or a more rewarding methodology. I hadn't considered the F5 key to refresh, being more concerned with actually getting the project to work (silly me......). The two instances of CubeIDE may become my preferred method, two monitors are available, one way or another.

Actually, some attention to each instance of the IDE will give a good idea of what is what, I was looking for the large print version. I'm not worried about the resolved path, it comes out to the same regardless of which instance is in focus. Other than the files generated by CubeMX, There is really only one file that is different between the two projects. Other files would be included or not in the build depending on conditionals. The .loc files are different because the hardware is different, but my "options.h" contain all the #ifdef and #define statements needed to rather completely define a project other than the main.h, main.c files. Any other variables are not a problem.

Ya think that CubeMX is going to be used on a dozens of processors project? Not even sure I could afford the ST Links for the project, let alone the processors and boards. I have a feeling that someone dealing with a project of that magnitude would have a company that would throw money at the development tools. Alas, I cannot.

Thanks

[ETong.1]

Hi,

I'm trying to do the same, debug two target boards at the same time when both are running. How to set the debug port number to make it connect to the different board?

When I change debugger configuration by using the port number from Port COM 10 or 11, I'm getting connection error

So far, only use Autostart localhost, by connecting one board at a time works.

Thanks

[ETong.1]

Select ST-LINK S/N with the scanned value can find the right board now.

[ETong.1]

If you want to keep both projects in the same IDE, you can use split window to have one project on the left and the other project on the right side. But it is not as clear as two IDE workspaces. Sometimes when you open the file by double click, they may not go to the right side.

[Harvey White]

OK, there are two approaches,

1) both projects in the workspace: cons: the processors are hard to tell apart.

2) each project in a separate instance of the IDE.

I've been quite successful with #2, and #1 is awkward.

Open one end in an instance of the IDE. Under Debugging, select a specific serial number for the STLink you're using, easiest to do is to configure the system with only one connected, but do not choose "auto". You need to have a specific serial number matching the STLink you have connected to the current project. You don't care about which serial port is emulated.

Open the other end in another instance. Select the other STLink by its serial number/ Things related to one end will be in the appropriate instance. .

You must, however, realize that when you make a change to one instance of a common file, while you automatically save the file when you, you do not update the editor's view in the other instance. You must remember to hit F5 to refresh the file.

Otherwise, you'll get the "file has been changed and is not the same as the file in the editor....." etc.

We need a mechanism to handle this, but debugging two instances (or more) has never been a priority, judging simply by probability.

[Pavel A.]

@Harvey White​ ST-LINKs are very affordable (I even wonder are they subsidized?). If they look expensive for you then I dunno. Again, compare them to J-LINKs or IAR adapters and be relieved.

> I have a feeling that someone dealing with a project of that magnitude would have a company that would throw money at the development tools.

Of course. When you work for such company, you get some interesting stuff. But throw... they call it investment ))

[Harvey White]

I was thinking 5 plus nodes all simultaneously being debugged, not that I see myself doing it, but it did hit a price point. The ST-Links are likely subsidized, The rather high cost of a J-Link is one reason I never (and may never) use that product. The smart idea for a processor manufacturer is to supply the tools at as low a cost as possible to capture as much market as possible.

Big companies call it investment, my wallet calls it expense...... <grin>

[Tesla DeLorean]

Use serial output for debug/telemetry.

If you have to single step all your own code to know how it works/responds should probably do some static analysis and think through the logic.

Instrument so you understand flow and dynamics, real-time

Add a monitor program where you can query internal states, and initiate test functions/sequences.

Compile in multiple options and methods, that way you're not stuck doing one change at a time.

Have functionality and responder functionality in remote nodes so you can query them.

Be able to push updates to the node(s) so you're not moving around to reprogram them each individually / physically.

Think of things that leverage and scale well, focus on implementing those early as they'll save you time.