Levente Kovacs <leventel...@gmail.com> 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 AVR-GCC-list@nongnu.org https://lists.nongnu.org/mailman/listinfo/avr-gcc-list
