Can I use JTAG to debug my program on top of embedded Linux?
Asked Answered
J

4

5

I am using an at91sam9260 for my developments. There is a Linux kernel running in it and I start my own software on top of it.

I was wondering if I could use a JTAG debugger to debug the software I am working on without seeing to much of what is going on the Linux kernel ?

I am asking that because I think that I might become very complex to debug my software while seeing the full Linux execution.

In other words I would like to know if there could be some abstraction layer when debugging with JTAG probe?

Jackboot answered 6/1, 2012 at 9:13 Comment(0)
H
2

Generally yes you can jtag as a debugger has absolutely nothing to do with what software you happen to be running on that processor. Where you can get into trouble is the cache, for example if you stop the processor want to change some instructions in ram, and restart, the changing of instructions in ram is a data access, which does not go through the instruction cache but the data cache, if you have a separate instruction and data cache, they are enabled and some of the instructions you have modified are at address that are in the instruction cache, you can get messed up pretty fast with new and stale instructions being fed to the processor. Linux likes to use the caches if there.

Second is the mmu, the processor/jtag is likely operating on the virtual addresses on the processor side of the mmu not the physical addresses, so depending on how the hardware works, if for example you set a breakpoint by address in a debug unit in the processor and the operating system task switches to another program/thread at that same address space, you will breakpoint on the wrong program at the right address. If the debugger/processor sets breakpoints by modifying an instruction in ram then you run into the cache problem above, IF not cached then you will break on the right instruction in the right thread, but then you have that cache problem.

Bottom line, absolutely, if the processor supports jtag based debugging that doesnt change based on whatever software you choose to run on that processor.

Healey answered 6/1, 2012 at 15:57 Comment(2)
Thank to all of you for your answers. You might be right telling me to use another more appropriate debugger to run on top of the linux kernel. In fact, I am also currently trying to use gdb to debug my program through uart. it is a bit more complicated than I thought. Anyway thanks again.Jackboot
Disagree: even apart from virtual memory, debugging application code running under a multitasking kernel is likely to be pretty ugly if the software driving the debugger does not have awareness of (or preferably cooperation from) that kernel. Typically such programs are debugged using debug capabilities in the kernel (such as ptrace) and a debug stub running on the target and communicating over a data interface. A hardware debugger would be more useful for debugging the kernel itself, especially its initial startup.Klecka
K
3

Probably not -- as far as I know, most JTAG debuggers assume the ability of setting breakpoints in the processor. Under a multitasking OS, that stops the OS kernel too.

Embedded OS's like QNX have debuggers that operate on top of the OS kernel and which communicate over Ethernet.

Kindrakindred answered 6/1, 2012 at 11:41 Comment(0)
L
2

It depends on JTAG device and it's driver. Personally, I know only one device that capable of doing that: XDS560 + Code composer studio (CCS). But, there can be others.

I suggest to consult with manufacturer of your device.

Lentigo answered 6/1, 2012 at 11:2 Comment(0)
H
2

Generally yes you can jtag as a debugger has absolutely nothing to do with what software you happen to be running on that processor. Where you can get into trouble is the cache, for example if you stop the processor want to change some instructions in ram, and restart, the changing of instructions in ram is a data access, which does not go through the instruction cache but the data cache, if you have a separate instruction and data cache, they are enabled and some of the instructions you have modified are at address that are in the instruction cache, you can get messed up pretty fast with new and stale instructions being fed to the processor. Linux likes to use the caches if there.

Second is the mmu, the processor/jtag is likely operating on the virtual addresses on the processor side of the mmu not the physical addresses, so depending on how the hardware works, if for example you set a breakpoint by address in a debug unit in the processor and the operating system task switches to another program/thread at that same address space, you will breakpoint on the wrong program at the right address. If the debugger/processor sets breakpoints by modifying an instruction in ram then you run into the cache problem above, IF not cached then you will break on the right instruction in the right thread, but then you have that cache problem.

Bottom line, absolutely, if the processor supports jtag based debugging that doesnt change based on whatever software you choose to run on that processor.

Healey answered 6/1, 2012 at 15:57 Comment(2)
Thank to all of you for your answers. You might be right telling me to use another more appropriate debugger to run on top of the linux kernel. In fact, I am also currently trying to use gdb to debug my program through uart. it is a bit more complicated than I thought. Anyway thanks again.Jackboot
Disagree: even apart from virtual memory, debugging application code running under a multitasking kernel is likely to be pretty ugly if the software driving the debugger does not have awareness of (or preferably cooperation from) that kernel. Typically such programs are debugged using debug capabilities in the kernel (such as ptrace) and a debug stub running on the target and communicating over a data interface. A hardware debugger would be more useful for debugging the kernel itself, especially its initial startup.Klecka
Y
0

For ARM, the Asset Arium family is claimed to be able to debug application code. I haven't tried it, though.

Yogurt answered 12/3, 2014 at 1:58 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.