Categories
|
|
|
|
|
Frequently Asked Questions
|
|
|
|
|
 |
| A304 - Why can't I hit breakpoints in my Kernel, Uboot or program? |
|
Breakpoints are not immediately set when you put a "bi" command in the BDI or a "break" in GDB. They are set as soon as you hit "go" and are cleared as soon as you stop. This way they do not influence debugging. You will never see the breakpoints in the DBCR0 or DBCR1 registers. For debugging Linux kernels, set the initial breakpoint after Uboot has booted up and before the kernel is loaded. This way Uboot will not clear the kernel breakpoint during its startup.
As a basic test to see if breakpoints are working, you can single step from the bootvector by doing, "BDI> ti", "BDI> ti", "BDI> ti". Then do a "BDI> i" and note the current PC. Restart the processor, "BDI> res", and set a breakpoint at this PC location, "BDI> bi 0x00000105". You can now let the processor run until it hits the instruction, "BDI> go". The processor should execute until this breakpoint is hit. If this does not work then some setting on the target is not correct.
There are a few reasons you could be missing breakpoints:
1) If you are debugging a bootloader or program from flash you must use hardware breakpoints. Software breakpoints do not work in flash because of the way flash is accessed. In your config file add BREAKMODE HARD in the target section.
2) When using hardware breakpoints be aware of how many breakpoints are available to you on your processor, If you exceed the amount that are available you will start missing breakpoints. You can clear older break points by doing a "CI" from the BDI telnet prompt.
3) The Linux kernel could be modifying the debug registers and clearing the breakpoints you set. Use the CONFIG_BDI_SWITCH in the Linux configuration to disable writing to debug registers or set up the switch in your sources so that when it is set the debug registers are not written to by software. Use "make menuconfig" and under "kernel hacking" select the CONFIG_BDI_SWITCH.
4) Similarly Uboot is known to clear debug registers. If you can't hit breakpoints with Uboot or any boot loader, set a very early breakpoint about 1 or 2 instructions from the reset vector to test. Try the procedure described in paragraph 2 above. If it does hit this breakpoint then your task is to find where the debug registers are written to in the source and add a CONFIG_BDI_SWITCH to disable it.
5) If register initializations in your config file conflict with your bootloader then your will end up with problems that may rear themselves when you are debugging. Trying to connect with GDB and set breakpoints results in unexpected behavior. For debugging your bootloader the config file should be as small as possible and should only bring up the board enough to where it can stop successfully at the bootvector.
6) Also as a test you can create a loop at the first line of "main" and set a break point inside the loop. That way the processor will be stuck looping and will not execute any other code before it hits the breakpoint. This is a good way of checking if you can hit breakpoints at all and if the debug registers get cleared later on.
7) If you keep breaking on unhandled exceptions or interrupts you probably need to enable VECTOR CATCH in your BDI2000 config file. Use STARTUP RESET to let the BDI setup vector catching on startup.
8) For software breakpoints to work, the kernel code pages need to be writeable. If the MMU is setup for read only on kernel page tables, then the BDI will not be able to modify the memory here to put in the TRAP instruction. Modify pgtable.c to enable writing to the kernel code pages, "f l=_PAGE_WRENABLE".
9) Use objdump -x on the elf executable to see all the program symbols in the source and make sure that the address you are breaking at is correct.
|
|
|
| Article ID: 10010 |
Article Created: 05-12-2008 15:16 PM |
|
|
