[SOLVED] No executable to debug

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • [SOLVED] No executable to debug

    I have a project that is built using a make file. This results in a .elf file being generated. This elf file runs and debugs using Eclipse/GDB (although its a horrible debug experience hence why I want to use SES)
    I'm trying to debug the .elf using SES but no matter what I try, I get "No executable to debug".

    I ended up with this setting >>>> Option->Code->build->Executable File name->$(ProjectDir)/Mydebugfile.elf

    I'm using SES version V7.10a


    Any ideas on what else I need to do to get this to work?
  • Ok, just gave Ozone a try and my target hit a hardfault immediately upon clicking the attach button. (the same .elf works through Ecplise <<< I shudder every time I type or say the E word)
    Ozone also complained I needed a valid licence but did allow me to use it for evaluation purposes.

    j-link device is a j-link Base (connection option = SWD, speed 4MHz)
    target processor:- ATSAME70Q21B (I had to select ATSAME70Q21A as there was no 'B' version)



    error message window :-

    The target stopped in HardFault exception state.

    Reason: A fault with configurable priority has been escalated to a HardFault exception at 0x00000000.

    For more information about analyzing faults on Cortex-M, refer to:
    wiki.segger.com/Cortex-M_Fault.



    console output:-

    CoreSight components:
    ROMTbl[0] @ E00FD000
    [0][0]: E00FE000 CID B105100D PID 000BB4C8 ROM Table
    ROMTbl[1] @ E00FE000
    [1][0]: E00FF000 CID B105100D PID 000BB4C7 ROM Table
    ROMTbl[2] @ E00FF000
    [2][0]: E000E000 CID B105E00D PID 000BB00C SCS-M7
    [2][1]: E0001000 CID B105E00D PID 000BB002 DWT
    [2][2]: E0002000 CID B105E00D PID 000BB00E FPB-M7
    [2][3]: E0000000 CID B105E00D PID 000BB001 ITM
    [1][1]: E0041000 CID B105900D PID 001BB975 ETM-M7
    [0][1]: E0040000 CID B105900D PID 000BB9A9 TPIU-M7
    I-Cache L1: 16 KB, 256 Sets, 32 Bytes/Line, 2-Way
    D-Cache L1: 16 KB, 128 Sets, 32 Bytes/Line, 4-Way
    Connected to target device.
    Reset: Halt core after reset via DEMCR.VC_CORERESET.
    Reset: Reset device via AIRCR.SYSRESETREQ.
    Elf.GetBaseAddr(); // returns 0x400000
    Target.ReadU32 (0x00400000); // returns 0x4, data is 0x464C457F
    Target.SetReg ("SP", 0x464C457F);
    Elf.GetEntryPointPC(); // returns 0x47BC58
    Target.SetReg ("PC", 0x47BC58);
    J-Link: Flash download: Bank 0 @ 0x00400000: Skipped. Contents already match
    Elf.GetBaseAddr(); // returns 0x400000
    Target.ReadU32 (0x00400000); // returns 0x4, data is 0x464C457F
    Target.SetReg ("SP", 0x464C457F);
    Elf.GetEntryPointPC(); // returns 0x47BC58
    Target.SetReg ("PC", 0x47BC58);
    T-bit of XPSR is 0 but should be 1. Changed to 1.
  • I know I'm going a bit off topic with Ozone but I'm pretty sure that Ozone is doing a full chip erase when its flashing the .elf which is trampling the bootloader which resides at the default boot location in flash.
    I've noticed that if there is no code at the default boot address, the processor hangs/hardfaults which prevents the jlink from connecting. (I could be totally wrong....)

    MEMORY
    {
    rom_boot_vectors (rx) : ORIGIN = 0x00400000, LENGTH = 0x00000200 /* rom boot vectors, 512 */
    rom_product_conf (rx): ORIGIN = 0x00400200, LENGTH = 0x00000200 /* rom product config, 512 */
    rom_boot_conf (rx) : ORIGIN = 0x00400400, LENGTH = 0x00000200 /* rom boot config, 512 */
    rom_boot (rx): ORIGIN = 0x00400600, LENGTH = 0x0003fa00 /* rom boot, 260608 */
    rom_app (rx) : ORIGIN = 0x00440000, LENGTH = 0x0013FE00 /* rom application, 1310208 */
    rom_app_fw_info (rx) : ORIGIN = 0x0057fe00, LENGTH = 0x00000200 /* rom application firmware info, 512 */
    rom_app_config (rx) : ORIGIN = 0x00580000, LENGTH = 0x00080000 /* rom application config, 524288 */
    ram (rwx) : ORIGIN = 0x20400000, LENGTH = 0x0005ee00 /* ram, 388608 */
    ram_shared (rwx): ORIGIN = 0x2045ee00, LENGTH = 0x00000200 /* ram, 512 bytes (noload and shared between bootloader and main app) */
    ram_nocache (rwx) : ORIGIN = 0x2045f000, LENGTH = 0x00001000 /* ram, 4096 (gmac_dcpt_array) */
    }


    Not sure how I can get around this......

    The post was edited 1 time, last by nibbly78 ().

  • Hello,

    Thank you for your inquiry.

    A guide on how to use an external gnu toolchain with Embedded Studio is explained here:
    wiki.segger.com/Use_an_externa…hain_with_Embedded_Studio

    Regarding Ozone. You need to make sure you supply Ozone with the information that your Eclipse also has.
    Currently you tell it only "here is an elf file and this target device". So Ozone has not information about the bootloader if it is not part of the elf file.

    Depending on what you are planning to do with the bootloader you have several options:
    wiki.segger.com/Debug_Bootload…ion_in_same_Ozone_project

    wiki.segger.com/Debug_on_a_Target_with_Bootloader


    Generally J-Link will only erase the sectors that are part of the elf image and not a full chip erase.
    So should you be placing your bootloader and application in an overlapping section it is possible that part of the bootloader is erased.
    In that case either make sure to respect the Flash sector boundaries in your application placement or set the read modify write threshold of J-Link accordignly:
    wiki.segger.com/Read-Modify-Write_Flash


    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • Hi Nino,
    Eclipse does not know about the bootloader either...
    Eclipse is settup to only call "make clean" and "make app_debug" (so no access to compiler/linker etc to my knowledge)
    the .elf that is generated by the make command is the EXACT .elf file that I used for debugging under eclipse & Ozone.

    Once I try to debug with Ozone (which fails) if I then go back to Eclise, that fails too. Only way to recover is to re-flash a bootloader (or any dummy app with a while (1) loop)
    Once it's up and debugging in eclise, at no point is my bootloader erased. I then try to debug with Ozone, which fails again and I note that bootloader is wiped.
  • nibbly78 wrote:

    Eclipse does not know about the bootloader either...

    Eclipse is settup to only call "make clean" and "make app_debug" (so no access to compiler/linker etc to my knowledge)
    This is not related.
    "Make clean" only affects the sources and the build, not the target.
    And "make_app_debug" makes the target application using the "Debug" project settings - whatever they are.
    As a side note, one can easily make the "Debug" and "Release" project settings identical ...

    To your bootloader - I hope it is not located in a sector your application uses as well.

    A sector is the smallest possible part of the Flash that can be erased/programmed.
    Unless you write the Bootloader in such a way that it can relocate itself to RAM and re-flash itself, BL and application cannot use the same same sector.
    Usually, a second-stage bootloader uses the default start address of a Flash-based application for a given MCU.
    This means you must change the startup file, vector table location and linker settings for every application that is supposed to use your bootloader.


    > Ok, just gave Ozone a try and my target hit a hardfault immediately upon clicking the attach button. (the same .elf works through Ecplise <<< I shudder every time I type or say the E word)

    This sounds like there is such a mismatch between BL and application.
  • I'm not sure how this can be a mismatch between BL and application.
    Like I said, I can debug the .elf with Eclipse and the bootloader remains intact so there is no mismatch (unless I'm mistaken)
    I attempt to debug the same .elf file with SES and get a hardfault and the bootloader is now gone too....
  • Which sounds more like a problem with the debugger settings.
    Perhaps your project contains a "mass erase" setting for the flashing process, or a script the toolchain/debugger uses.

    By the way, are you sure the bootloader and the application are not located in the same sector ?
  • What project? Ozone just opens and uses the .elf file. I didn't change any settings, so I guess it uses default jlink settings. (I did have a look at settings but there is not not change)

    Anyway, I'm going to give up on Ozone and create another thread as this one has gone off topic a bit..

    Thanks for your help.
  • I would still check the documentation/tutorials for Ozone, it needs to derive information about Flash sector locations and sizes of the target MCU from somewhere. And the flashing modus, depending on the ELF contents.

    I use the debugger integrated in ES, assuming it is the same "core" as Ozone.
    Only here it is (supposedly) fed from the ES project settings.

    By the way, I also had a strange problem recently, were I just did not get the SysTick interrupt to run.
    It turned out the vector file and linker setting were for the wrong MCU subtype, with slightly different vector table and memory sizes.
    In the end I re-created the project, added all my sources again, and the problem was gone.