Thursday, February 22, 2018
Text Size
Knowledge Base
faq-icon.png ABTR-BDI Commands
Knowledgebase Articles
  • KB00015 - Can't Hit Breakpoints

    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.

    Hits : 351
  • KB00020- Can I write scripts to perform BDI operations?

    Can I write scripts to perform BDI operations?

    Answer:The easiest way to script with the BDI is to write GDB Scripts. All BDI telnet commands are available thru GDB via the “mon” keyword.

    As an example create a text file with the following data:

    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd
    mon mm 0x00000100 0x1234abcd

    Keep filling the file out 1000 times with that same line or any BDI command you need to execute preceded with the “mon” keyword, you can also enter any GDB command you need to execute. Save the file and call it BDIscript.txt. To run the commands from GDB you'll need to just type in:

    (gdb) source ../path/BDIscript.txt

    It is s very straight-forward; make multiple files for multiple such tasks. You can write more complicated gdb scripts, define functions and create very powerfull GDB scripts. Look here for details:

    Hits : 381
  • KB00053 - BDI2000/3000 What's the difference between Power up vs. Wakeup

    Indeed the "POWERUP" option is not documented in the bdiGDB-ARM11/Cortex manual v1.13.  This will be fixed in the next release.  Abatron added  this command but neglected to add it to the manual.

    POWERUP is only used after a power-cycle of the target.  After the BDI detects a power-on it does nothing for the time defined by POWERUP.  Then a reset sequence is started.

    WAKEUP is used during the reset sequence after the BDI releases RESET. It waits for WAKEUP time until it continues with the reset sequence.

    User's targeting the iMX51 should know there is no JTAG communication possible while reset is asserted.  You need to release reset before you can set the HALT Request Bit. This means that the CPU starts running in any case and the WAKEUP becomes actually a run time. During this run time the code present on the target may setup for example the PLL so you can connect with the faster clock.  It's assume that our provided configuration would also work if we only change the SCANINIT.

    ; There is no debug communication possible when RESET is asserted.
    ; In order be able to hard reset the system we use SCANINIT SCANINIT  r1:w100:t1:w100:t0: ;assert reset and toggle TRST
    SCANINIT  w1000:ch10:w1000:   ;clock TCK with TMS high and wait
    SCANINIT  r0:w200000          ;release reset, wait 200 ms
    Hits : 197
  • KB00139 - New Telnet "eprog" Command supports Selective Erase/Program of Flash

    The new Telnet "eprog" command automatically erases the used sectors based on the information in the ELF header.

    Instead of "prog" you have to use the new "eprog" command.  The BDI needs information about the sector addresses and sizes of the used flash. It will get it from the erase list in the configuration file. The syntax is "ERASE address size count".  It is not necessary to specify all flash sectors. But users need to specify those sectors that are candidates for erase/program.

    If you use "erase" via Telnet then the whole list will be erased.
    If you use "eprog" the sectors are checked against the elf header and only the relevant sectors will be erased before programming.

    This new command supports only ELF files.  Binary and S-record files are not supported.  For all file formats other than ELF, the "eprog" command maps to the normal "prog" command.

    Firmware for BDI2000: b20copgd.135 (bdiGDB-COP)
    Firmware for BDI3000: b30copgd.135 (bdiGDB-COP)

    Hits : 104

Ultimate Solutions, Inc.
10 Clever Drive
Tewksbury, MA 01876 USA
Phone: 978.455.3383
Fax: 978.926.3091
Quick Link to Support & Resources:


Twitter Button  

Latest News

Abatron adds support for AppliedMicro's X-Gene™ processor
More Info

USI acquires Zylin ZY1000 product line
Click Here

Available NOW for an introductory price!
Embedded Linux BSP Program from bootbits
Click Here...

Ask about new Boundary Scan capabilities with the ZY1000!
Click for more info


An Easier Way to Debug Linux - Download the Pre-recorded Webinar


Hardware Debuggers (Episode 29) Interview with Fahd Abidi  Download Here

USI ToolFinder

Use our Toolfinder to find Development Tools available for your processor family! Click Here...

USI Blog

Feel free to leave a comment or idea! Click Here...