Advanced Debug: How to solve for PICO_R1_3 make: *** No rule to make target 'gdb' Stop

[espruino-discuss]

Posted at 2021-11-21 by Robin

Sun 2021.11.21

Goal is to debug within the Espruino Linux executable.

Last code snippet on the AdvancedDebug page produces the above error.

Following the 'Advanced Debug' instructions at:

https://www.espruino.com/AdvancedDebug

'we'd strongly suggest you try and debug a normal Linux executable of Espruino first'

Fixed Under 'Gothchas'
Removed the reference: ''bootloader' : 1' from the board file
Ran make using DEBUG=1

What does work: The Espruino Linux executable is built along with espruino_2v08.220_pico_1r3.bin and .lst

It is possible to execute Javascript statements within the Terminal window, with the console like emulation, thus debugging Javascript is possible, but the goal is to debug setting breakpoints within that .c source Linux executable.

From the last snippet window on the AdvancedDebug page:

DEBUG=1 PICO_1V3=1 make gdb

produces error: make: *** No rule to make target 'gdb'. Stop.

Reviewing the makefile file, around L700 is a single reference to gdb: export GDB=$(CCPREFIX)gdb Reviewing the make files within the folder \make doesn't reveal a gdb make target file.

I tried the second to last snippet:
DEBUG=1 PICO_1V3=1 make flash
make/sanitycheck.make:16: *** You now need to build with 'BOARD=PICO_R1_3 make'. Stop.

which produces an apparent modification that needs attention.

I did locate this sanity check, and attempted to follow the established pattern.

From sanitycheck.make, references indicate to use the 'BOARD=' prefix, so tried that:

DEBUG=1 BOARD=PICO_R1_3 make gdb

but without success. Is there a missing gdb make file that is needed here? Is there a gdb entry point that needs to be included, maybe in a separate make routine or file?

Back to trying this @fanoush arm-none-eabi-gdb suggestion:

post #3 last pp. Conceptual comments needed on simple firmware debug

[espruino-discuss]

Posted at 2021-11-21 by Robin

While I'm searching for a suitable gdb tutorial or suggested command line instruction set,

I have made a bit of progress with attaching the gdb process, but I'm not sure this is going to get me to setting breakpoints within the .c source, similar to how one might debug a Visual Studio C#/C/CPP project.

From the web page content, link post #1, my mental model is that the .c source seen within the VSCode app would be the launch point to start a main.c file there. Several failed attempts at tasks.json and launch.json
left me a bit bewildered, and had gotten to the hardware debug stage with SEGGER and SWD. This still seems to be the subsequent next step, before gaining the experience debugging with the Espruino Linux executable, which should be first, shouldn't it?


For example, should I need to set a BP at (inside fcn):

L958 jshardware.c
JsSysTime jshGetSystemTime()

what is the process to get from Javascript instruction

https://www.espruino.com/Reference#l__global_getTime

presumeably run from the Espruino Linux exectuable running inside the VSCode Terminal, through to the call

jswrap_interactive.c#L362 on to the call to jshGetSystemTime()

Still seeking the solution there, maybe sample tasks.json and launch.json are needed, but in the meantime:

Entry point: 0x26554
        0x00026000 - 0x0006ace0 is .text
        0x0006ace0 - 0x0006ad10 is .sdh_ble_observers
        0x0006ad10 - 0x0006ad30 is .sdh_soc_observers
        0x0006ad30 - 0x0006ad50 is .sdh_state_observers
        0x0006ad50 - 0x0006ad60 is .sdh_stack_observers
        0x0006ad60 - 0x0006ad68 is .sdh_req_observers
        0x0006ad68 - 0x0006ad7c is .nrf_queue
        0x0006ad7c - 0x0006ad84 is .ARM.exidx
        0x20003720 - 0x200039a0 is .data
        0x200039a0 - 0x200039b4 is .fs_data
        0x2003fff0 - 0x20040000 is .noinit
        0x200039b8 - 0x200332d0 is .bss
(gdb) nexti
0x000140d4 in ?? ()
(gdb) nexti
0x000140d6 in ?? ()
(gdb) nexti
0x000140d8 in ?? ()

> https://www.gnu.org/software/gdb/documentation/

Although I'm not entirely certain at how to interpret the above, it appears the .elf file is being decoded and it appears the instruction(s) is being stepped into, until I learn the gdb commands, am I on the right path to get at the source? The above seems more of a hardware register debug process.

---

Posted at 2021-11-25 by Robin

ping keep alive

---

Posted at 2021-11-28 by Robin

ping keep alive