(resolved) Need help: "Failed to launch GDB: Load failed" -- when the load succussed

BHAudio · June 3, 2023, 4:45am

Hello all,

I am looking into the following error:

"Failed to launch GDB: Load failed (from target-download)"

When looking at the log the download shows success, but then it has a get_status error 74 and this seems to throw off the debugger.

From the DFU download log:

File downloaded successfully
Error during download get_status
make: *** [../libDaisy/core/Makefile:330: program-dfu] Error 74

Here is the last part of the GDB log :

GDB -> App: {"output":"","token":13,"outOfBandRecord":[{"isStream":false,"type":"status","asyncClass":"download","output":[]}]}
-> 13^error,msg="Load failed"
GDB -> App: {"output":"","token":13,"outOfBandRecord":[],"resultRecords":{"resultClass":"error","results":[["msg","Load failed"]]}}
14-interpreter-exec console "monitor reset halt"
Failed to launch GDB: Load failed (from target-download)

From the debugger terminal:

[2023-06-03T04:19:49.901Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start...

Looking at the DFU data it shows

Downloading element to address = 0x90040000, size = 164832
Erase           [=========================] 100%       164832 bytes
Erase    done.
Download        [=========================] 100%       164832 bytes
Download done.
File downloaded successfully
Error during download get_status
make: *** [../libDaisy/core/Makefile:330: program-dfu] Error 74

Here are some details on the setup:

I am running the Daisy Bootloader
I have APP_TYPE = BOOT_QSPI in the makefile
I have the Daisy in the bootloader mode where i can be programmed via the DFU. (tap and release on reset button, then tap and release on boot button)
I then used the Visual Studio Code “F5” to start debugging.
The app builds and deploys as shown above.

Is there any way to not have the system fail the download if that error 74 is causing the issue?

Thanks,
Brett

BHAudio · June 3, 2023, 6:50pm

I did two more things:

First,
I wanted to retry the APP_TYPE = BOOT_NONE. I set the APP_TYPE in the makefile, and then reran the full F5 build while the Daisy Seed was in the Daisy Bootloader. All worked as expected, it even erased the Daisy Bootloader and started the debugger as expected.

Secondly,
I wanted to try the same with the APP_TYPE = BOOT_QSPI. I changed the setting in the makefile, rebuilt so that I could run “make program-boot”, I set the Daisy Seed to DFU mode via the buttons, and then did the F5 build.

Note: for this run I also updated the gdb to have the debug_level 4. Here is what is shown at the end of the log were a few “STLINK_SWD_AP_FAULT”.

Here is the full log:

Debug: 616 2558 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x90040000 4 166
Debug: 617 2558 stlink_usb.c:1100 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
Debug: 618 2558 gdb_server.c:383 gdb_log_incoming_packet(): [stm32h7x.cpu0] received packet: X900402a0,3de0:<binary-data-16-bytes>
Debug: 619 2559 gdb_server.c:1483 gdb_error(): Reporting -4 to GDB as generic error
Debug: 620 2559 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $E0E#ba
Debug: 621 2559 gdb_server.c:1672 gdb_write_memory_binary_packet(): addr: 0x900402a0, len: 0x00003de0
Debug: 622 2559 target.c:2410 target_write_buffer(): writing buffer of 15840 byte at 0x900402a0
Debug: 623 2559 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x900402a0 4 3960
Debug: 624 2559 stlink_usb.c:1100 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
[2023-06-03T18:36:45.855Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start.

Here is more of the log

Debug: 520 2345 hla_target.c:594 adapter_read_memory(): adapter_read_memory 0x5c00103c 4 1
Debug: 521 2345 command.c:155 script_debug(): command - expr (2048 & ~0) | 0x00000800
Warn : 522 2345 openocd.c:281 jim_expr_command(): DEPRECATED! (C:/Program Files/DaisyToolchain/bin/..//scripts/target/stm32h7x.cfg:234) use 'expr { (2048 & ~0) | 0x00000800 }' not 'expr (2048 & ~0) | 0x00000800'
Debug: 523 2345 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $O44455052454341544544212028433a2f50726f6772616d2046696c65732f4461697379546f6f6c636861696e2f62696e2f2e2e2f2f736372697074732f7461726765742f73746d33326837782e6366673a3233342920757365202765787072207b2028323034382026207e3029207c2030783030303030383030207d27206e6f742027657870722028323034382026207e3029207c2030783030303030383030270a#dd
Debug: 524 2346 command.c:155 script_debug(): command - stm32h7x.cpu0 mww 1543508028 2048
Debug: 525 2346 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x5c00103c 4 1
Debug: 526 2346 command.c:155 script_debug(): command - transport select
Debug: 527 2346 command.c:155 script_debug(): command - expr  [ string first "hla" $_TRANSPORT ] != -1 
Debug: 528 2347 command.c:155 script_debug(): command - target current
Debug: 529 2347 command.c:155 script_debug(): command - expr 0x5C001000 + 0x054
Warn : 530 2347 openocd.c:281 jim_expr_command(): DEPRECATED! (C:/Program Files/DaisyToolchain/bin/..//scripts/target/stm32h7x.cfg:248) use 'expr { 0x5C001000 + 0x054 }' not 'expr 0x5C001000 + 0x054'
Debug: 531 2347 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $O44455052454341544544212028433a2f50726f6772616d2046696c65732f4461697379546f6f6c636861696e2f62696e2f2e2e2f2f736372697074732f7461726765742f73746d33326837782e6366673a3234382920757365202765787072207b2030783543303031303030202b203078303534207d27206e6f742027657870722030783543303031303030202b203078303534270a#ae
Debug: 532 2348 command.c:155 script_debug(): command - stm32h7x.cpu0 mem2array value 32 1543508052 1
Warn : 533 2348 target.c:4435 target_mem2array(): DEPRECATED! use 'read_memory' not 'mem2array'
Debug: 534 2348 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $O4445505245434154454421207573652027726561645f6d656d6f727927206e6f7420276d656d326172726179270a#c6
Debug: 535 2348 hla_target.c:594 adapter_read_memory(): adapter_read_memory 0x5c001054 4 1
Debug: 536 2349 command.c:155 script_debug(): command - expr (786432 & ~0) | 0x000C0000
Warn : 537 2349 openocd.c:281 jim_expr_command(): DEPRECATED! (C:/Program Files/DaisyToolchain/bin/..//scripts/target/stm32h7x.cfg:234) use 'expr { (786432 & ~0) | 0x000C0000 }' not 'expr (786432 & ~0) | 0x000C0000'
Debug: 538 2349 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $O44455052454341544544212028433a2f50726f6772616d2046696c65732f4461697379546f6f6c636861696e2f62696e2f2e2e2f2f736372697074732f7461726765742f73746d33326837782e6366673a3233342920757365202765787072207b20283738363433322026207e3029207c2030783030304330303030207d27206e6f7420276578707220283738363433322026207e3029207c2030783030304330303030270a#81
Debug: 539 2349 command.c:155 script_debug(): command - stm32h7x.cpu0 mww 1543508052 786432
Debug: 540 2349 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x5c001054 4 1
Debug: 541 2350 command.c:155 script_debug(): command - stm32h7x.cpu0 invoke-event reset-assert-pre
Debug: 542 2350 command.c:155 script_debug(): command - transport select
Debug: 543 2350 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 544 2350 command.c:155 script_debug(): command - stm32h7x.cpu0 arp_reset assert 1
Debug: 545 2350 target.c:2199 target_free_all_working_areas_restore(): freeing all working areas
Debug: 546 2350 hla_target.c:336 hl_assert_reset(): hl_assert_reset
Debug: 547 2351 core.c:636 adapter_system_reset(): SRST line asserted
Debug: 548 2352 command.c:155 script_debug(): command - stm32h7x.cpu0 invoke-event reset-assert-post
Debug: 549 2352 command.c:155 script_debug(): command - stm32h7x.cpu0 invoke-event reset-deassert-pre
Debug: 550 2352 command.c:155 script_debug(): command - transport select
Debug: 551 2352 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 552 2352 command.c:155 script_debug(): command - stm32h7x.cpu0 arp_reset deassert 1
Debug: 553 2352 target.c:2199 target_free_all_working_areas_restore(): freeing all working areas
Debug: 554 2352 hla_target.c:395 hl_deassert_reset(): hl_deassert_reset
Debug: 555 2352 core.c:640 adapter_system_reset(): SRST line released
Debug: 556 2524 command.c:155 script_debug(): command - stm32h7x.cpu0 invoke-event reset-deassert-post
Debug: 557 2524 command.c:155 script_debug(): command - transport select
Debug: 558 2524 command.c:155 script_debug(): command - expr  [ string first "jtag" $_TRANSPORT ] != -1 
Debug: 559 2524 command.c:155 script_debug(): command - stm32h7x.cpu0 was_examined
Debug: 560 2524 command.c:155 script_debug(): command - stm32h7x.cpu0 arp_waitstate halted 1000
Debug: 561 2525 hla_target.c:594 adapter_read_memory(): adapter_read_memory 0xe000edf8 4 1
Debug: 562 2525 target.c:2628 target_read_u32(): address: 0xe000edf8, value: 0x00000000
Debug: 563 2526 armv7m.c:368 armv7m_read_core_reg(): read r0 value 0x00000000
Debug: 564 2526 armv7m.c:368 armv7m_read_core_reg(): read r1 value 0x00000000
Debug: 565 2527 armv7m.c:368 armv7m_read_core_reg(): read r2 value 0x00000000
Debug: 566 2527 armv7m.c:368 armv7m_read_core_reg(): read r3 value 0x00000000
Debug: 567 2527 armv7m.c:368 armv7m_read_core_reg(): read r4 value 0x00000000
Debug: 568 2528 armv7m.c:368 armv7m_read_core_reg(): read r5 value 0x00000000
Debug: 569 2528 armv7m.c:368 armv7m_read_core_reg(): read r6 value 0x00000000
Debug: 570 2529 armv7m.c:368 armv7m_read_core_reg(): read r7 value 0x00000000
Debug: 571 2529 armv7m.c:368 armv7m_read_core_reg(): read r8 value 0x00000000
Debug: 572 2529 armv7m.c:368 armv7m_read_core_reg(): read r9 value 0x00000000
Debug: 573 2530 armv7m.c:368 armv7m_read_core_reg(): read r10 value 0x00000000
Debug: 574 2530 armv7m.c:368 armv7m_read_core_reg(): read r11 value 0x00000000
Debug: 575 2530 armv7m.c:368 armv7m_read_core_reg(): read r12 value 0x00000000
Debug: 576 2531 armv7m.c:368 armv7m_read_core_reg(): read sp value 0x20020000
Debug: 577 2531 armv7m.c:368 armv7m_read_core_reg(): read lr value 0xffffffff
Debug: 578 2531 armv7m.c:368 armv7m_read_core_reg(): read pc value 0x0800174c
Debug: 579 2532 armv7m.c:368 armv7m_read_core_reg(): read xPSR value 0x01000000
Debug: 580 2532 armv7m.c:368 armv7m_read_core_reg(): read msp value 0x20020000
Debug: 581 2533 armv7m.c:368 armv7m_read_core_reg(): read psp value 0x00000000
Debug: 582 2533 armv7m.c:368 armv7m_read_core_reg(): read pmsk_bpri_fltmsk_ctrl value 0x00000000
Debug: 583 2534 armv7m.c:366 armv7m_read_core_reg(): read d0 value 0x0000000000000000
Debug: 584 2534 armv7m.c:366 armv7m_read_core_reg(): read d1 value 0x0000000000000000
Debug: 585 2535 armv7m.c:366 armv7m_read_core_reg(): read d2 value 0x0000000000000000
Debug: 586 2536 armv7m.c:366 armv7m_read_core_reg(): read d3 value 0x0000000000000000
Debug: 587 2536 armv7m.c:366 armv7m_read_core_reg(): read d4 value 0x0000000000000000
Debug: 588 2537 armv7m.c:366 armv7m_read_core_reg(): read d5 value 0x0000000000000000
Debug: 589 2538 armv7m.c:366 armv7m_read_core_reg(): read d6 value 0x0000000000000000
Debug: 590 2538 armv7m.c:366 armv7m_read_core_reg(): read d7 value 0xffffffff00000000
Debug: 591 2539 armv7m.c:366 armv7m_read_core_reg(): read d8 value 0x0000000000000000
Debug: 592 2540 armv7m.c:366 armv7m_read_core_reg(): read d9 value 0x0000000000000000
Debug: 593 2540 armv7m.c:366 armv7m_read_core_reg(): read d10 value 0x0000000000000000
Debug: 594 2541 armv7m.c:366 armv7m_read_core_reg(): read d11 value 0x0000000000000000
Debug: 595 2542 armv7m.c:366 armv7m_read_core_reg(): read d12 value 0x0000000000000000
Debug: 596 2542 armv7m.c:366 armv7m_read_core_reg(): read d13 value 0x0000000000000000
Debug: 597 2543 armv7m.c:366 armv7m_read_core_reg(): read d14 value 0x0000000000000000
Debug: 598 2543 armv7m.c:366 armv7m_read_core_reg(): read d15 value 0xffffffff00000000
Debug: 599 2543 armv7m.c:368 armv7m_read_core_reg(): read fpscr value 0x00000000
Debug: 600 2544 hla_target.c:278 adapter_debug_entry(): entered debug state in core mode: Thread at PC 0x0800174c, target->state: halted
Debug: 601 2544 target.c:1843 target_call_event_callbacks(): target event 0 (gdb-halt) for core stm32h7x.cpu0
Debug: 602 2544 target.c:1843 target_call_event_callbacks(): target event 1 (halted) for core stm32h7x.cpu0
User : 603 2544 armv7m.c:729 armv7m_arch_state(): target halted due to debug-request, current mode: Thread 
xPSR: 0x01000000 pc: 0x0800174c msp: 0x20020000
Debug: 604 2544 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $O7461726765742068616c7465642064756520746f2064656275672d726571756573742c2063757272656e74206d6f64653a20546872656164200a785053523a20307830313030303030302070633a2030783038303031373463206d73703a20307832303032303030300a#b2
Debug: 605 2544 target.c:1843 target_call_event_callbacks(): target event 8 (gdb-end) for core stm32h7x.cpu0
Debug: 606 2544 hla_target.c:323 adapter_poll(): halted: PC: 0x0800174c
Debug: 607 2544 command.c:155 script_debug(): command - stm32h7x.cpu0 curstate
Debug: 608 2545 command.c:155 script_debug(): command - stm32h7x.cpu0 invoke-event reset-end
Debug: 609 2545 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $OK#9a
Debug: 610 2557 gdb_server.c:390 gdb_log_incoming_packet(): [stm32h7x.cpu0] received packet: X90040000,0:
Debug: 611 2557 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $OK#9a
Debug: 612 2557 gdb_server.c:390 gdb_log_incoming_packet(): [stm32h7x.cpu0] received packet: X90040000,298:
Debug: 613 2558 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $OK#9a
Debug: 614 2558 gdb_server.c:1672 gdb_write_memory_binary_packet(): addr: 0x90040000, len: 0x00000298
Debug: 615 2558 target.c:2410 target_write_buffer(): writing buffer of 664 byte at 0x90040000
Debug: 616 2558 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x90040000 4 166
Debug: 617 2558 stlink_usb.c:1100 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
Debug: 618 2558 gdb_server.c:383 gdb_log_incoming_packet(): [stm32h7x.cpu0] received packet: X900402a0,3de0:<binary-data-16-bytes>
Debug: 619 2559 gdb_server.c:1483 gdb_error(): Reporting -4 to GDB as generic error
Debug: 620 2559 gdb_server.c:406 gdb_log_outgoing_packet(): [stm32h7x.cpu0] sending packet: $E0E#ba
Debug: 621 2559 gdb_server.c:1672 gdb_write_memory_binary_packet(): addr: 0x900402a0, len: 0x00003de0
Debug: 622 2559 target.c:2410 target_write_buffer(): writing buffer of 15840 byte at 0x900402a0
Debug: 623 2559 hla_target.c:609 adapter_write_memory(): adapter_write_memory 0x900402a0 4 3960
Debug: 624 2559 stlink_usb.c:1100 stlink_usb_error_check(): STLINK_SWD_AP_FAULT
[2023-06-03T18:36:45.855Z] SERVER CONSOLE DEBUG: onBackendConnect: gdb-server session closed
GDB server session ended. This terminal will be reused, waiting for next session to start.

Please let me know if I can get you any more data here to help look into this more closely.

Thanks,
Brett

Corvus_Prudens · June 5, 2023, 8:53pm

It sounds like you may not have flashed the program before starting the debug process. Currently, debugging with the bootloader is a little tricky because openocd isn’t set up to flash the program directly. When using the bootloader, you’ll have to flash the program first, then start debugging. If the debug script includes any pre-launch tasks, you’ll probably need to remove those. I don’t think we have a bootloader debug target set up by default.

BHAudio · June 6, 2023, 12:11am

@Corvus_Prudens ,

I see - any samples / examples I can look to help build this?

Thanks,
Brett

Corvus_Prudens · June 6, 2023, 6:55pm

I don’t think there’s anything ready-made lying around at the moment, but there are some discussions here and there about how to work with it. Is there anything in particular you’re not sure about?

BHAudio · June 7, 2023, 1:07am

@Corvus_Prudens ,

Thank you for asking - here is where I’m stuck.

I don’t know how to connect the debugger after the code is running when in VSCode.

Here is what I have done so far:

in the makefile i set APP_TYPE = BOOT_QSPI
I build the app
I ran the make program-boot (from the VS Code bash)
I put the Daisy bootloader mode (press and release reset, press and release boot). I get the “breathing” LED indidcating i’m in the Daisy bootloader that is waiting for a DFU connect.
I ran the make program-dfu (from the VS Code bash)
The code loads properly

It looks like the app should be loaded and running.

Two things:

At this point, how do I connect the debugger when in VS.Code to start my debugging session?
Is there a way to still build, deploy with dfu, and start to debug from VS Code with a new task in the task.json and/or launch.json?

Note: My goal is to move to the use of my external USB device to laod the .bin into the system and run from SRAM. This above is just the startig point to see if I can get that running. Although I did read somewhere that I don’t think OpenOCD can debug when things are running in QSPI, but I don’t know for sure if that is correct or not.

Thank you for your time and help here,
Brett

BHAudio · June 8, 2023, 3:20am

Hello @Corvus_Prudens , and @TallMike ,

I have an update but still a couple of issues
After looking at the SD Card for the QSPI flash I realized that yes, the flash was successful as the bootloader left a text file behind saying the update was successful.

Issue 1: The device did not seem to reboot after the upload when powered off the device and turned it back on.
Issue 2: The bin file was never deleted from the card causing
Issue 3: The system would not load and use the SD Card where I store and use audio files and save / load patterns… the device just hung and did nothing.

I decided to try the APP_TYPE = SRAM and load from the SD Card. I rebuilt everything and here is what happened:

Issue 1: The device never seemed to boot up and there was nothing on the SD Card from the boot loader.

Two things happend that I did not expect: expection:

That the .bin file would be left and/or tried to be reloaded again when in QSPI mode and loading from the SD Card.
That if I tried to run from the SD Card when in the APP_TYPE = SRAM that the device never seemed to boot.
I’m not sure if that is due to the fact my code is using the SD Card or something else. Note: I am assuming my code is not running because it never seems to start.

I am a step closer by being able to upload to QSPI via the SD Card, but I am not able to keep running / using the SD Card after the boot happens and I try to access the SD Card.

Any thoughts on how to manage this issue?

Thanks,
Brett

BHAudio · June 10, 2023, 10:35pm

Hello all,

I have things running now with the Daisy Bootloader, the DFU tool, and both SRAM and QSPI.

A few notes to others who may come across this to hopefully help you out:

Daisy Bootloader on reset needs in press and let go ‘reset’ and then press and let go ‘boot’ to have the bootloader stay in the DFU mode. I didn’t quite have that down the first time I was trying this. (from this post)
I updated my launch.json in two ways:
– Changed “preLaunchTask” to be “build_and_program_dfu”, that way I could use the F5 in VS Code.
– Modified openOCDLaunchCommands to add in the line: “gdb_breakpoint_override hard” as the last line in the section.
I plan to add in the use of System::ResetToBootloader in my code for faster reboot / re-programming time.

Hope that helps others down the line.

Thanks,
Brett

Corvus_Prudens · June 12, 2023, 7:53pm

Awesome! I’m so glad you got that working.

BHAudio · June 13, 2023, 12:37am

@Corvus_Prudens ,

I am thinking about doing a little more of a writeup up / walkthrough on it because the info seems to be in a few places. That way it could be editued / updated but in a place formore people to try it out.

Brett