Search Results

In the Rowley guide for externally built application, the wizard points "exactly" to the .elf in question... Can't seem to do this in SES!

.

So, if I "modify" the project type from Externally Built Executable to >> Excutable, debug works which proves my paths etc to the elf file were correct all along. However, I lose the ability to call the make file to build etc. I then changed it back to Externally Built Executable to try something out then changed it to Excutable and now it can't find the elf file again even though the projects setting are the same to when it to worked temporarily.. This feature is broken....

This is the layout and settings that I have. $(ProjectDir)=C:/Firmware/MotorisedFaders/MyBranch/motor-firmware Inside of ProjectDir is another folder called MQ500MotorFader which is where the elf file MQ500MotorFader.elf is generated when the make file is called. So, SES has to debug >> C:/Firmware/MotorisedFaders/MyBranch/motor-firmware/MQ500MotorFader/MQ500MotorFader.elf Options>Debug>Working Directory = $(ProjectDir)/MQ500MotorFader Options>Debug>Command Arguments = MQ500MotorFader.elf What m…

I already made the project name the same as the ProjectName.elf so the Debug->Debugger->Command Arguments >> $(ProjectName)$(EXE) is already correct. The linking that's done by the make file is too complicated for me to try to get SES to do the build/linking on its own hence best stick to just calling the make file as that works.. I don't really want to use ozone as I'm used to Rowley Crossworks (not much different to SES) as I used that for 7+ years at my old job. If I get SES to debug an exter…

To highlight the problem better I did the following :- step 1) I used the project wizard to create a new Hello World program and tested that is ran with debugger. (worked just fine) step 2) I then created another project side by side but selected externally built executable (using same processor as above) step 3) I then copied the "Output\Debug\Exe\mydebug.elf" that was generated from step 1) to the root of the second project folder. ste4 4) I then experimented with the project settings to try a…

I have managed to instruct SES to build my elf file by calling a makefile (make all) Now, when I select debug/Go, I get a error saying No executable to debug. How do I instruct SES to point to my .elf file so that it can be debugged? I have attached a screenshot of the setting that I think should have worked but didn't. I have made sure that the elf file is in the SAME directory as the .emProject project

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

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

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 debu…

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…

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 HardFa…

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?

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 wo…

It will take me a little while to strip out unnecessary/sensitive code. I'll get back to you.

How do I make the "-lc" linker option work? I added "-lc" (with the quotes and I tried without) to the "Additional Linker options" section of the Linker settings tab. Linker is set to GNU (not Segger) I also installed the additional C++ libs in the package manager (not sure if this was necessary or not..) IDE version 7.10a Reason I'm trying to set this is to bypass this error >> undefined reference to `__libc_init_array' to which I have never been able to find a satisfactory fix (unless I use an…

Ahhh, Many thanks Lucas

Hi, ok, I've attached the project. Regards

Ok, did some more digging. Turns out libc.a is in location C:\Program Files\SEGGER\SEGGER Embedded Studio for ARM 7.10\lib So, simply having Settings->Library Include Standard Libraries set to YES should be sufficient but still get same error. I also made sure the path was set up correctly which is as follows :- $(StudioLibDir:$(StudioDir)/lib) for Settings->Library Include Standard Libraries Directory Lastly, as a test, I treated libc.a as if it were a .c file and added it to my project but tha…