Generally speaking, they can be divided into two categories: one is used to test the electrical characteristics of the chip and detect whether there is a problem with the chip; the other is used for debugging. Most CPUs that support this feature include both of these modules.
A CPU with a debug interface module, provided the clock is normal, can access its internal registers and devices connected to the CPU bus via the JTAG interface, such as FLASH, RAM, and registers of built-in modules in the SoC (e.g., 4510B, 44Box, AT91M series), including registers for UART, Timers, GPIO, etc. The above only describes the capabilities of the JTAG interface; using these functions requires software support, and the specific functionality is determined by the software. For example, consider the function of downloading a program to RAM. Those familiar with SoCs know that using external RAM requires referring to the SoC Datasheet register descriptions to set the RAM's base address, bus width, access speed, etc. Some SoCs also require remapping to function correctly. During firmware operation, these settings are completed by the firmware initialization program. However, if using the JTAG interface, the relevant registers may still be at power-on values or even error values, preventing the RAM from functioning correctly, thus inevitably causing the download to fail. To use it normally, a way to configure the RAM must first be found. In ADW, settings can be configured using the Let command in the Console window; in AXD, settings can be configured using the Set command in the Console window.
Below is a command sequence for configuring the AT91M40800: disable interrupts, configure CS0-CS3 , and perform a remap. This is applicable to AXD (the debug function included with ADS).
`setmem0xfffff124 , 0xFFFFFFFF , 32` --- disables all interrupts.
`setmem0xffe00000 , 0x0100253d , 32` --- Sets CS00xffe00004 , 0x02002021 , 32 --- Sets CS1
setmem0xffe00008 , 0x0300253d , 32 --- Set CS2
setmem0xffe0000C , 0x0400253d , 32 --- Set CS3
setmem0xffe00020 , 1 , 32---Remap
If you want to use it in ADW (SDT's DEBUG), you need to change it to:
let0xfffff124=0xFFFFFFFF---Disable all interrupts
let0xffe00000=0x0100253d---Set CS0
let0xffe00004=0x02002021---Set CS1
let0xffe00008=0x0300253d---Set CS2
let0xffe0000C=0x0400253d --- Set CS3
let0xffe00020=1---Remap
For ease of use, you can save the above commands as a file named config.ini , and then execute it by typing obconfig.ini in the Console window.
Using other debuggers is generally similar, only the commands and command formats are different.
When configuring RAM, the registers set and their values must match the settings of the program to be run. Generally, the compiled object file is in ELF format or a similar format, containing the execution address of the object code. The execution address is determined during linking. During debugging, the program is downloaded to the specified address based on the address information in the ELF file. If the base address of RAM is set to 0x10000000 , but the firmware's starting address is specified as 0x02000000 during compilation , the object code will be downloaded to 0x02000000, obviously resulting in download failure.
Before downloading a program via JTAG, all interrupts should be disabled, for the same reason as disabling interrupts during firmware initialization. When using the JTAG interface, the enabling of each interrupt is unknown, especially if executable code is stored in Flash, some interrupts may be enabled. After downloading the code via JTAG, execution may be interrupted before initialization is complete, leading to program errors. Therefore, interrupts must be disabled first, typically by setting the SOC's interrupt control register. Writing to Flash via JTAG: Theoretically, JTAG can access all devices on the CPU bus, so writing to Flash should be possible. However, Flash writing differs significantly from RAM writing, requiring special commands. Different Flash erasers require different programming commands, and the block size and number also vary, making this functionality difficult to provide. Therefore, debug systems generally do not provide Flash writing functionality, or only support a limited number of Flash types. Currently, to my knowledge, only FlashPGM software provides Flash writing functionality for ARM, but its use is very cumbersome. AXD and ADW do not provide Flash writing functionality. My method for writing Flash code involves writing a simple program specifically for the target board's Flash memory. Using the JTAG interface, I download this program to the target board. Then, I package the target code to be written into a BIN file and download that to the target board as well (the address is different from the address of the Flash code program). Finally, I run the downloaded Flash code program. This method seems to be faster than using FlashPGM to write Flash.
About simple JTAG cables.
Currently, there are various simple JTAG cables available, which are essentially just level conversion circuits that also provide protection. The JTAG logic is implemented by software running on the PC, so theoretically, any simple JTAG cable can support various application software, such as debuggers. I have personally used the same JTAG cable to write debugging programs for Xilinx CPLD and AXD/ADW. The key lies in software support; most software does not provide configuration functions and therefore can only support a specific type of JTAG cable.
Regarding the speed of a simple JTAG cable: JTAG is a serial interface. A simple JTAG cable using the printer port leverages the printer port's latching output feature, with software generating JTAG timings via I/O. As determined by the JTAG standard, writing/reading a byte via JTAG requires a series of operations. Based on my analysis, using a simple JTAG cable and utilizing the printer port to output one byte to the target board requires an average of 43 printer port I/O operations . On my machine (P4 1.7G ), this translates to approximately 660K I/O operations per second, resulting in a download speed of approximately 660K/43 , roughly equivalent to 15KByte/s . For other machines, the I/O speed is roughly the same, typically between 600K and 800K .
How to improve JTAG download speed.
It's clear that using a simple JTAG cable won't increase speed. There are generally two ways to increase speed.
1. The system uses the JTAG interface provided by the system, and the system and the microcomputer are connected via USB/Ethernet. This requires the use of an MCU.
2. Use a CPLD/FPGA to provide a JTAG interface. The CPLD/FPGA and the microcomputer use an EPP interface (most microcomputer printer ports support EPP mode). The EPP interface completes the data transmission between the microcomputer and the CPLD/FPGA, and the CPLD/FPGA completes the JTAG timing.
I have implemented both methods. The first method can achieve relatively high speeds, exceeding 200 KByte/s in actual tests (note: Byte, not Bit); however, the hardware is relatively complex, and manufacturing is also more complicated. The second method is relatively slower, reaching a maximum speed of 96 KByte/s, but the circuitry is simpler, manufacturing is easier, and the speed is sufficient. The second approach also has a drawback: because the CPU is not released during I/O operations, the microcomputer CPU becomes very busy when downloading programs.
In summary, I believe that the second method is more preferable for individual enthusiasts.
For more information, please follow the Embedded Systems channel.
