Is it possible to use Eclipse with CodeSourcery G++ Lite for simulation-type debugging? I'm sure my terminology isn't correct, let me explain.... I'm already able to connect to my Luminary 6965 eval board using OpenOCD and debug that way. However, I'm wondering if I can debug code without the eval board, by using simulation only. For right now, I'm only interested in core debugging; peripherals would be nice but not required at this time. Also, if this can be done, is a good way provided to time execution? The simulation provided in Microchip MPLAB was very good, and I've become spoiled.
qemu offers an emulator Cortex-M3 even explicitly for the LM3S6965 according to http://bellard.org/qemu/qemu-doc.html#SEC63 . qemu can listen as a gdb-server so the chain Eclipse <-> gdb (to "remote") <-> gdb-server(qemu) <-> simulator(qemu) should be possible ("should" since I have not tested this myself).
Martin Thomas wrote: > qemu offers an emulator Cortex-M3 even explicitly for the LM3S6965 > according to http://bellard.org/qemu/qemu-doc.html#SEC63 . qemu can > listen as a gdb-server so the chain Eclipse <-> gdb (to "remote") <-> > gdb-server(qemu) <-> simulator(qemu) should be possible ("should" since > I have not tested this myself). This looks interesting, but is thoroughly confusing me. The "readme" says to run qemu-win.bat, which launches Linux within Windows. But I can't figure out what the purpose of that is. I'm not finding any files in this filesystem that look different than the normal Linux filesystem. http://bellard.org/qemu/qemu-doc.html#SEC63 says in order use gdb, this following command should be issued: qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img Except, it doesn't work because it can't open the disk image, and that file doesn't exist. On the same webpage, it states "Use the executable `qemu-system-arm' to simulate a ARM machine." The problem is, it seems like the executable insists on a disk image of some sort, when I'm only trying to simulate a microcontroller. Uggghhhh. Wouldn't arm-none-eabi-gdb work as a debugger with Eclipse? This is my guess, but I'm a little new at this aspect.
> > Except, it doesn't work because it can't open the disk image, and that > file doesn't exist. > > On the same webpage, it states "Use the executable `qemu-system-arm' to > simulate a ARM machine." The problem is, it seems like the executable > insists on a disk image of some sort, when I'm only trying to simulate a > microcontroller. Uggghhhh. > > Wouldn't arm-none-eabi-gdb work as a debugger with Eclipse? This is my > guess, but I'm a little new at this aspect. to run a compiled app under qemu use the following: qemu-system-arm.exe -S -s -p 2000 -L . -kernel hello.elf -M lm3s811evb This will stop the app at reset and wait for a gdb connection on port 2000 normally you could use the gdb simulator - but at the moment it does not simulate atmv7 instructions very well. Cheers Spen
Spencer Oliver wrote: >> > > > to run a compiled app under qemu use the following: > qemu-system-arm.exe -S -s -p 2000 -L . -kernel hello.elf -M lm3s811evb > > This will stop the app at reset and wait for a gdb connection on port > 2000 > > normally you could use the gdb simulator - but at the moment it does not > simulate atmv7 instructions very well. > > Cheers > Spen Thank you for your reply. I was able to execute the command you gave. I'm still having a problem maybe you or someone else can provide some input on. I start arm-none-eabi-gdb with "-d" and some source directories, so far so good. Then I issue these commands within gdb: (gdb) file hello.elf Reading symbols from C:\(long path)\hello.ef...done. (gdb) display/i $pc (gdb) target extended-remote localhost:2000 Remote debugging using localhost:2000 0x00000000 in g_pfnVectors () 1: x/i $pc 0x0 <g_pfnVectors>: andcs r0, r0, r8, lsl #14 (gdb) step Single stepping until exit from function g_pfnVectors, which has no line number information. IntDefaultHandler () at startup.c:208 208 { 1: x/i $pc 0x9988 <IntDefaultHandler>: b.n 0x9988 <IntDefaultHandler> (gdb) step IntDefaultHandler () at startup.c:208 208 { 1: x/i $pc 0x9988 <IntDefaultHandler>: b.n 0x9988 <IntDefaultHandler> Quit (expect signal SIGINT when the program is resumed) (gdb) bt #0 IntDefaultHandler () at startup.c:208 #1 0xfffffff8 in ?? () (gdb) info frame Stack level 0, frame at 0xffffffe0: pc = 0x9988 in IntDefaultHandler (startup.c:208); saved pc 0xfffffff8 called by frame at 0x0 source language c. Arglist at 0xffffffe0, args: Locals at 0xffffffe0, Previous frame's sp is 0xffffffe0 (gdb) I'm at a loss because this file, when programmed on an eval board, runs fine. It appears that at the reset vector, 0x0, it tried executing "andcs" which isn't even a valid cortex-m3 instruction. It throws a Usage Exception, and branches to that handler, IntDefaultHandler, which is just a while(1); loop. What I don't understand: 1. Why does it work on the eval board 2. Why is there garbage at address 0x0 when I call main() in the reset vector 3. What is the deal with the references to addresses near 0xffffffff On a side note, any idea how to get a nice comprehensive assembly listing from gcc? -S causes all sorts of errors.
> > Thank you for your reply. I was able to execute the command you gave. > I'm still having a problem maybe you or someone else can provide some > input on. > > I start arm-none-eabi-gdb with "-d" and some source directories, so far > so good. Then I issue these commands within gdb: > > > (gdb) file hello.elf > Reading symbols from C:\(long path)\hello.ef...done. > (gdb) display/i $pc > (gdb) target extended-remote localhost:2000 > Remote debugging using localhost:2000 > 0x00000000 in g_pfnVectors () > 1: x/i $pc > 0x0 <g_pfnVectors>: andcs r0, r0, r8, lsl #14 > (gdb) step > Single stepping until exit from function g_pfnVectors, > which has no line number information. > IntDefaultHandler () at startup.c:208 > 208 { > 1: x/i $pc > 0x9988 <IntDefaultHandler>: b.n 0x9988 <IntDefaultHandler> > (gdb) step > IntDefaultHandler () at startup.c:208 > 208 { > 1: x/i $pc > 0x9988 <IntDefaultHandler>: b.n 0x9988 <IntDefaultHandler> > Quit (expect signal SIGINT when the program is resumed) > (gdb) bt > #0 IntDefaultHandler () at startup.c:208 > #1 0xfffffff8 in ?? () > (gdb) info frame > Stack level 0, frame at 0xffffffe0: > pc = 0x9988 in IntDefaultHandler (startup.c:208); saved pc 0xfffffff8 > called by frame at 0x0 > source language c. > Arglist at 0xffffffe0, args: > Locals at 0xffffffe0, Previous frame's sp is 0xffffffe0 > (gdb) > > > I'm at a loss because this file, when programmed on an eval board, runs > fine. It appears that at the reset vector, 0x0, it tried executing > "andcs" which isn't even a valid cortex-m3 instruction. It throws a > Usage Exception, and branches to that handler, IntDefaultHandler, which > is just a while(1); loop. > > What I don't understand: > 1. Why does it work on the eval board > 2. Why is there garbage at address 0x0 when I call main() in the reset > vector > 3. What is the deal with the references to addresses near 0xffffffff > > On a side note, any idea how to get a nice comprehensive assembly > listing from gcc? -S causes all sorts of errors. just for testing, change to target remote rather than extended-remote. one point i would make is check you use the following in your linker script: ENTRY(ResetISR) /* change to suit your reset vector */ gdb sometimes get confused with the armv7(cortex_m3) as the reset vector is not at 0 like most arm cores. A lot depends on your version of gdb, mainline does not correctly support v7 whereas codesourcery version does if you have sent the correct target.xml file from your gdbserver. remember qemu does not simulated everything, it is work in progress. Cheers Spen
Spencer Oliver wrote: >> >> listing from gcc? -S causes all sorts of errors. > > just for testing, change to target remote rather than extended-remote. > one point i would make is check you use the following in your linker > script: > ENTRY(ResetISR) /* change to suit your reset vector */ > > gdb sometimes get confused with the armv7(cortex_m3) as the reset vector > is not at 0 like most arm cores. > > A lot depends on your version of gdb, mainline does not correctly > support v7 whereas codesourcery version does if you have sent the > correct target.xml file from your gdbserver. > > remember qemu does not simulated everything, it is work in progress. > > Cheers > Spen Thanks again. I'll look into this.
Watch this topic
Disable multi-page viewPlease log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
Log in with Google account
No account? Register here.