31
мар
Serial Wire Debug (SWD) Toolkit for LabVIEW by RAFA Solutions easily implements and integrates Serial Wire Debug protocol in custom applications. Feb 22, 2015 Serial Wire Debug (SWD) Serial Wire Debug (SWD) is a debug port similar to JTAG, and provides the same debug capabilities (run, stop on breakpoints, single-step) but with fewer pins. It replaces the JTAG connector with a 2-pin interface (one clock pin and one bi-directional data pin). The SWD port itself does not provide for real-time tracing.
Passive debugging: The simplest method is passive debugging, wherein the device being debugged sends out debug messages over a debug interface, and the debugger host captures and displays the messages. These debug messages can possibly be any text or data that helps in identifying the state, control, or data flow of the device being debugged. It is notable that the debugger only receives the messages sent out by the debugged and displays them. The responsibility of spitting out useful messages is on the debugged. The debugger cannot ask for data that it wants, because the communication is one directional.
This kind of setup can be visualized as in Figure 12.1. ■ Figure 12.1. A view of a debugger operation in passive mode.This kind of setup is nonintrusive, and the debugged and debugger do not require major infrastructure, neither do they have to follow any specific protocol. All that is required is that the debugged initializes and starts writing to the debug interface; the debugger, if connected and available, will configure itself to the baud rate of the debugged and start receiving messages. Because of its simplicity and innocuousness, this kind of setup is used during early boot flow of system, devices, and CPUs. Active debugging: The second scenario (see Figure 12.2) is when the device being debugged is actively involved in inquiring, and/or changing the state, control, or data flow of the device being debugged. In this case, in addition to the messages (data/state) that the debugged sends out, the debugger can ask for additional data needed for debug.
Not only can the debugger ask for additional data and state information, but also the debugger can change the control flow (halt the execution of the debugged, or change the program counter) or change the data, thereby triggering a control flow change, and so on. The debugger sends a command over the debug interface to the debugged, and the debugged responds to the commands.
Since there is back-and-forth communication of command and data, a client is needed on both sides that listens from the other end and responds appropriately. Due to the need for clients, this mechanism can be employed only after the basic infrastructure is up and the clients are up and working. Joseph Yiu, in, 2014 14.2.2 Processor debug interfaceNow let’s look at the debug interface in a bit more detail.In order to allow the debugger to access various debug features, a debug interface is needed. Many microcontrollers support a serial protocol called JTAG – Joint Test Action Group. The JTAG protocol is an industry standard protocol (IEEE 1149.1) and can be used for various functions such as chip-level or PCB-level testing, as well as giving access to debug features inside microcontrollers.While JTAG is sufficient for many debug usage scenarios, it needs at least four pins: TCK, TDI, TMS, and TDO; the reset signal nTRST is optional. For some microcontroller devices with low pin counts, such as 28-pin packages, using four pins for debugging is too many.
As a result, ARM ® developed the Serial Wire debug protocol, which only needs two pins: SWCLK and SWDIO. The Serial Wire debug protocol provides the same debug access features and also supports parity error detection, which enables better reliability in systems with higher electrical noise. Therefore the Serial Wire debug protocol is very attractive for many microcontroller vendors and users. Pin sharing between JTAG and Serial Wire debug protocolMany Cortex ®-M3 and Cortex-M4 microcontrollers support both JTAG and Serial Wire debug protocols. You can dynamically switch between the two modes using special bit patterns on the TMS/SWDIO pin. In order to achieve lower power consumption, some microcontrollers omit the JTAG debug protocol capability and support only the Serial Wire debug protocol.Typically Cortex-M0 and Cortex-M0+ microcontrollers only support one of these debug protocols to reduce power: mostly the Serial Wire debug protocol because fewer pins are needed.When using the Serial Wire debug protocol, the TDO pin can be used for trace operation with SWO (Serial Wire Output), as outlined in section 14.1.2. Many low-cost debug adaptors support trace capture via SWO.
Connection of the AHB-AP in the Cortex-M3.The CSW register can control the transfer direction (read/write), transfer size, transfer types, and so on. The TAR register is used to specify the transfer address, and the DRW register is used to carry out the data transfer operation (transfer starts when this register is accessed).The data register DRW represents exactly what is shown on the bus. For half word and byte transfers, the required data will have to be manually shifted to the correct byte lane by debugger software. For example, if you want to carry out a data transfer of half word size to address 0x1002, you need to have the data on bit 31:16 of the DRW register.
The AHB-AP can generate unaligned transfers, but it does not rotate the result data based on the address offset. So, the debugger software will have to either rotate the data manually or split an unaligned data access into several accesses if needed.Other registers in the AHB-AP provide additional features. For example, the AHB-AP provides four banked registers and an automatic address increment function so that access to memory within close range or sequential transfers can be speeded up.
The AHB-AP also contains a register called base address to indicate the address of ROM table.In the CSW register, there is one bit called MasterType. This is normally set to 1 so that hardware receiving the transfer from AHB-AP knows that it is from the debugger.
However, the debugger can pretend to be the core by clearing this bit. In this case, the transfer received by the device attached to the AHB system should behave as though it is accessed by the processor. This is useful for testing peripherals with FIFO that can behave differently when accessed by the debugger. Joseph Yiu, in, 2010 2.10 Debugging SupportThe Cortex-M3 processor includes a number of debugging features, such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.The debugging hardware of the Cortex-M3 processor is based on the CoreSight™ architecture. Unlike traditional ARM processors, the CPU core itself does not have a Joint Test Action Group (JTAG) interface. Instead, a debug interface module is decoupled from the core, and a bus interface called the Debug Access Port (DAP) is provided at the core level. Through this bus interface, external debuggers can access control registers to debug hardware as well as system memory, even when the processor is running.
The control of this bus interface is carried out by a Debug Port (DP) device. The DPs currently available are the Serial-Wire JTAG Debug Port (SWJ-DP) (supports the traditional JTAG protocol as well as the Serial-Wire protocol) or the SW-DP (supports the Serial-Wire protocol only). A JTAG-DP module from the ARM CoreSight product family can also be used.
Chip manufacturers can choose to attach one of these DP modules to provide the debug interface.Chip manufacturers can also include an Embedded Trace Macrocell (ETM) to allow instruction trace. Trace information is output via the Trace Port Interface Unit (TPIU), and the debug host (usually a Personal Computer PC) can then collect the executed instruction information via external trace-capturing hardware.Within the Cortex-M3 processor, a number of events can be used to trigger debug actions. Debug events can be breakpoints, watchpoints, fault conditions, or external debugging request input signals. When a debug event takes place, the Cortex-M3 processor can either enter halt mode or execute the debug monitor exception handler.The data watchpoint function is provided by a Data Watchpoint and Trace (DWT) unit in the Cortex-M3 processor. This can be used to stop the processor (or trigger the debug monitor exception routine) or to generate data trace information. When data trace is used, the traced data can be output via the TPIU.
(In the CoreSight architecture, multiple trace devices can share one single trace port.)In addition to these basic debugging features, the Cortex-M3 processor also provides a Flash Patch and Breakpoint (FPB) unit that can provide a simple breakpoint function or remap an instruction access from Flash to a different location in SRAM.An Instrumentation Trace Macrocell (ITM) provides a new way for developers to output data to a debugger. By writing data to register memory in the ITM, a debugger can collect the data via a trace interface and display or process them. This method is easy to use and faster than JTAG output.All these debugging components are controlled via the DAP interface bus on the Cortex-M3 or by a program running on the processor core, and all trace information is accessible from the TPIU.
Aside from memory, peripheral options, and operation speed, a number of other factors make one Cortex™-M3 product different from another. The Cortex-M3 design supplied by ARM contains a number of features that are configurable, such as.Number of external interrupts.Number of interrupt priority levels (width of priority-level registers).With Memory Protection Unit (MPU) or without MPU.With Embedded Trace Macrocell (ETM) or without ETM.Choice of debug interface (Serial-Wire (SW), Joint Test Action Group (JTAG), or both)In most projects, the features and specification of the microcontroller will certainly affect your choice of Cortex-M3 product.Peripherals: For many applications, peripheral support is the main criterion.
More peripherals might be good, but this also affects the microcontroller's power consumption and price.Memory: Cortex-M3 microcontrollers can have Flash memory from several kilobytes to several megabytes. In addition, the size of the internal memory might also be important. Usually these factors will have a direct impact on the price.Clock speed: The Cortex-M3 design from ARM can easily reach more than 100 MHz, even in 0.18 µm processes.
However, manufacturers might specify a lower operation speed due to limitations of memory access speed.Footprint: The Cortex-M3 can be available in many different packages, depending on the chip manufacturer's decision. Many Cortex-M3 devices are available in low pin count packages, making them ideal for low-cost manufacturing environments.Currently, a number of microcontroller vendors are already shipping Cortex-M3-based microcontrollers, and a number of other vendors will also soon be shipping Cortex-M3 products. Here, we list a number of them:Texas Instruments (formerly LuminaryMicro): The Stellaris Cortex-M3 microcontroller product range has over 100 devices in the family, including devices with 10/100 Ethernet MAC and PHY, USB, CAN, SPI, I 2C, I 2S, and so on. ST Microelectronics: The ST's Cortex-M3 products included several product lines as follows:.STM32 connectivity line for feature-packed device supporting USB On-The-Go (USB OTG), Ethernet, and memory cards.STM32L for ultralow-power applications with analog and LCD interface support.
The Cortex-M3 processor is released as a processor subsystem (see Figure 6.3). The CPU core itself is closely coupled to the interrupt controller (NVIC) and various debug logic blocks:.CM3Core: The Cortex-M3 core contains the registers, ALU, data path, and bus interface.NVIC: The NVIC is a built-in interrupt controller. The number of interrupts is customized by chip manufacturers.
The NVIC is closely coupled to the CPU core and contains a number of system control registers. It supports the nested interrupt handling, which means that with the Cortex-M3, nested interrupt handling is very simple. It also comes with a vectored interrupt feature so that when an interrupt occurs, it can enter the corresponding interrupt handler routine directly, without using a shared handler to determine which interrupt has occurred.SYSTICK Timer: The System Tick (SYSTICK) Timer is a basic countdown timer that can be used to generate interrupts at regular time intervals, even when the system is in sleep mode. It makes OS porting between Cortex-M3 devices much easier because there is no need to change the OS's system timer code.
The SYSTICK Timer is implemented as part of the NVIC.WIC: A module interface with NVIC but separated from the main processor design to allow the system to wake up from interrupt events while the processor (including the NVIC) is completely stopped or powered down. This module is new from the Cortex-M3 revision 2 and is optional.MPU: The MPU block is optional. This means that some versions of the Cortex-M3 might have the MPU and some might not. If it is included, the MPU can be used to protect memory contents by, for example, making memory regions read-only or preventing user applications from accessing privileged applications data.BusMatrix: A BusMatrix is used as the heart of the Cortex-M3 internal bus system.
It is an AHB interconnection network, allowing transfer to take place on different buses simultaneously unless both bus masters are trying to access the same memory region. The BusMatrix also provides additional data transfer management, including a write buffer as well as bit-oriented operations (bit-band).AHB to APB: An AHB-to-APB bus bridge is used to connect a number of APB devices such as debugging components to the private peripheral bus in the Cortex-M3 processor. In addition, the Cortex-M3 allows chip manufacturers to attach additional APB devices to the external private peripheral bus (PPB) using this APB bus.The rest of the components in the block diagram are for debugging support and normally should not be used by application code.SW-DP/SWJ-DP: The Serial Wire Debug Port (SW-DP)/Serial Wire JTAG Debug Port (SWJ-DP) work together with the AHB Access Port (AHB-AP) so that external debuggers can generate AHB transfers to control debug activities. There is no JTAG scan chain inside the processor core of the Cortex-M3; most debugging functions are controlled by the NVIC registers through AHB accesses. SWJ-DP supports both the Serial Wire Protocol and the JTAG Protocol, whereas SW-DP can support only the Serial Wire Protocol.AHB-AP: The AHB-AP provides access to the whole Cortex-M3 memory through a few registers. This block is controlled by the SW-DP/SWJ-DP through a generic debug interface called the Debug Access Port (DAP). To carry out debugging functions, the external debugging hardware needs to access the AHB-AP through the SW-DP/SWJ-DP to generate the required AHB transfers.ETM: The ETM is an optional component for instruction trace, so some Cortex-M3 products might not have real-time instruction trace capability.
Trace information is output to the trace port through TPIU. The ETM control registers are memory mapped, which can be controlled by the debugger through the DAP.DWT: The DWT allows data watchpoints to be set up. When a data address or data value match is found, the match hit event can be used to generate watchpoint events to activate the debugger, generate data trace information, or activate the ETM.ITM: The ITM can be used in several ways. Software can write to this module directly to output information to TPIU, or the DWT matching events can be used to generate data trace packets through ITM for output into a trace data stream.TPIU: The TPIU is used to interface with external trace hardware such as trace port analyzers.
Internal to the Cortex-M3, trace information is formatted as Advanced Trace Bus (ATB) packets, and the TPIU reformats the data to allow data to be captured by external devices.FPB: The FPB is used to provide Flash Patch and Breakpoint functionalities. Star trek enterprise season 5 torrents download. Flash Patch means that if an instruction access by the CPU matches a certain address, the address can be remapped to a different location so that a different value is fetched. Alternatively, the matched address can be used to trigger a breakpoint event. The Flash Patch feature is very useful for testing, such as adding diagnosis program code to a device that cannot be used in normal situations unless the FPB is used to change the program control.ROM table: A small ROM table is provided. This is simply a small lookup table to provide memory map information for various system devices and debugging components.
Debugging systems use this table to locate the memory addresses of debugging components. In most cases, the memory map should be fixed to the standard memory location, as documented in the Cortex-M3 Technical Reference Manual (TRM) Ref. 1, but because some of the debugging components are optional and additional components can be added, individual chip manufacturers might want to customize their chip's debugging features. In this case, the ROM table must be customized and used for debugging software to determine the correct memory map and hence detect the type of debugging components available. JTAG SignalsTDITest Data In – this signal is the serial data stream received into the TDI pin of a device in a JTAG chain.TDOTest Data Out – this signal is the serial data stream transmitted from the TDO pin to the TDI pin of the next device in a JTAG chain.TCKTest Clock – this is the clock signal for JTAG communication, and must be connected to the TCK pin on all target ISP devices that share the same data stream. This signal should be given special routing consideration since it is operational critical.TMSTest Mode Select – this is the JTAG mode signal that establishes the appropriate TAP state transitions for each target ISP device.
It will be connected in common to all devices within a JTAG chain.TRSTTest Reset – this signal can be used to reset the devices in a JTAG chain. This is an optional signal.The JTAG interface can be used to program one or more devices.
Interfacing with multiple devices is accomplished by setting up a JTAG daisy chain. Depending on loading, five devices can typically be driven in a chain before buffering is required to ensure signal integrity. To set up a chain, all signals except TDI and TDO are connected in a daisy chain to all of the devices. TDI and TDO are connected to each device in the chain in a cascaded configuration. The TDO pin is connected to the TDI input pin of the next device in the chain. The loop is closed by connecting the final device's TDO signal back to the master device. Depending on the chain configuration implementation it should be possible to configure the FPGA device and the FPGA configuration PROM as well as being able to communicate with any other device on the JTAG chain.
JTAG Configuration chain interfaceJTAG has emerged as the preferred configuration and debug interface for most ISP-capable integrated circuits. A new standard, IEEE 1532, has been developed, which builds on the momentum of the JTAG standard. IEEE 1532 supports concurrent programming of ISP-capable devices regardless of the component manufacturer or device. The standard separates data and algorithm, allowing simplified design updates since a design does not need to be recompiled. The standard provides a standardized interface for initialization and events occurring during configuration. The specification assures that device pins are in defined states at all times.
A done bit is provided to assure the device has been programmed. The ultimate goal of this new standard is to provide a seamless unified programming capability for all ISP-capable devices. 10.4.1 Understanding Pin Operational StatesThe hardware design must take into account the state of all pins in each of the possible FPGA modes exhibited from power-up through configured operation. There are many different categories of FPGA pins including general I/O, dedicated inputs and outputs, configuration pins and special function pins. Each of these device pin groups may exhibit different characteristics in each of the three FPGA modes. It is critical that the design correctly handle all possible pin interactions with board-level signals.A few examples of why this can be critical follow. Joseph Yiu, in, 2014 4.7 DebugAs software gets more complex, debug features are becoming more and more important in modern processor architectures.
Although their designs are compact, the Cortex ®-M3 and Cortex-M4 processors include comprehensive debugging features such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.There are two types of interfaces provided in the Cortex-M processors: debug and trace. The debug interface allows a debug adaptor to connect to a Cortex-M microcontroller to control the debug features and access the memory space on the chip. The Cortex-M processor supports the traditional JTAG protocol, which uses either 4 or 5 pins, or a newer 2-pin protocol called Serial Wire Debug (SWD). The SWD protocol was developed by ARM ®, and can handle the same debug features as in JTAG in just two pins, without any loss of debug performance. Many commercially available debug adaptors, such as the ULINK 2 or ULINK Pro products from Keil™, support both protocols. The two protocols can use the same connector, with JTAG TCK shared with the Serial Wire clock, and JTAG TMS shared with the Serial Wire Data, which is bidirectional ( Figure 4.28). Both protocols are widely supported by different debug adaptors from different companies.
Debug connectionThe trace interface is used to collect information from the processor during runtime such as data, event, profiling information, or even complete details of program execution. Two types of trace interface are supported: a single pin protocol called Serial Wire Viewer (SWV) and a multi-pin protocol called Trace Port ( Figure 4.29).SWV is a low-cost solution that has a lower trace data bandwidth limit. However, the bandwidth is still large enough to handle capturing of selective data trace, event trace, and basic profiling. The output signal, which is called Serial Wire Output (SWO), can be shared with the JTAG TDO pin so that you only need one standard JTAG/SWD connector for both debug and trace. (Obviously, the trace data can only be captured when the two-pin SWD protocol is used for debugging.). The Trace Port mode requires one clock pin and several data pins. The number of data pins used is configurable, and in most cases the Cortex-M3 or Cortex-M4 microcontrollers support a maximum of four data pins (a total of five pins including the clock).
The Trace Port mode supports a much higher trace data bandwidth than SWV. You can also use Trace Port mode with fewer pins if needed; for example, when some of the Trace Data pins are multiplexed with I/O functions and you need to use some of these I/O pins for your application. Trace connection (SWO or Trace Port mode)The high trace data bandwidth of the Trace Port model allows real-time recording of program execution information, in addition to the other trace information you can collect using SWV. The real-time program trace requires a companion component called Embedded Trace Macrocell (ETM) in the chip. This is an optional component for the Cortex-M3 and Cortex-M4 processors. Some of the Cortex-M3 and Cortex-M4 microcontrollers do not have ETM and therefore do not provide program/instruction trace.To capture trace data, you can use a low-cost debug adaptor such as Keil ULINK-2 or Segger J-Link, which can capture data through the SWV interface. Or you can use advanced products such as Keil ULINK Pro or Segger J-Trace to capture trace data in trace port mode.There are a number of other debug components inside the Cortex-M3 and Cortex-M4 processors.
For example, the Instrumentation Trace Macrocell (ITM) allows program code running on the microcontroller to generate data to be output through the trace interface. The data can then be displayed on a debugger window.
More information about various debug features are covered in Chapter 14. Appendix H also provides information about standard debug connectors used by various debug adaptors.
Popular Posts
Serial Wire Debug (SWD) Toolkit for LabVIEW by RAFA Solutions easily implements and integrates Serial Wire Debug protocol in custom applications. Feb 22, 2015 Serial Wire Debug (SWD) Serial Wire Debug (SWD) is a debug port similar to JTAG, and provides the same debug capabilities (run, stop on breakpoints, single-step) but with fewer pins. It replaces the JTAG connector with a 2-pin interface (one clock pin and one bi-directional data pin). The SWD port itself does not provide for real-time tracing.
Passive debugging: The simplest method is passive debugging, wherein the device being debugged sends out debug messages over a debug interface, and the debugger host captures and displays the messages. These debug messages can possibly be any text or data that helps in identifying the state, control, or data flow of the device being debugged. It is notable that the debugger only receives the messages sent out by the debugged and displays them. The responsibility of spitting out useful messages is on the debugged. The debugger cannot ask for data that it wants, because the communication is one directional.
This kind of setup can be visualized as in Figure 12.1. ■ Figure 12.1. A view of a debugger operation in passive mode.This kind of setup is nonintrusive, and the debugged and debugger do not require major infrastructure, neither do they have to follow any specific protocol. All that is required is that the debugged initializes and starts writing to the debug interface; the debugger, if connected and available, will configure itself to the baud rate of the debugged and start receiving messages. Because of its simplicity and innocuousness, this kind of setup is used during early boot flow of system, devices, and CPUs. Active debugging: The second scenario (see Figure 12.2) is when the device being debugged is actively involved in inquiring, and/or changing the state, control, or data flow of the device being debugged. In this case, in addition to the messages (data/state) that the debugged sends out, the debugger can ask for additional data needed for debug.
Not only can the debugger ask for additional data and state information, but also the debugger can change the control flow (halt the execution of the debugged, or change the program counter) or change the data, thereby triggering a control flow change, and so on. The debugger sends a command over the debug interface to the debugged, and the debugged responds to the commands.
Since there is back-and-forth communication of command and data, a client is needed on both sides that listens from the other end and responds appropriately. Due to the need for clients, this mechanism can be employed only after the basic infrastructure is up and the clients are up and working. Joseph Yiu, in, 2014 14.2.2 Processor debug interfaceNow let’s look at the debug interface in a bit more detail.In order to allow the debugger to access various debug features, a debug interface is needed. Many microcontrollers support a serial protocol called JTAG – Joint Test Action Group. The JTAG protocol is an industry standard protocol (IEEE 1149.1) and can be used for various functions such as chip-level or PCB-level testing, as well as giving access to debug features inside microcontrollers.While JTAG is sufficient for many debug usage scenarios, it needs at least four pins: TCK, TDI, TMS, and TDO; the reset signal nTRST is optional. For some microcontroller devices with low pin counts, such as 28-pin packages, using four pins for debugging is too many.
As a result, ARM ® developed the Serial Wire debug protocol, which only needs two pins: SWCLK and SWDIO. The Serial Wire debug protocol provides the same debug access features and also supports parity error detection, which enables better reliability in systems with higher electrical noise. Therefore the Serial Wire debug protocol is very attractive for many microcontroller vendors and users. Pin sharing between JTAG and Serial Wire debug protocolMany Cortex ®-M3 and Cortex-M4 microcontrollers support both JTAG and Serial Wire debug protocols. You can dynamically switch between the two modes using special bit patterns on the TMS/SWDIO pin. In order to achieve lower power consumption, some microcontrollers omit the JTAG debug protocol capability and support only the Serial Wire debug protocol.Typically Cortex-M0 and Cortex-M0+ microcontrollers only support one of these debug protocols to reduce power: mostly the Serial Wire debug protocol because fewer pins are needed.When using the Serial Wire debug protocol, the TDO pin can be used for trace operation with SWO (Serial Wire Output), as outlined in section 14.1.2. Many low-cost debug adaptors support trace capture via SWO.
Connection of the AHB-AP in the Cortex-M3.The CSW register can control the transfer direction (read/write), transfer size, transfer types, and so on. The TAR register is used to specify the transfer address, and the DRW register is used to carry out the data transfer operation (transfer starts when this register is accessed).The data register DRW represents exactly what is shown on the bus. For half word and byte transfers, the required data will have to be manually shifted to the correct byte lane by debugger software. For example, if you want to carry out a data transfer of half word size to address 0x1002, you need to have the data on bit 31:16 of the DRW register.
The AHB-AP can generate unaligned transfers, but it does not rotate the result data based on the address offset. So, the debugger software will have to either rotate the data manually or split an unaligned data access into several accesses if needed.Other registers in the AHB-AP provide additional features. For example, the AHB-AP provides four banked registers and an automatic address increment function so that access to memory within close range or sequential transfers can be speeded up.
The AHB-AP also contains a register called base address to indicate the address of ROM table.In the CSW register, there is one bit called MasterType. This is normally set to 1 so that hardware receiving the transfer from AHB-AP knows that it is from the debugger.
However, the debugger can pretend to be the core by clearing this bit. In this case, the transfer received by the device attached to the AHB system should behave as though it is accessed by the processor. This is useful for testing peripherals with FIFO that can behave differently when accessed by the debugger. Joseph Yiu, in, 2010 2.10 Debugging SupportThe Cortex-M3 processor includes a number of debugging features, such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.The debugging hardware of the Cortex-M3 processor is based on the CoreSight™ architecture. Unlike traditional ARM processors, the CPU core itself does not have a Joint Test Action Group (JTAG) interface. Instead, a debug interface module is decoupled from the core, and a bus interface called the Debug Access Port (DAP) is provided at the core level. Through this bus interface, external debuggers can access control registers to debug hardware as well as system memory, even when the processor is running.
The control of this bus interface is carried out by a Debug Port (DP) device. The DPs currently available are the Serial-Wire JTAG Debug Port (SWJ-DP) (supports the traditional JTAG protocol as well as the Serial-Wire protocol) or the SW-DP (supports the Serial-Wire protocol only). A JTAG-DP module from the ARM CoreSight product family can also be used.
Chip manufacturers can choose to attach one of these DP modules to provide the debug interface.Chip manufacturers can also include an Embedded Trace Macrocell (ETM) to allow instruction trace. Trace information is output via the Trace Port Interface Unit (TPIU), and the debug host (usually a Personal Computer PC) can then collect the executed instruction information via external trace-capturing hardware.Within the Cortex-M3 processor, a number of events can be used to trigger debug actions. Debug events can be breakpoints, watchpoints, fault conditions, or external debugging request input signals. When a debug event takes place, the Cortex-M3 processor can either enter halt mode or execute the debug monitor exception handler.The data watchpoint function is provided by a Data Watchpoint and Trace (DWT) unit in the Cortex-M3 processor. This can be used to stop the processor (or trigger the debug monitor exception routine) or to generate data trace information. When data trace is used, the traced data can be output via the TPIU.
(In the CoreSight architecture, multiple trace devices can share one single trace port.)In addition to these basic debugging features, the Cortex-M3 processor also provides a Flash Patch and Breakpoint (FPB) unit that can provide a simple breakpoint function or remap an instruction access from Flash to a different location in SRAM.An Instrumentation Trace Macrocell (ITM) provides a new way for developers to output data to a debugger. By writing data to register memory in the ITM, a debugger can collect the data via a trace interface and display or process them. This method is easy to use and faster than JTAG output.All these debugging components are controlled via the DAP interface bus on the Cortex-M3 or by a program running on the processor core, and all trace information is accessible from the TPIU.
Aside from memory, peripheral options, and operation speed, a number of other factors make one Cortex™-M3 product different from another. The Cortex-M3 design supplied by ARM contains a number of features that are configurable, such as.Number of external interrupts.Number of interrupt priority levels (width of priority-level registers).With Memory Protection Unit (MPU) or without MPU.With Embedded Trace Macrocell (ETM) or without ETM.Choice of debug interface (Serial-Wire (SW), Joint Test Action Group (JTAG), or both)In most projects, the features and specification of the microcontroller will certainly affect your choice of Cortex-M3 product.Peripherals: For many applications, peripheral support is the main criterion.
More peripherals might be good, but this also affects the microcontroller\'s power consumption and price.Memory: Cortex-M3 microcontrollers can have Flash memory from several kilobytes to several megabytes. In addition, the size of the internal memory might also be important. Usually these factors will have a direct impact on the price.Clock speed: The Cortex-M3 design from ARM can easily reach more than 100 MHz, even in 0.18 µm processes.
However, manufacturers might specify a lower operation speed due to limitations of memory access speed.Footprint: The Cortex-M3 can be available in many different packages, depending on the chip manufacturer\'s decision. Many Cortex-M3 devices are available in low pin count packages, making them ideal for low-cost manufacturing environments.Currently, a number of microcontroller vendors are already shipping Cortex-M3-based microcontrollers, and a number of other vendors will also soon be shipping Cortex-M3 products. Here, we list a number of them:Texas Instruments (formerly LuminaryMicro): The Stellaris Cortex-M3 microcontroller product range has over 100 devices in the family, including devices with 10/100 Ethernet MAC and PHY, USB, CAN, SPI, I 2C, I 2S, and so on. ST Microelectronics: The ST\'s Cortex-M3 products included several product lines as follows:.STM32 connectivity line for feature-packed device supporting USB On-The-Go (USB OTG), Ethernet, and memory cards.STM32L for ultralow-power applications with analog and LCD interface support.
The Cortex-M3 processor is released as a processor subsystem (see Figure 6.3). The CPU core itself is closely coupled to the interrupt controller (NVIC) and various debug logic blocks:.CM3Core: The Cortex-M3 core contains the registers, ALU, data path, and bus interface.NVIC: The NVIC is a built-in interrupt controller. The number of interrupts is customized by chip manufacturers.
The NVIC is closely coupled to the CPU core and contains a number of system control registers. It supports the nested interrupt handling, which means that with the Cortex-M3, nested interrupt handling is very simple. It also comes with a vectored interrupt feature so that when an interrupt occurs, it can enter the corresponding interrupt handler routine directly, without using a shared handler to determine which interrupt has occurred.SYSTICK Timer: The System Tick (SYSTICK) Timer is a basic countdown timer that can be used to generate interrupts at regular time intervals, even when the system is in sleep mode. It makes OS porting between Cortex-M3 devices much easier because there is no need to change the OS\'s system timer code.
The SYSTICK Timer is implemented as part of the NVIC.WIC: A module interface with NVIC but separated from the main processor design to allow the system to wake up from interrupt events while the processor (including the NVIC) is completely stopped or powered down. This module is new from the Cortex-M3 revision 2 and is optional.MPU: The MPU block is optional. This means that some versions of the Cortex-M3 might have the MPU and some might not. If it is included, the MPU can be used to protect memory contents by, for example, making memory regions read-only or preventing user applications from accessing privileged applications data.BusMatrix: A BusMatrix is used as the heart of the Cortex-M3 internal bus system.
It is an AHB interconnection network, allowing transfer to take place on different buses simultaneously unless both bus masters are trying to access the same memory region. The BusMatrix also provides additional data transfer management, including a write buffer as well as bit-oriented operations (bit-band).AHB to APB: An AHB-to-APB bus bridge is used to connect a number of APB devices such as debugging components to the private peripheral bus in the Cortex-M3 processor. In addition, the Cortex-M3 allows chip manufacturers to attach additional APB devices to the external private peripheral bus (PPB) using this APB bus.The rest of the components in the block diagram are for debugging support and normally should not be used by application code.SW-DP/SWJ-DP: The Serial Wire Debug Port (SW-DP)/Serial Wire JTAG Debug Port (SWJ-DP) work together with the AHB Access Port (AHB-AP) so that external debuggers can generate AHB transfers to control debug activities. There is no JTAG scan chain inside the processor core of the Cortex-M3; most debugging functions are controlled by the NVIC registers through AHB accesses. SWJ-DP supports both the Serial Wire Protocol and the JTAG Protocol, whereas SW-DP can support only the Serial Wire Protocol.AHB-AP: The AHB-AP provides access to the whole Cortex-M3 memory through a few registers. This block is controlled by the SW-DP/SWJ-DP through a generic debug interface called the Debug Access Port (DAP). To carry out debugging functions, the external debugging hardware needs to access the AHB-AP through the SW-DP/SWJ-DP to generate the required AHB transfers.ETM: The ETM is an optional component for instruction trace, so some Cortex-M3 products might not have real-time instruction trace capability.
Trace information is output to the trace port through TPIU. The ETM control registers are memory mapped, which can be controlled by the debugger through the DAP.DWT: The DWT allows data watchpoints to be set up. When a data address or data value match is found, the match hit event can be used to generate watchpoint events to activate the debugger, generate data trace information, or activate the ETM.ITM: The ITM can be used in several ways. Software can write to this module directly to output information to TPIU, or the DWT matching events can be used to generate data trace packets through ITM for output into a trace data stream.TPIU: The TPIU is used to interface with external trace hardware such as trace port analyzers.
Internal to the Cortex-M3, trace information is formatted as Advanced Trace Bus (ATB) packets, and the TPIU reformats the data to allow data to be captured by external devices.FPB: The FPB is used to provide Flash Patch and Breakpoint functionalities. Star trek enterprise season 5 torrents download. Flash Patch means that if an instruction access by the CPU matches a certain address, the address can be remapped to a different location so that a different value is fetched. Alternatively, the matched address can be used to trigger a breakpoint event. The Flash Patch feature is very useful for testing, such as adding diagnosis program code to a device that cannot be used in normal situations unless the FPB is used to change the program control.ROM table: A small ROM table is provided. This is simply a small lookup table to provide memory map information for various system devices and debugging components.
Debugging systems use this table to locate the memory addresses of debugging components. In most cases, the memory map should be fixed to the standard memory location, as documented in the Cortex-M3 Technical Reference Manual (TRM) Ref. 1, but because some of the debugging components are optional and additional components can be added, individual chip manufacturers might want to customize their chip\'s debugging features. In this case, the ROM table must be customized and used for debugging software to determine the correct memory map and hence detect the type of debugging components available. JTAG SignalsTDITest Data In – this signal is the serial data stream received into the TDI pin of a device in a JTAG chain.TDOTest Data Out – this signal is the serial data stream transmitted from the TDO pin to the TDI pin of the next device in a JTAG chain.TCKTest Clock – this is the clock signal for JTAG communication, and must be connected to the TCK pin on all target ISP devices that share the same data stream. This signal should be given special routing consideration since it is operational critical.TMSTest Mode Select – this is the JTAG mode signal that establishes the appropriate TAP state transitions for each target ISP device.
It will be connected in common to all devices within a JTAG chain.TRSTTest Reset – this signal can be used to reset the devices in a JTAG chain. This is an optional signal.The JTAG interface can be used to program one or more devices.
Interfacing with multiple devices is accomplished by setting up a JTAG daisy chain. Depending on loading, five devices can typically be driven in a chain before buffering is required to ensure signal integrity. To set up a chain, all signals except TDI and TDO are connected in a daisy chain to all of the devices. TDI and TDO are connected to each device in the chain in a cascaded configuration. The TDO pin is connected to the TDI input pin of the next device in the chain. The loop is closed by connecting the final device\'s TDO signal back to the master device. Depending on the chain configuration implementation it should be possible to configure the FPGA device and the FPGA configuration PROM as well as being able to communicate with any other device on the JTAG chain.
JTAG Configuration chain interfaceJTAG has emerged as the preferred configuration and debug interface for most ISP-capable integrated circuits. A new standard, IEEE 1532, has been developed, which builds on the momentum of the JTAG standard. IEEE 1532 supports concurrent programming of ISP-capable devices regardless of the component manufacturer or device. The standard separates data and algorithm, allowing simplified design updates since a design does not need to be recompiled. The standard provides a standardized interface for initialization and events occurring during configuration. The specification assures that device pins are in defined states at all times.
A done bit is provided to assure the device has been programmed. The ultimate goal of this new standard is to provide a seamless unified programming capability for all ISP-capable devices. 10.4.1 Understanding Pin Operational StatesThe hardware design must take into account the state of all pins in each of the possible FPGA modes exhibited from power-up through configured operation. There are many different categories of FPGA pins including general I/O, dedicated inputs and outputs, configuration pins and special function pins. Each of these device pin groups may exhibit different characteristics in each of the three FPGA modes. It is critical that the design correctly handle all possible pin interactions with board-level signals.A few examples of why this can be critical follow. Joseph Yiu, in, 2014 4.7 DebugAs software gets more complex, debug features are becoming more and more important in modern processor architectures.
Although their designs are compact, the Cortex ®-M3 and Cortex-M4 processors include comprehensive debugging features such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.There are two types of interfaces provided in the Cortex-M processors: debug and trace. The debug interface allows a debug adaptor to connect to a Cortex-M microcontroller to control the debug features and access the memory space on the chip. The Cortex-M processor supports the traditional JTAG protocol, which uses either 4 or 5 pins, or a newer 2-pin protocol called Serial Wire Debug (SWD). The SWD protocol was developed by ARM ®, and can handle the same debug features as in JTAG in just two pins, without any loss of debug performance. Many commercially available debug adaptors, such as the ULINK 2 or ULINK Pro products from Keil™, support both protocols. The two protocols can use the same connector, with JTAG TCK shared with the Serial Wire clock, and JTAG TMS shared with the Serial Wire Data, which is bidirectional ( Figure 4.28). Both protocols are widely supported by different debug adaptors from different companies.
Debug connectionThe trace interface is used to collect information from the processor during runtime such as data, event, profiling information, or even complete details of program execution. Two types of trace interface are supported: a single pin protocol called Serial Wire Viewer (SWV) and a multi-pin protocol called Trace Port ( Figure 4.29).SWV is a low-cost solution that has a lower trace data bandwidth limit. However, the bandwidth is still large enough to handle capturing of selective data trace, event trace, and basic profiling. The output signal, which is called Serial Wire Output (SWO), can be shared with the JTAG TDO pin so that you only need one standard JTAG/SWD connector for both debug and trace. (Obviously, the trace data can only be captured when the two-pin SWD protocol is used for debugging.). The Trace Port mode requires one clock pin and several data pins. The number of data pins used is configurable, and in most cases the Cortex-M3 or Cortex-M4 microcontrollers support a maximum of four data pins (a total of five pins including the clock).
The Trace Port mode supports a much higher trace data bandwidth than SWV. You can also use Trace Port mode with fewer pins if needed; for example, when some of the Trace Data pins are multiplexed with I/O functions and you need to use some of these I/O pins for your application. Trace connection (SWO or Trace Port mode)The high trace data bandwidth of the Trace Port model allows real-time recording of program execution information, in addition to the other trace information you can collect using SWV. The real-time program trace requires a companion component called Embedded Trace Macrocell (ETM) in the chip. This is an optional component for the Cortex-M3 and Cortex-M4 processors. Some of the Cortex-M3 and Cortex-M4 microcontrollers do not have ETM and therefore do not provide program/instruction trace.To capture trace data, you can use a low-cost debug adaptor such as Keil ULINK-2 or Segger J-Link, which can capture data through the SWV interface. Or you can use advanced products such as Keil ULINK Pro or Segger J-Trace to capture trace data in trace port mode.There are a number of other debug components inside the Cortex-M3 and Cortex-M4 processors.
For example, the Instrumentation Trace Macrocell (ITM) allows program code running on the microcontroller to generate data to be output through the trace interface. The data can then be displayed on a debugger window.
More information about various debug features are covered in Chapter 14. Appendix H also provides information about standard debug connectors used by various debug adaptors.
...'>Serial Wire Debug Specification(31.03.2020)Serial Wire Debug (SWD) Toolkit for LabVIEW by RAFA Solutions easily implements and integrates Serial Wire Debug protocol in custom applications. Feb 22, 2015 Serial Wire Debug (SWD) Serial Wire Debug (SWD) is a debug port similar to JTAG, and provides the same debug capabilities (run, stop on breakpoints, single-step) but with fewer pins. It replaces the JTAG connector with a 2-pin interface (one clock pin and one bi-directional data pin). The SWD port itself does not provide for real-time tracing.
Passive debugging: The simplest method is passive debugging, wherein the device being debugged sends out debug messages over a debug interface, and the debugger host captures and displays the messages. These debug messages can possibly be any text or data that helps in identifying the state, control, or data flow of the device being debugged. It is notable that the debugger only receives the messages sent out by the debugged and displays them. The responsibility of spitting out useful messages is on the debugged. The debugger cannot ask for data that it wants, because the communication is one directional.
This kind of setup can be visualized as in Figure 12.1. ■ Figure 12.1. A view of a debugger operation in passive mode.This kind of setup is nonintrusive, and the debugged and debugger do not require major infrastructure, neither do they have to follow any specific protocol. All that is required is that the debugged initializes and starts writing to the debug interface; the debugger, if connected and available, will configure itself to the baud rate of the debugged and start receiving messages. Because of its simplicity and innocuousness, this kind of setup is used during early boot flow of system, devices, and CPUs. Active debugging: The second scenario (see Figure 12.2) is when the device being debugged is actively involved in inquiring, and/or changing the state, control, or data flow of the device being debugged. In this case, in addition to the messages (data/state) that the debugged sends out, the debugger can ask for additional data needed for debug.
Not only can the debugger ask for additional data and state information, but also the debugger can change the control flow (halt the execution of the debugged, or change the program counter) or change the data, thereby triggering a control flow change, and so on. The debugger sends a command over the debug interface to the debugged, and the debugged responds to the commands.
Since there is back-and-forth communication of command and data, a client is needed on both sides that listens from the other end and responds appropriately. Due to the need for clients, this mechanism can be employed only after the basic infrastructure is up and the clients are up and working. Joseph Yiu, in, 2014 14.2.2 Processor debug interfaceNow let’s look at the debug interface in a bit more detail.In order to allow the debugger to access various debug features, a debug interface is needed. Many microcontrollers support a serial protocol called JTAG – Joint Test Action Group. The JTAG protocol is an industry standard protocol (IEEE 1149.1) and can be used for various functions such as chip-level or PCB-level testing, as well as giving access to debug features inside microcontrollers.While JTAG is sufficient for many debug usage scenarios, it needs at least four pins: TCK, TDI, TMS, and TDO; the reset signal nTRST is optional. For some microcontroller devices with low pin counts, such as 28-pin packages, using four pins for debugging is too many.
As a result, ARM ® developed the Serial Wire debug protocol, which only needs two pins: SWCLK and SWDIO. The Serial Wire debug protocol provides the same debug access features and also supports parity error detection, which enables better reliability in systems with higher electrical noise. Therefore the Serial Wire debug protocol is very attractive for many microcontroller vendors and users. Pin sharing between JTAG and Serial Wire debug protocolMany Cortex ®-M3 and Cortex-M4 microcontrollers support both JTAG and Serial Wire debug protocols. You can dynamically switch between the two modes using special bit patterns on the TMS/SWDIO pin. In order to achieve lower power consumption, some microcontrollers omit the JTAG debug protocol capability and support only the Serial Wire debug protocol.Typically Cortex-M0 and Cortex-M0+ microcontrollers only support one of these debug protocols to reduce power: mostly the Serial Wire debug protocol because fewer pins are needed.When using the Serial Wire debug protocol, the TDO pin can be used for trace operation with SWO (Serial Wire Output), as outlined in section 14.1.2. Many low-cost debug adaptors support trace capture via SWO.
Connection of the AHB-AP in the Cortex-M3.The CSW register can control the transfer direction (read/write), transfer size, transfer types, and so on. The TAR register is used to specify the transfer address, and the DRW register is used to carry out the data transfer operation (transfer starts when this register is accessed).The data register DRW represents exactly what is shown on the bus. For half word and byte transfers, the required data will have to be manually shifted to the correct byte lane by debugger software. For example, if you want to carry out a data transfer of half word size to address 0x1002, you need to have the data on bit 31:16 of the DRW register.
The AHB-AP can generate unaligned transfers, but it does not rotate the result data based on the address offset. So, the debugger software will have to either rotate the data manually or split an unaligned data access into several accesses if needed.Other registers in the AHB-AP provide additional features. For example, the AHB-AP provides four banked registers and an automatic address increment function so that access to memory within close range or sequential transfers can be speeded up.
The AHB-AP also contains a register called base address to indicate the address of ROM table.In the CSW register, there is one bit called MasterType. This is normally set to 1 so that hardware receiving the transfer from AHB-AP knows that it is from the debugger.
However, the debugger can pretend to be the core by clearing this bit. In this case, the transfer received by the device attached to the AHB system should behave as though it is accessed by the processor. This is useful for testing peripherals with FIFO that can behave differently when accessed by the debugger. Joseph Yiu, in, 2010 2.10 Debugging SupportThe Cortex-M3 processor includes a number of debugging features, such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.The debugging hardware of the Cortex-M3 processor is based on the CoreSight™ architecture. Unlike traditional ARM processors, the CPU core itself does not have a Joint Test Action Group (JTAG) interface. Instead, a debug interface module is decoupled from the core, and a bus interface called the Debug Access Port (DAP) is provided at the core level. Through this bus interface, external debuggers can access control registers to debug hardware as well as system memory, even when the processor is running.
The control of this bus interface is carried out by a Debug Port (DP) device. The DPs currently available are the Serial-Wire JTAG Debug Port (SWJ-DP) (supports the traditional JTAG protocol as well as the Serial-Wire protocol) or the SW-DP (supports the Serial-Wire protocol only). A JTAG-DP module from the ARM CoreSight product family can also be used.
Chip manufacturers can choose to attach one of these DP modules to provide the debug interface.Chip manufacturers can also include an Embedded Trace Macrocell (ETM) to allow instruction trace. Trace information is output via the Trace Port Interface Unit (TPIU), and the debug host (usually a Personal Computer PC) can then collect the executed instruction information via external trace-capturing hardware.Within the Cortex-M3 processor, a number of events can be used to trigger debug actions. Debug events can be breakpoints, watchpoints, fault conditions, or external debugging request input signals. When a debug event takes place, the Cortex-M3 processor can either enter halt mode or execute the debug monitor exception handler.The data watchpoint function is provided by a Data Watchpoint and Trace (DWT) unit in the Cortex-M3 processor. This can be used to stop the processor (or trigger the debug monitor exception routine) or to generate data trace information. When data trace is used, the traced data can be output via the TPIU.
(In the CoreSight architecture, multiple trace devices can share one single trace port.)In addition to these basic debugging features, the Cortex-M3 processor also provides a Flash Patch and Breakpoint (FPB) unit that can provide a simple breakpoint function or remap an instruction access from Flash to a different location in SRAM.An Instrumentation Trace Macrocell (ITM) provides a new way for developers to output data to a debugger. By writing data to register memory in the ITM, a debugger can collect the data via a trace interface and display or process them. This method is easy to use and faster than JTAG output.All these debugging components are controlled via the DAP interface bus on the Cortex-M3 or by a program running on the processor core, and all trace information is accessible from the TPIU.
Aside from memory, peripheral options, and operation speed, a number of other factors make one Cortex™-M3 product different from another. The Cortex-M3 design supplied by ARM contains a number of features that are configurable, such as.Number of external interrupts.Number of interrupt priority levels (width of priority-level registers).With Memory Protection Unit (MPU) or without MPU.With Embedded Trace Macrocell (ETM) or without ETM.Choice of debug interface (Serial-Wire (SW), Joint Test Action Group (JTAG), or both)In most projects, the features and specification of the microcontroller will certainly affect your choice of Cortex-M3 product.Peripherals: For many applications, peripheral support is the main criterion.
More peripherals might be good, but this also affects the microcontroller\'s power consumption and price.Memory: Cortex-M3 microcontrollers can have Flash memory from several kilobytes to several megabytes. In addition, the size of the internal memory might also be important. Usually these factors will have a direct impact on the price.Clock speed: The Cortex-M3 design from ARM can easily reach more than 100 MHz, even in 0.18 µm processes.
However, manufacturers might specify a lower operation speed due to limitations of memory access speed.Footprint: The Cortex-M3 can be available in many different packages, depending on the chip manufacturer\'s decision. Many Cortex-M3 devices are available in low pin count packages, making them ideal for low-cost manufacturing environments.Currently, a number of microcontroller vendors are already shipping Cortex-M3-based microcontrollers, and a number of other vendors will also soon be shipping Cortex-M3 products. Here, we list a number of them:Texas Instruments (formerly LuminaryMicro): The Stellaris Cortex-M3 microcontroller product range has over 100 devices in the family, including devices with 10/100 Ethernet MAC and PHY, USB, CAN, SPI, I 2C, I 2S, and so on. ST Microelectronics: The ST\'s Cortex-M3 products included several product lines as follows:.STM32 connectivity line for feature-packed device supporting USB On-The-Go (USB OTG), Ethernet, and memory cards.STM32L for ultralow-power applications with analog and LCD interface support.
The Cortex-M3 processor is released as a processor subsystem (see Figure 6.3). The CPU core itself is closely coupled to the interrupt controller (NVIC) and various debug logic blocks:.CM3Core: The Cortex-M3 core contains the registers, ALU, data path, and bus interface.NVIC: The NVIC is a built-in interrupt controller. The number of interrupts is customized by chip manufacturers.
The NVIC is closely coupled to the CPU core and contains a number of system control registers. It supports the nested interrupt handling, which means that with the Cortex-M3, nested interrupt handling is very simple. It also comes with a vectored interrupt feature so that when an interrupt occurs, it can enter the corresponding interrupt handler routine directly, without using a shared handler to determine which interrupt has occurred.SYSTICK Timer: The System Tick (SYSTICK) Timer is a basic countdown timer that can be used to generate interrupts at regular time intervals, even when the system is in sleep mode. It makes OS porting between Cortex-M3 devices much easier because there is no need to change the OS\'s system timer code.
The SYSTICK Timer is implemented as part of the NVIC.WIC: A module interface with NVIC but separated from the main processor design to allow the system to wake up from interrupt events while the processor (including the NVIC) is completely stopped or powered down. This module is new from the Cortex-M3 revision 2 and is optional.MPU: The MPU block is optional. This means that some versions of the Cortex-M3 might have the MPU and some might not. If it is included, the MPU can be used to protect memory contents by, for example, making memory regions read-only or preventing user applications from accessing privileged applications data.BusMatrix: A BusMatrix is used as the heart of the Cortex-M3 internal bus system.
It is an AHB interconnection network, allowing transfer to take place on different buses simultaneously unless both bus masters are trying to access the same memory region. The BusMatrix also provides additional data transfer management, including a write buffer as well as bit-oriented operations (bit-band).AHB to APB: An AHB-to-APB bus bridge is used to connect a number of APB devices such as debugging components to the private peripheral bus in the Cortex-M3 processor. In addition, the Cortex-M3 allows chip manufacturers to attach additional APB devices to the external private peripheral bus (PPB) using this APB bus.The rest of the components in the block diagram are for debugging support and normally should not be used by application code.SW-DP/SWJ-DP: The Serial Wire Debug Port (SW-DP)/Serial Wire JTAG Debug Port (SWJ-DP) work together with the AHB Access Port (AHB-AP) so that external debuggers can generate AHB transfers to control debug activities. There is no JTAG scan chain inside the processor core of the Cortex-M3; most debugging functions are controlled by the NVIC registers through AHB accesses. SWJ-DP supports both the Serial Wire Protocol and the JTAG Protocol, whereas SW-DP can support only the Serial Wire Protocol.AHB-AP: The AHB-AP provides access to the whole Cortex-M3 memory through a few registers. This block is controlled by the SW-DP/SWJ-DP through a generic debug interface called the Debug Access Port (DAP). To carry out debugging functions, the external debugging hardware needs to access the AHB-AP through the SW-DP/SWJ-DP to generate the required AHB transfers.ETM: The ETM is an optional component for instruction trace, so some Cortex-M3 products might not have real-time instruction trace capability.
Trace information is output to the trace port through TPIU. The ETM control registers are memory mapped, which can be controlled by the debugger through the DAP.DWT: The DWT allows data watchpoints to be set up. When a data address or data value match is found, the match hit event can be used to generate watchpoint events to activate the debugger, generate data trace information, or activate the ETM.ITM: The ITM can be used in several ways. Software can write to this module directly to output information to TPIU, or the DWT matching events can be used to generate data trace packets through ITM for output into a trace data stream.TPIU: The TPIU is used to interface with external trace hardware such as trace port analyzers.
Internal to the Cortex-M3, trace information is formatted as Advanced Trace Bus (ATB) packets, and the TPIU reformats the data to allow data to be captured by external devices.FPB: The FPB is used to provide Flash Patch and Breakpoint functionalities. Star trek enterprise season 5 torrents download. Flash Patch means that if an instruction access by the CPU matches a certain address, the address can be remapped to a different location so that a different value is fetched. Alternatively, the matched address can be used to trigger a breakpoint event. The Flash Patch feature is very useful for testing, such as adding diagnosis program code to a device that cannot be used in normal situations unless the FPB is used to change the program control.ROM table: A small ROM table is provided. This is simply a small lookup table to provide memory map information for various system devices and debugging components.
Debugging systems use this table to locate the memory addresses of debugging components. In most cases, the memory map should be fixed to the standard memory location, as documented in the Cortex-M3 Technical Reference Manual (TRM) Ref. 1, but because some of the debugging components are optional and additional components can be added, individual chip manufacturers might want to customize their chip\'s debugging features. In this case, the ROM table must be customized and used for debugging software to determine the correct memory map and hence detect the type of debugging components available. JTAG SignalsTDITest Data In – this signal is the serial data stream received into the TDI pin of a device in a JTAG chain.TDOTest Data Out – this signal is the serial data stream transmitted from the TDO pin to the TDI pin of the next device in a JTAG chain.TCKTest Clock – this is the clock signal for JTAG communication, and must be connected to the TCK pin on all target ISP devices that share the same data stream. This signal should be given special routing consideration since it is operational critical.TMSTest Mode Select – this is the JTAG mode signal that establishes the appropriate TAP state transitions for each target ISP device.
It will be connected in common to all devices within a JTAG chain.TRSTTest Reset – this signal can be used to reset the devices in a JTAG chain. This is an optional signal.The JTAG interface can be used to program one or more devices.
Interfacing with multiple devices is accomplished by setting up a JTAG daisy chain. Depending on loading, five devices can typically be driven in a chain before buffering is required to ensure signal integrity. To set up a chain, all signals except TDI and TDO are connected in a daisy chain to all of the devices. TDI and TDO are connected to each device in the chain in a cascaded configuration. The TDO pin is connected to the TDI input pin of the next device in the chain. The loop is closed by connecting the final device\'s TDO signal back to the master device. Depending on the chain configuration implementation it should be possible to configure the FPGA device and the FPGA configuration PROM as well as being able to communicate with any other device on the JTAG chain.
JTAG Configuration chain interfaceJTAG has emerged as the preferred configuration and debug interface for most ISP-capable integrated circuits. A new standard, IEEE 1532, has been developed, which builds on the momentum of the JTAG standard. IEEE 1532 supports concurrent programming of ISP-capable devices regardless of the component manufacturer or device. The standard separates data and algorithm, allowing simplified design updates since a design does not need to be recompiled. The standard provides a standardized interface for initialization and events occurring during configuration. The specification assures that device pins are in defined states at all times.
A done bit is provided to assure the device has been programmed. The ultimate goal of this new standard is to provide a seamless unified programming capability for all ISP-capable devices. 10.4.1 Understanding Pin Operational StatesThe hardware design must take into account the state of all pins in each of the possible FPGA modes exhibited from power-up through configured operation. There are many different categories of FPGA pins including general I/O, dedicated inputs and outputs, configuration pins and special function pins. Each of these device pin groups may exhibit different characteristics in each of the three FPGA modes. It is critical that the design correctly handle all possible pin interactions with board-level signals.A few examples of why this can be critical follow. Joseph Yiu, in, 2014 4.7 DebugAs software gets more complex, debug features are becoming more and more important in modern processor architectures.
Although their designs are compact, the Cortex ®-M3 and Cortex-M4 processors include comprehensive debugging features such as program execution controls, including halting and stepping, instruction breakpoints, data watchpoints, registers and memory accesses, profiling, and traces.There are two types of interfaces provided in the Cortex-M processors: debug and trace. The debug interface allows a debug adaptor to connect to a Cortex-M microcontroller to control the debug features and access the memory space on the chip. The Cortex-M processor supports the traditional JTAG protocol, which uses either 4 or 5 pins, or a newer 2-pin protocol called Serial Wire Debug (SWD). The SWD protocol was developed by ARM ®, and can handle the same debug features as in JTAG in just two pins, without any loss of debug performance. Many commercially available debug adaptors, such as the ULINK 2 or ULINK Pro products from Keil™, support both protocols. The two protocols can use the same connector, with JTAG TCK shared with the Serial Wire clock, and JTAG TMS shared with the Serial Wire Data, which is bidirectional ( Figure 4.28). Both protocols are widely supported by different debug adaptors from different companies.
Debug connectionThe trace interface is used to collect information from the processor during runtime such as data, event, profiling information, or even complete details of program execution. Two types of trace interface are supported: a single pin protocol called Serial Wire Viewer (SWV) and a multi-pin protocol called Trace Port ( Figure 4.29).SWV is a low-cost solution that has a lower trace data bandwidth limit. However, the bandwidth is still large enough to handle capturing of selective data trace, event trace, and basic profiling. The output signal, which is called Serial Wire Output (SWO), can be shared with the JTAG TDO pin so that you only need one standard JTAG/SWD connector for both debug and trace. (Obviously, the trace data can only be captured when the two-pin SWD protocol is used for debugging.). The Trace Port mode requires one clock pin and several data pins. The number of data pins used is configurable, and in most cases the Cortex-M3 or Cortex-M4 microcontrollers support a maximum of four data pins (a total of five pins including the clock).
The Trace Port mode supports a much higher trace data bandwidth than SWV. You can also use Trace Port mode with fewer pins if needed; for example, when some of the Trace Data pins are multiplexed with I/O functions and you need to use some of these I/O pins for your application. Trace connection (SWO or Trace Port mode)The high trace data bandwidth of the Trace Port model allows real-time recording of program execution information, in addition to the other trace information you can collect using SWV. The real-time program trace requires a companion component called Embedded Trace Macrocell (ETM) in the chip. This is an optional component for the Cortex-M3 and Cortex-M4 processors. Some of the Cortex-M3 and Cortex-M4 microcontrollers do not have ETM and therefore do not provide program/instruction trace.To capture trace data, you can use a low-cost debug adaptor such as Keil ULINK-2 or Segger J-Link, which can capture data through the SWV interface. Or you can use advanced products such as Keil ULINK Pro or Segger J-Trace to capture trace data in trace port mode.There are a number of other debug components inside the Cortex-M3 and Cortex-M4 processors.
For example, the Instrumentation Trace Macrocell (ITM) allows program code running on the microcontroller to generate data to be output through the trace interface. The data can then be displayed on a debugger window.
More information about various debug features are covered in Chapter 14. Appendix H also provides information about standard debug connectors used by various debug adaptors.
...'>Serial Wire Debug Specification(31.03.2020)