• 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

  • 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__glĀ­obal_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/documenĀ­tation/

    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.

  • ping keep alive

  • ping keep alive

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

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

Posted by Avatar for Robin @Robin

Actions