RTEMS, CodeWarrior, and the PowerPC
Oyake, Amalaye (398F)
amalaye.oyake at jpl.nasa.gov
Thu Mar 31 20:08:02 UTC 2016
Please repost this once again. But include
1) Your BUILD ENVIRONMENT + VERSION
2) Your HOST ENVIRONMENT + VERSION
3) What board you are compiling on
4) Your JTAG Debugger information
This way it can be migrated to a wiki.
* Amalaye Oyake *
* Instrument Product Software Development Group */\ *
* Jet Propulsion Laboratory, Pasadena *|| *
* CA 91109 818.393.7168 work 626.399.1707 cell /||\ *
From: users <users-bounces at rtems.org<mailto:users-bounces at rtems.org>> on behalf of Travis Wheatley <travis.wheatley at fireflyspace.com<mailto:travis.wheatley at fireflyspace.com>>
Date: Thursday, March 31, 2016 at 1:04 PM
To: "users at rtems.org<mailto:users at rtems.org>" <users at rtems.org<mailto:users at rtems.org>>
Subject: Re: RTEMS, CodeWarrior, and the PowerPC
Ok, got it working. Posting here for future reference.
Turns out this isn't all that difficult.
Firstly, one must set up an "attach" launcher in CodeWarrior when you create your project. Then under "Debug Configurations" modify that attach launcher thusly:
1) Under the "Source" tab of the debug configurations page add the .../development/rtems/git folder and be sure to click the "search sub-directories" check box
2) Under the "Trace and Profile" click the "User Code" radio button and put in your start address (0x4000 in the case of hello.exe).
3) Under the "Main" make sure that debug session type is set to attach. Open the C/C++ application item and use the browse button to point to the executable (in my case .../development/rtems/build-powerpc/powerpc-rtems4.12/c/qoriq_t2080rdb/testsuites/samples/hello/hello.exe. Under Build make sure the disable auto build radio button is selected and under Target make sure your Connection is set properly and your target board is selected.
Now... time to fly it.
Boot u-boot and hit enter to interrupt the auto boot process at the u-boot console and load the hello.bin file (created from hello.exe using "powerpc-rtems4.12-objcopy -Obinary hello.exe hello.bin") at the entry address (0x4000).
Back in CodeWarrior, fire up the debugger and it will attach.
Suspend the processor and in the disassembly window take a look at your entry point (0x4000). I like to set a breakpoint there just because.
Now resume and type "go <your entry point>" at the u-boot command prompt. You should immediately hit the breakpoint you set and you should see the start.S source in your debug window. From this point you are basically there. The debugger is then able to associate source files such as bspstart.c with the executable you are running.
On Mar 31, 2016, at 1:38 PM, Travis Wheatley wrote:
On Mar 30, 2016, at 10:39 PM, Chris Johns wrote:
So... can anyone point me to the "Here's how you do source level RTEMS debug from an ide" documentation?
I can only guess from a quick search Codewarrior is Eclipse based. Is this true?
Yes, Codewarrior is Eclipse based.
Does the debugger behind the IDE GUI have a command line interface?
Not that I am aware of, but I could be mistaken.
Does the Codewarrior debugger use ELF format files and so DWARF?
It is my understanding that Codewarrior understands ELF/DWARF.
If it does you are a long way to being able to support debugging.
If ELF is supported does the debugger understand the level of DWARF gcc generates with the 4.12 tools? There are a number of options to tweak the debug info gcc generates.
Doing a search for DWARF in the CodeWarrior docs only pulls up some flags that one can send to the compiler to change the level of DWARF generated by the compiler the IDE uses but doesn't really say anything about what level the debug tools actually support.
I suggest you try an existing sample exe and open it in the debugger. A hack is to create a bare application in the IDE and replace the executable Codewarrior creates with hello.exe.
An interesting test, but not sure how it furthers the cause. One problem here is that I am running u-boot on the target board to do basic initialization with the intent of eventually treating my RTEMS application as a bootable image. So... I think that I have to boot the platform and then "attach" to it before running bootm or jumping to a location that contains my target code. I believe I can ignore CW whining about having a null target, do the download manually, set a breakpoint at the entry point of my code, then execute. Assuming that is correct I still don't know how to tell CW to use the hello.ralf file as its magic decoder ring nor how to point to the source since what I really want to debug is exactly where the exception that sends me to the kernel panic handler in bspstart.c occurred.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the users