compuphase / Black-Magic-Probe-Book

A guide plus associated utilities for the Black Magic Probe.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Source Code Not Visible

d-adamson opened this issue · comments

Moving this to a new issue

bmdebug comes up and initializes, but I do not see anything in the source window.
However, I can type "list main" in the console and see the source.
Normally my *.elf is in a "build" subdirectory. I've tried putting the *.elf and *.c in the same directory, but that does not seem to help.

Screenshot from 2023-02-19 16-01-47

Originally posted by @d-adamson in #29 (comment)

Just tested commit 747334b

Unfortunately the source is still not visible. Skimming through the changes, I can see you put some serious work into this.

Here is the latest screenshot, output file, and bmcfg file.

In the screenshot, the gdb console is pointing to the correct source file.

I can set break points in console and the code will run to the break point.

Screenshot from 2023-02-23 10-07-19
Output_bmdebug.txt
blink-10.elf.bmcfg.txt

In commit 31cd6ab, I made two changes:

  1. Extra logs (when run with "bmdebug -d" option) to show what source file it attempts to load, and what the result was.

  2. When the main view says "NO SOURCE", the line below shows GDB's index in its table with source files, and which filename matches that number according to bmdebug.

With the answers to these points, we can narrow down on the bug.

Linux make failed

$ make
gcc -c /usr/include/GLFW -Wall -g -obmdebug.o bmdebug.c
bmdebug.c: In function ‘sources_add’:
bmdebug.c:1597:46: error: ‘errno’ undeclared (first use in this function)
 1597 |       printf("file open failed, error %d\n", errno);
      |                                              ^~~~~
bmdebug.c:100:1: note: ‘errno’ is defined in header ‘<errno.h>’; did you forget to ‘#include <errno.h>’?
   99 | # include "res/icon_debug_64.h"
  +++ |+#include <errno.h>
  100 | #endif
bmdebug.c:1597:46: note: each undeclared identifier is reported only once for each function it appears in
 1597 |       printf("file open failed, error %d\n", errno);

Added line 57 in bmdebug.c
# include <errno.h>

Make completed.

Starting testing ...

Here are the results:
Screenshot from 2023-02-24 15-11-51
Out.txt

Finally found the parsing error. Should be fixed in commit c5f03b1.

Fantastic! I just checked it and it's working! 👍

Unfortunately, there appears to be another crash when opening a SVD file.

path to svd
~/pico/pico-sdk/src/rp2040/hardware_regs/rp2040.svd

Here is the log output:

OutSVD.txt

What I see, in the OutSVD.txt file, is that the code started running with a temporary breakpoint at main, then moves to the "STOPPED" state when it reaches the breakpoint. At that point, the log is aborted. There was probably still data in the stdout buffer at the time of the crash.

In the commit c3442c2, I only added fflush() to the log functions, so that the debug output will be complete.

If the program halted correctly at main() and that crashed as soon as you opened the SVD file, the bug is likely in the SVD parser. In that case, can you send me the rp2040.svd. I got a copy from the raspberrypi/pico-sdk project here on GitHub, but that loaded fine in my case. I tested on Windows, though. I will test on Linux tomorrow. (But the code is generic, so I do not see how it would be OS-dependent.)

Unfortunately, it is still crashing. I waited about 30 seconds after the code hit the break point at main, just to let any potential background tasks settle.

Here is the output of the log file and the svd file (I added the .txt extension so that it would upload to this thread).

OutSvd-2.txt
rp2040.svd.txt

Commit ca36470 fixes a buffer overrun in SVD parsing.

I was able to reproduce the crash on a different workstation. After this fix, loading the SVD file no longer crashed.

Thanks Thiadmer ,

It looks like it is all up and running!
You are a super hero! 🥇

Thanks a lot for your persistence in testing. I would not have found these three (!) bugs without your log data.