Debuggin AVR32

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I had a question about debugging: it looks like a GDB is either close to done or already done based on the press release, so debugging could be done remotely over ethernet if using Linux?

What support will GDB have in hardware (aka fast speed)? I've seen mention of hardware support for data watchs, breakpoints, and a real-time trace. Though I haven't found the specific location in the datasheet that talks about how to use it... but it must be there!

Regards,

-Colin

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GDB is working, although it can't really be considered "done" yet. You can indeed use it to debug Linux applications remotely over ethernet (or a serial line), although the shared library support is still a little buggy, and you can use it to debug standalone applications through the JTAGICEmkII using the avr32gdbproxy program included with the STK1000 BSP.

Support for hardware features like watchpoints and trace isn't implemented yet. How are such things supposed to work in gdb anyway? Hardware breakpoints are implemented for standalone programs, but not for Linux applications right now.

Those hardware features are supposed to be described in a technical reference manual, although I can't find it anywhere on atmel.com.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Colin,

But the way things like data breakpoints are done in a Linux user app is using the memory protection system of the CPU's MMU. When you are using GDB only the user app/threads are stopped during debugging - the Linux kernel continues to run.

The upshot of this is that while gdbserver/gdb/ddd over ethernet are a GREAT way to debug user level code - in a Linux system there is no easy way to debug the kernel or device drivers. The kernel can have the KDGB patch applied which is supposed to help support this but it's a bit flaky and on the whole everyone just debugs kernel/driver code using printk()s in the end.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It would be interesting to see if/how much hardware data breakpoints and trace would make the program run faster, though. With trace, I would guess quite a lot.

For kernel debugging, you can always use GDB with JTAGICEmkII, although it requires that the code you're debugging is built-in (not in a module). Data Trace is truly awesome when debugging low-level hardware access; although you currently need a Vitra to benefit from this...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
For kernel debugging, you can always use GDB with JTAGICEmkII, although it requires that the code you're debugging is built-in (not in a module). Data Trace is truly awesome when debugging low-level hardware access; although you currently need a Vitra to benefit from this...

Wow so you have an AVR32 debugger that understands memory virtualisation then? I've implemented Linux on several processors and while the JTAG has always been great for debugging the bootloader as soon as the Linux makes the switch into VM mode the debuggers have been useless though I've recently found a couple of ARM JTAG debuggers (American Arium and Lauterbach) that CAN handle the Linux switch to VM mode as they are "Linux aware" debuggers - but they are the exception rather than the rule.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
how wrote:
For kernel debugging, you can always use GDB with JTAGICEmkII, although it requires that the code you're debugging is built-in (not in a module). Data Trace is truly awesome when debugging low-level hardware access; although you currently need a Vitra to benefit from this...

Wow so you have an AVR32 debugger that understands memory virtualisation then? I've implemented Linux on several processors and while the JTAG has always been great for debugging the bootloader as soon as the Linux makes the switch into VM mode the debuggers have been useless though I've recently found a couple of ARM JTAG debuggers (American Arium and Lauterbach) that CAN handle the Linux switch to VM mode as they are "Linux aware" debuggers - but they are the exception rather than the rule.

Well, it doesn't really understand virtual memory completely. That's why you can't debug modules. But it does understand the segmentation model, that is, that memory at 0x80000000-0x9FFFFFFF is mapped to physical address 0x00000000-0x1FFFFFFF, and this is where the kernel image is located. Also, the memory from 0xE0000000 to 0xFFFFFFFF is unmapped (i.e. phys==virt) when running with segmentation, so access to I/O modules works as expected too.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

But surely everything in a Linux system that is mmap()d will no longer live at the address it appears to live at. If the code *thinks* something lives at 0x12345678 (it's vitual address) and you set a h/w data access breakpoint there then the address comparator in the JTAG will be set up to trigger on an access to this address but the physical address may be 0x88415678 and so the thing will neve trigger. Your debugger needs to understand how the MMU on the chip has been programmed to relocate physical addresses to virtual addresses and this is what the AA/Luterbach products offer for the ARM because without it nothing in a Linux virtual world is where it appears to be. (of course uCLinux is nice and can easily be JTAG debugged becuase it has no such thing as virtual addressing)

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
But surely everything in a Linux system that is mmap()d will no longer live at the address it appears to live at.

That's true. Which means you can't really expect to get a lot of meaningful information when the CPU is executing user-space code. But the kernel itself (excluding modules) uses a fixed mapping from virtual to physical addresses which the debugger is aware of, so as long as you run kernel code and access kernel data, the debugger will do the right thing.

Quote:
If the code *thinks* something lives at 0x12345678 (it's vitual address) and you set a h/w data access breakpoint there then the address comparator in the JTAG will be set up to trigger on an access to this address but the physical address may be 0x88415678 and so the thing will neve trigger.

Actually, I think that will work since the data breakpoint unit triggers on virtual addresses, i.e. the address the CPU core thinks it's writing to.

Quote:
Your debugger needs to understand how the MMU on the chip has been programmed to relocate physical addresses to virtual addresses and this is what the AA/Luterbach products offer for the ARM because without it nothing in a Linux virtual world is where it appears to be.

Sounds like a pretty neat product. How does it solve the problem of loading the correct symbols when executing user code?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
Sounds like a pretty neat product. How does it solve the problem of loading the correct symbols when executing user code?

That's actually two different ARm JTAG debugger products. American Arium are in the States and distributed by logic.nl in Europe while Lauterbach are German I think. And both just use .ELF files as any other debugger when loading symbols.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

AFAIK it is possible to write a plugin to PathFinder that makes it "OS aware". Ie http://www.ashling.com/pressrele...
So if it can be done for eCos it should be possible for Linux.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

c_oflynn wrote:
I had a question about debugging: it looks like a GDB is either close to done or already done based on the press release, so debugging could be done remotely over ethernet if using Linux?

using SSH over the internet would be just like sitting in front of the remote, since it is running the 2.6 kernel. You could then run GDB as you normally would.

Hey, I already did this with the STK500!
AVRDUDE over internet w/ Linux SSH
http://tinyurl.com/o8e9q