Login / Signup

Introduction to Freescale BDM (Background Debug Mode)

  • user warning: Table './devemc/sessions' is marked as crashed and last (automatic?) repair failed query: SELECT COUNT(sid) AS count FROM sessions WHERE timestamp >= 1422194791 AND uid = 0 in /home/devemc/public_html/dev/includes/session.inc on line 157.
  • user warning: Table './devemc/sessions' is marked as crashed and last (automatic?) repair failed query: SELECT COUNT(DISTINCT s.uid) FROM sessions s WHERE s.timestamp >= 1422194791 AND s.uid > 0 in /home/devemc/public_html/dev/modules/user/user.module on line 790.
Background Debug Mode BDM Freescale

One of the big advantages of the BDM (Background Debug Mode) is that sometimes it will provide a cheap method of obtaining the same debugging results which otherwise may only be obtained with expensive in-circuit emulators. In addition to that, the BDM offers the designer the advantage that no special circuit needs to be used around the target microcontroller in order to for its features to be accessed. In order for this to be possible, special hardware needs to be implemented inside the microcontroller itself.

Although this makes it more expensive (not by much) it has some real advantages when you need fast debugging and fast time-to-market. Generally speaking, an architecture using a Background Debug Mode interface will always consist of a Host and of a Target:

The Host may always query the target by initializing communication. A single pin of the microcontroller is necessary for the communication, and this is the BKGD pin, although the host needs access to the RESET pin too (only needed to allow the host to initiate a system reset, if needed). Many development tools feature a Background Debug Mode connector which has become a standard in the industry. It features 6 pins, out of which two are not used. The other ones are for Power, GND, BKGD and RESET:

The BKGD pin is an open-drain type, but the pull-up resistor is included in the microcontroller itself, so no external resistor is required. This configuration allows for bi-directional communication to occur on the same pin, both the host and the target being able to pull this pin to GND in order to assert a low-level voltage. This is the pin which provides a single-wire communication and debug interface to the microcontroller; it is also possible to access the various types of on-chip memories using it.

At an architectural level, the BDM consists of a background debug controller (BDC) and of a debug module (DBG). Since the debug facility consists of integrated hardware, there is no need for the BDC to use either the CPU or its instructions, allowing it to access internal memory even while the program runs. Both the BDC and the DBG offer a rich set of features which allow for extensive debug commands to be used in conjunction with the other internal functions of the microcontroller.

BDC features:
• Single dedicated pin for mode selection and background communications – BKGD pin
• BDC registers not located in memory map
• SYNC command to determine target communicates rate
• Non-intrusive commands for memory access
• Active background mode commands for CPU register access
• GO and TRACE1 commands
• BACKGROUND command can wake CPU from stop or wait modes
• One hardware address breakpoint built into BDC
• Oscillator runs in stop mode if BDM is enabled.

DBG features:
• Two trigger comparators:
— Two address and read/write (R/W) or
— One full address + data + R/W
• Flexible 8-word by 16-bit first-in, first-out (FIFO) for capture information:
— Change of flow addresses or
— Event data only
• Two types of breakpoints
— Tag breakpoints for instruction opcodes
— Force breakpoints for any address access
• Nine trigger modes
— A only
— A or B
— A then B
— A and B data (full mode)
— A but not B data (full mode)
— Event-only B (store data)
— A then event-only B (store data)
— Inside range (A address B)
— Outside range (address < A or address > B)

The main purpose of the BDC is to communicate via the BKGD pin, and since it does not use any memory locations from the microcontroller memory map, nor any of its peripherals, it can communicate with the host without interfering with the main application which runs on the target. The commands are transferred serially from the PC (or any other host processor) via the BKGD pin, MSB first, using a custom protocol. The transfer of the execution of these commands has no effect the real-time operation of the program even as it runs.

There are a various number of valid commands for the BDC (depending on its version), but all of them may be divided into two groups:
• Active background mode commands — No application is running on the target. Background command causes MCU to enter active background mode, during which the CPU registers can be accessed and during which all instructions are individually traceable
• Non-Intrusive Commands — Application program running on the target. Read/write access is granted to the MCU registers and to the status and control registers of the BDM.

Two different registers are associated with the BDC. These are the BDSCR (which is the 8-bit status and control register) and the BDCBKPT (which is the 16-bit breakpoint register). The breakpoint register is the one which holds the address for the hardware breakpoints used when debugging.
In order to avoid the possibility of accidentally accessing the debugger from the application running on the microcontroller, the BDSCR register is not mapped in the internal user memory.

A few details about the communication: two methods may be used in order to perform the host-target communication: a hardware method (which implies releasing the RESET pin after the BKGD pin, and when the MCU enters active background mode) and a software method (when there is no initial reset of the MCU and when non-intrusive commands may be transferred to the target, allowing for entering the active mode in this way).

Data is transferred through the BKGD pin at a rate equal to 16 background controller cycles, therefore it is important that the host knows the target clock speed (it is like setting the baud rate for a serial communication). The background controller cycle time is derived either from the bus clock of the MCU, or from an alternative internal clock source. Both options have advantages and disadvantages. Using the bus clock of the microcontroller can provide higher communication speed, which may prove useful when programming large portions of the flash memory. It is not recommended, however, to use this particular setting when performing general software debug, as the application running on the microcontroller still has the possibility of changing the clock source on-the-fly.

The similarities between JTAG and BDM are numerous, as they are both present on the market to address one of the most stringent of software development requirements: application debug. Unlike the JTAG, however, the BDM does not provide any possibility for days chaining, therefore it is not as favored as the JTAG when it comes to replacing the In-Circuit-Test bed of needles on the manufacturing lines.

Freescale BDM

If you want to know more about this Freescale product, please submit your request to Arrow Italy using this form.

NOTE: this form is valid ONLY for Companies or Customers based in Italy and working in the Italian area.

Who's online

There are currently users and guests online.

Recent comments