I am a new member of this list, so forgive me if it was asked 100 times
before. I try to debug my Atmega128 project. So far, I made it working with the gcc toolchain, I successfully set up a gdb server. However, I don't know how to monitor the internals of my device. I'd like to read the following things: * IO block of the device, in particular the SP register * The registers r0...r31 * RAM content. Memory dump, and variable watch. I couldn't find any in depth tutorial. Any help appreciated. thank you, Levente -- Levente Kovacs http://levente.logonex.eu _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
First off, are you working on a Linux machine? (i.e. why are you using avr-gdb?) > -----Original Message----- > From: avr-gcc-list-bounces+eric.weddington=[hidden email] > [mailto:avr-gcc-list-bounces+eric.weddington=[hidden email]] On > Behalf Of Levente Kovacs > Sent: Friday, May 20, 2011 1:58 PM > To: [hidden email] > Subject: [avr-gcc-list] avr-gdb use > > I am a new member of this list, so forgive me if it was asked 100 times > before. > > I try to debug my Atmega128 project. So far, I made it working with the > gcc > toolchain, I successfully set up a gdb server. > > However, I don't know how to monitor the internals of my device. > > I'd like to read the following things: > > * IO block of the device, in particular the SP register > > * The registers r0...r31 > > * RAM content. Memory dump, and variable watch. > > I couldn't find any in depth tutorial. > > > Any help appreciated. > > thank you, > Levente > > > -- > Levente Kovacs > http://levente.logonex.eu > > > > _______________________________________________ > AVR-GCC-list mailing list > [hidden email] > https://lists.nongnu.org/mailman/listinfo/avr-gcc-list _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
On Fri, 20 May 2011 15:13:35 -0600
"Weddington, Eric" <[hidden email]> wrote: > First off, are you working on a Linux machine? (i.e. why are you > using avr-gdb?) yes, I'm using Debian Linux. Ummm... I thought it is the part of the toolchain. Shell I use normal gdb? Levente -- Levente Kovacs http://levente.logonex.eu _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
In reply to this post by Kovacs Levente-2
Levente Kovacs <[hidden email]> wrote:
> I'd like to read the following things: > > * IO block of the device There's currently no symbolic method for that (ideas what/how to add the respective debugging information to the symbol table are welcome), so you have to examine them manually, like: x/bx 0x800039 print (char *)0x800039 to read back the value of the PINA register (SRAM memory address 0x39 + 0x800000 offset to indicate SRAM rather than flash ROM). > in particular the SP register The stack pointer and PC are special, in that GDB always reads those back from the target when stopping, so you can access it as print $SP > * The registers r0...r31 info reg print $r0 > * RAM content. Memory dump, x/32bx 0x800000 (SRAM) x/32bx 0 (flash ROM) > and variable watch. What is "watch" in your opinion? If you're following the GDB terminology, it means to stop the program whenever the value of some memory location changes. This is done with the "watch" command, however hardware watchpoint support in the AVR JTAG ICE doesn't allow you to watch all memory ranges. (*) It's always possible to watch a byte address, but for larger ranges, the address range must be expressable as baseaddress + mask, where the mask's digits at baseaddress must be 0. Since the AVR architecture itself doesn't require memory alignment, the compiler would normally not arrange that for you. If you think of "watch" in AVR Studio's terminology, this is equivalent to GDB's "display" command. Normally, you'd just use the "print" command though, which accepts arbitrary C language expressions, including access to all variables that are in scope for the currently visited stackframe(**), and including C typecast access to arbitrary memory locations. So a print statement like this one is completely possible in GDB: print *(struct cdata_priv *)(listptr->data) (*) Software watchpoints, while available, are terribly slow and thus impractical. They require the debugger to single-step the application, and manually examine the contents at the watched memory range after each step. (**) Unlike AVR Studio, you can walk stackframes up and down, so different frame's variable come in and get out of scope. > I couldn't find any in depth tutorial. I don't believe you that. Except for the 0x800000 SRAM address offset, and the IO register access through memory addresses, all of the above is pretty generic GDB knowledge which is completely independent of the target architecture. The very same commands would be used to debug a native application on your Linux host. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
On Sun, 22 May 2011 22:20:17 +0200 (MET DST)
[hidden email] (Joerg Wunsch) wrote: > There's currently no symbolic method for that (ideas what/how to add > the respective debugging information to the symbol table are welcome), Well, I'd add a table of the addresses, and you could use the syntax like this: x/bx __PORTA or something like that. __PORTA is just an alias of the address. Just a quick idea. Thanks for the rest of the information. It was very informative. In the meanwhile I figured out lots of things, and my target is reached: a RTOS. And I'm happy. Thanks anyways, 73 de HA5OGL Levente -- Levente Kovacs http://levente.logonex.eu _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
Levente Kovacs <[hidden email]> wrote:
> On Sun, 22 May 2011 22:20:17 +0200 (MET DST) > [hidden email] (Joerg Wunsch) wrote: > >> There's currently no symbolic method for that (ideas what/how to add >> the respective debugging information to the symbol table are welcome), > > Well, I'd add a table of the addresses, and you could use the syntax like > this: > > x/bx __PORTA Ideally even print PORTA Anyway, the big question is how to add this to the symbol table from just including the low-level header file (<avr/io.h>), or possibly even by linking against a separate object file which is going to add the debugging symbols. > In the meanwhile I figured out lots of things, and my target is > reached: a RTOS. And I'm happy. Glad to hear, 73! -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) _______________________________________________ AVR-GCC-list mailing list [hidden email] https://lists.nongnu.org/mailman/listinfo/avr-gcc-list |
Free forum by Nabble | Edit this page |