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?

Thanks for that. I'll give that a try as well.
In ozone, will I be able to debug the .elf and have it integrate back to the source code for single stepping/breakpoints etc?

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......

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.

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....

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.

To fix the original problem I set the project name within the solution to match the filename of the .elf file