PPC600 Family Debugger

Transcription

1 PPC600 Family Debugger TRACE32 Online Help TRACE32 Directory TRACE32 Index TRACE32 Documents... ICD In-Circuit Debugger... Processor Architecture Manuals... PQII, MPC5200, MPC603/7xx, MPC74xx... PPC600 Family Debugger... 1 Introduction... 5 Brief Overview of Documents for New Users 5 Warning... 6 Signal Level 6 ESD Protection 6 Target Design Requirement/Recommendations... 7 General 7 Quick Start... 8 Troubleshooting Problems with Memory Access 11 FAQ 12 Configuration System Overview 28 PowerPC 600 Family Specific Implementations Breakpoints 29 Software Breakpoints 29 Software Breakpoint Handling 30 On-chip Breakpoints 32 Software Breakpoints in Interrupt Handlers 33 Breakpoints in FLASH/ROM 33 Breakpoints on Physical or Virtual Addresses 33 Examples for Breakpoints 34 Software Breakpoints 34 On-chip Program Address Breakpoints 34 On-chip Data Address Breakpoints 34 Access Classes 35 Access Classes to Memory and Memory Mapped Resources 35 PPC600 Family Debugger 1

2 Access Classes to Other Addressable Core and Peripheral Resources 36 Cache 36 Memory Coherency 36 MESI States 37 Little Endian Operation 38 CPU specific SYStem Commands SYStem.BdmClock Set JTAG frequency 39 SYStem.CPU Select the CPU type 39 SYStem.CpuAccess Run-time memory access (intrusive) 40 SYStem.LOCK Lock and tristate the debug port 40 SYStem.MemAccess Real-time memory access (non-intrusive) 41 SYStem.Mode Select operation mode 42 SYStem.CONFIG.state Display target configuration 43 SYStem.CONFIG Configure debugger according to target topology 44 Daisy-chain Example 46 TapStates 47 SYStem.CONFIG.CORE Assign core to TRACE32 instance 48 CPU specific System Commands SYStem.Option BASE Set base address for on-chip peripherals 49 SYStem.Option BUS32 Use 32-Bit data-bus mode 50 SYStem.Option CONFIG Select RCW configuration 50 SYStem.Option DCREAD Read from data cache 51 SYStem.Option DUALPORT Implicitly use run-time memory access 51 SYStem.Option FREEZE Freeze timebase when core halted 52 SYStem.Option HOOK Compare PC to hook address 52 SYStem.Option HRCWOVerRide Override HRCW on SYStem.Up 53 SYStem.Option ICFLUSH Invalidate instruction cache before go/step 53 SYStem.Option ICREAD Read from instruction cache 54 SYStem.Option IMASKASM Disable interrupts while single stepping 54 SYStem.Option IMASKHLL Disable interrupts while HLL single stepping 54 SYStem.Option IP Set MSR_IP value for breakpoints / SYStem.Up 55 SYStem.Option.LittleEnd True little endian mode 55 SYStem.Option.MemProtect Enable memory access safeguard 55 SYStem.Option.MemSpeed Configure memory access timing 56 SYStem.Option MMUSPACES Separate address spaces by space IDs 56 SYStem.Option.NoDebugStop Disable JTAG stop on debug events 57 SYStem.Option.NOTRAP Use alternative software breakpoint instruction 58 SYStem.Option OVERLAY Enable overlay support 59 SYStem.Option PARITY Generate parity on memory access 59 SYStem.Option.PINTDebug Program interrupt debugging 60 SYStem.Option.PPCLittleEnd PPC little endian mode 60 SYStem.Option.PTE Evaluate PTE table for address translation 61 SYStem.Option RESetBehavior Set behavior when target reset detected 61 PPC600 Family Debugger 2

3 SYStem.Option ResetMode Select reset mode for SYStem.Up 62 SYStem.Option.SLOWRESET Relaxed reset timing 62 SYStem.Option.STEPSOFT Use alternative method for ASM single step 63 SYStem.Option WATCHDOG Leave software watchdog enabled 64 CPU specific MMU Commands MMU.DUMP Page wise display of MMU translation table 65 MMU.List Compact display of MMU translation table 67 MMU.SCAN Load MMU table from CPU 68 MMU.Set Write MMU TLB entries to CPU 69 CPU specific BenchMarkCounter Commands BMC.FREEZE Freeze counters while core halted 70 BMC.<counter>.SIZE No function 70 CPU specific TrOnchip Commands TrOnchip.DISable Disable debug register control 71 TrOnchip.ENable Enable debug register control 71 TrOnchip.CONVert Adjust range breakpoint in on-chip resource 71 TrOnchip.VarCONVert Adjust complex breakpoint in on-chip resource 72 TrOnchip.RESet Reset on-chip trigger settings 72 TrOnchip.state Display on-chip trigger window 72 TrOnchip.TEnable Set filter for the trace 72 TrOnchip.TOFF Switch the sampling to the trace to OFF 73 TrOnchip.TON Switch the sampling to the trace to ON 73 TrOnchip.TTrigger Set a trigger for the trace 73 Mechanical Description JTAG/COP Connector PPC603e/700/MPC Technical Data Operation Voltage 75 Support Available Tools 76 Compilers 78 Target Operating Systems 80 3rd-Party Tool Integrations 82 Products Product Information 83 Order Information 85 PPC600 Family Debugger 3

4 PPC600 Family Debugger Version 16-Nov Aug-17 Updated the description of SYStem.Option MMUSPACES. B::Data.List addr/line code label mnemonic comment P:FFF021C li r10,0 P:FFF021C4 915F0018 stw r10,18(r31) 567 for ( i = 0 ; i <= SIZE ; flags[ i++ ] = TRUE ) ; P:FFF021C li r9,0 ; i,0 P:FFF021CC 2C cmpwi cr1,r9,12 ; cr1,i,18 P:FFF021D ble cr1,0fff021d8 P:FFF021D C b 0FFF021F0 B::Register B::PER R0 0 R8 0 EXISR CIS pending SRIS wait S R1 0FFFFFFD8 R9 0 D0IS wait D1IS wait D R2 0 R10 0 E0IS wait E1IS wait E R3 0 R11 0 R4 0 R12 0 Input Output Configuration R5 0 R13 0 IOCR E0T level E1T level E2T le R6 0 R14 0 E0L negative E1L negative R7 0 R15 0 RDM disabled TCS sysclk S SPRG0 0 SRR0 0 SPRG1 0 SRR1 0 Bank 0 SPRG2 0 SRR2 0 BR0 FF183FFE BAS 0FF00000 BS 1MB BU rea PPC600 Family Debugger 4

5 Introduction This document describes the processor specific settings and features of TRACE32-ICD for the following CPU families: MPC603x MPC51xx, MPC5200, MPC5200B MPC7xx, MPC74xx MPC82xx, MPC83xx MPC86xx Please keep in mind that only the Processor Architecture Manual (the document you are reading at the moment) is CPU specific, while all other parts of the online help are generic for all CPUs supported by Lauterbach. So if there are questions related to the CPU, the Processor Architecture Manual should be your first choice. If some of the described functions, options, signals or connections in this Processor Architecture Manual are only valid for a single CPU or for specific families, the name(s) of the family(ies) is added in brackets. Brief Overview of Documents for New Users Architecture-independent information: Debugger Basics - Training (training_debugger.pdf): Get familiar with the basic features of a TRACE32 debugger. T32Start (app_t32start.pdf): T32Start assists you in starting TRACE32 PowerView instances for different configurations of the debugger. T32Start is only available for Windows. General Commands (general_ref_<x>.pdf): Alphabetic list of debug commands. Architecture-specific information: Processor Architecture Manuals : These manuals describe commands that are specific for the processor architecture supported by your debug cable. To access the manual for your processor architecture, proceed as follows: - Choose Help menu > Processor Architecture Manual. OS Awareness Manuals (rtos_<os>.pdf): TRACE32 PowerView can be extended for operating system-aware debugging. The appropriate OS Awareness manual informs you how to enable the OS-aware debugging. PPC600 Family Debugger 5

6 Warning Signal Level All The debugger drives the output pins of the BDM/JTAG/COP connector with the same level as detected on the VCCS pin. If the I/O pins of the processor are 3.3 V compatible then the VCCS should be connected to 3.3 V. See also System.up errors. Supported debug voltage: Debug cable with blue ribbon cable V. Debug cable with gray ribbon cable V (Available since 03/2004). ESD Protection WARNING: To prevent debugger and target from damage it is recommended to connect or disconnect the debug cable only while the target power is OFF. Recommendation for the software start: 1. Disconnect the debug cable from the target while the target power is off. 2. Connect the host system, the TRACE32 hardware and the debug cable. 3. Power ON the TRACE32 hardware. 4. Start the TRACE32 software to load the debugger firmware. 5. Connect the debug cable to the target. 6. Switch the target power ON. 7. Configure your debugger e.g. via a start-up script. Power down: 1. Switch off the target power. 2. Disconnect the debug cable from the target. 3. Close the TRACE32 software. 4. Power OFF the TRACE32 hardware. PPC600 Family Debugger 6

7 Target Design Requirement/Recommendations General Locate the JTAG / COP connector as close as possible to the processor to minimize the capacitive influence of the trace length and cross coupling of noise onto the JTAG signals. Don t put any capacitors (or RC combinations) on the JTAG lines. Connect TDI, TDO, TMS and TCK directly to the CPU. Buffers on the JTAG lines will add delays and will reduce the maximum possible JTAG frequency. If you need to use buffers, select ones with little delay. Most CPUs will support JTAG above 50 MHz, and you might want to use high frequencies for optimized download and upload performance. Ensure that JTAG HRESET is connected directly to the HRESET of the processor. This will provide the ability for the debugger to drive and sense the status of HRESET. The target design should only drive HRESET with open collector/open drain. For optimal operation, the debugger should be able to reset the target board completely (processor external peripherals, e.g. memory controllers) with HRESET. In order to start debugging right from reset, the debugger must be able to control CPU HRESET and CPU TRST independently. There are board design recommendations to tie CPU TRST to CPU HRESET, but this recommendation is not suitable for JTAG debuggers. If the processor does not have QACK/QREQ pins, leave the corresponding pins on the debug connector N/C. If the processor has QACK/QREQ pins, QACK must be LOW in order to halt the core for debugging. If QACK is connected to the debug connector, the debugger can drive it LOW by command. If QACK is not connected to any system controller, it is recommended to tie it to GND. The debug cable uses the VCCS pin to generate the power supply for the JTAG output buffers. The load on the VCCs pin caused by the debug cable depends on the debug cable version: Gray ribbon cable Blue ribbon cable The VCCS pin is used as reference voltage for the internal power supply in the debug cable. This causes a load of about 50 k. It is recommended to use a resistor with max. 5 k to VCC, and max 1 k for systems with VCCS = 1. 8V The VCCS pin should be connected to VCC through a resistor with max. 10, as the output buffers are directly supplied by the VCCS pin. PPC600 Family Debugger 7

8 Quick Start Starting up the Debugger is done as follows: 1. Select the device prompt B: for the ICD Debugger, if the device prompt is not active after the TRACE32 software was started. b: 2. Select the CPU type to load the CPU specific settings. SYStem.CPU MPC Tell the debugger where s FLASH/ROM on the target. MAP.BOnchip 0xFF xFFFFFFFF This command is necessary for the use of on-chip breakpoints. 4. Enter debug mode. SYStem.Up This command resets the CPU (HRESET) and enters debug mode. After this command is executed, it is possible to access the registers. 5. Show registers of on-chip peripherals. PER.view 6. Set the chip selects to get access to the target memory. Data.Set ANC:(IOBASE() 0x ) %Long 0xFF Data.Set ANC:(IOBASE() 0x ) %Long 0xFF800EF4 ; Load the program and debug symbols. Data.LOAD.Elf diabc.x 8. If the program was compiled on a different computer / environment, the source file path might have to be adopted. Data.LOAD.Elf diabc.x /StripPART 5. /SOURCEPATH "L:\prj\src" PPC600 Family Debugger 8

9 The option of the Data.LOAD command depends on the file format generated by the compiler. For information on the compiler options refer to the section Compilers. A detailed description of the Data.LOAD command is given in the General Commands Reference. 9. Set a breakpoint to the function to be debugged. Break.Set main 10. Start application. The core will halt when the breakpoint is reached. Go 11. Open windows to show source code, core registers and local variables. The window position can be specified with the WinPOS command. Data.List Register /SpotLight Frame.view /Locals /Caller PPC600 Family Debugger 9

10 Troubleshooting The SYStem.Up command is the first command of a debug session where communication with the target is required. If you receive error messages while executing this command this may have the following reasons. Error Message target power fail emulation pod configuration error target processor in reset emulation debug port fail emulation debug port fail target reset fail Reason Target has no power or debug cable is not connected. Check if the JTAG VCC pin is driven by the target. The debugger was not able to determine the connected processor. There are two possible reasons for this error: The CPU you are using is not supported by the used software, or a communication error prevented a correct determination. Check the AREA window for more information. The reset line is/was asserted by the target while the debugger performed a power-on reset. Try SYStem.Option.SLOWRESET, and check signal level of the JTAG HRESET pin. The debugger was unable to perform a power-on reset with the processor. Check all JTAG port signals. If the target reset is asserted for >500ms, or the target reset state is not reflected on the JTAG_HReset pin, SYStem.Option.SLOWRESET might be necessary. emulator debug port reset error PPC600 Family Debugger 10

11 Problems with Memory Access For processors of some device families (esp. MPC82XX/MPC83XX), it is important that no unimplemented memory addresses are accessed by the debugger. Unimplemented memory means address ranges which would cause a data access exception when accessed by the target application in the current target state. Memory that is only available after target initialization, like SDRAM is unimplemented memory until initialized (e.g. a Data.dump window (or the stack view in the Register window) to SDRAM directly after reset). Also, virtual addresses are unimplemented if the memory management unit is currently disabled or the address unmapped (e.g. a Data.List window to Linux code at 0xC directly after reset). The effects of accessing unimplemented memory are temporarily flickering memory windows up to permanently hanging memory buses, which can only be recovered by a reset. The debugger can rarely detect if a memory bus is hanging or not. Typical values displayed in dump/list windows are 0x , 0xDEADBEE0, 0xDEADBEE1 or???????? (bus error). Hints for safe memory accesses: directly after reset, set R1 to zero before opening the register window (which includes the stack view) directly after reset, close all windows that display data from SDRAM etc. which is not accessible directly after reset MPC82XX: close the peripheral view window before SYStem.UP. Usually the IMMR base address is different after reset and after target initialization. Always set the right base address with SYStem.Option.BASE before opening the peripheral view. Protect the debugger from accessing unimplemented memory using MAP.DENYACCESS. PPC600 Family Debugger 11

12 FAQ Debugging via VPN Ref: 0307 The debugger is accessed via Internet/VPN and the performance is very slow. What can be done to improve debug performance? The main cause for bad debug performance via Internet or VPN are low data throughput and high latency. The ways to improve performance by the debugger are limited: In PRACTICE scripts, use "SCREEN.OFF" at the beginning of the script and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated. "SYStem.POLLING SLOW" will set a lower frequency for target state checks (e.g. power, reset, jtag state). It will take longer for the debugger to recognize that the core stopped on a breakpoint. "SETUP.URATE 1.s" will set the default update frequency of Data.List/Data.dump/Variable windows to 1 second (the slowest possible setting). prevent unneeded memory accesses using "MAP.UPDATEONCE [address-range]" for RAM and "MAP.CONST [address--range]" for ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified address range only once after the core stopped at a breakpoint or manual break. "MAP.CONST" will read the specified address range only once per SYStem.Mode command (e.g. SYStem.Up). PPC600 Family Debugger 12

13 Setting a Software Breakpoint fails Ref: 0276 What can be the reasons why setting a software breakpoint fails? Setting a software breakpoint can fail when the target HW is not able to implement the wanted breakpoint. Possible reasons: The wanted breakpoint needs special features that are only possible to realize by the trigger unit inside the controller. Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set window). Breakpoints with checking in real-time for data-values ("Data"). Breakpoints with special features ("action") like TriggerTrace, TraceEnable, TraceOn/TraceOFF. TRACE32 can not change the memory. Example: ROM and Flash when no preparation with FLASH.Create, FLASH.TARGET and FLASH.AUTO was made. All type of memory if the memory device is missing the necessary control signals like WriteEnable or settings of registers and SpecialFunctionRegisters (SFR). Contrary settings in TRACE32. Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type> Onchip (HARD is only available for ICE and FIRE). RTOS and MMU: If the memory can be changed by Data.Set but the breakpoint doesn't work it might be a problem of using an MMU on target when setting the breakpoint to a symbolic address that is different than the writable and intended memory location. arm!qack Termination Ref: 0131 Strange behavior during or after system.up; Step/Go do not work correctly; External memory flicker The!QACK signal is a confirmation input for the CPU. The signal indicates that no other device will access/use the 603 bus and no bus snoop is necessary by the CPU. Only after this confirmation the CPU changes from user mode back to debug mode. Normally this signal is served by any external memory controller/bridge or any other logic. In this case the signal needs a pull-up because it's LOW active. If there is no device using the 603 bus or serving this signal,!qack must have a pull-down or be tied to GND. On a target with a MPC107 bus controller, some boot loaders configure the MPC107 so, that!qack is driven HIGH if it is not asserted. The MPC107 has to be configured to tristate the signal in this case. If the signal is LOW, the debugger is not able to control the CPU properly. PPC600 Family Debugger 13

14 MPC600/7XX Error Message: "emulation pod configuration error" Ref: 0105 Error message "emulation pod configuration error" after starting the T32 ICD software This error can have three sources: The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available. The CPU detection failed. Check the JTAG connection to the target. The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window. PPC600 Family Debugger 14

15 Debugging via VPN Ref: 0307 The debugger is accessed via Internet/VPN and the performance is very slow. What can be done to improve debug performance? The main cause for bad debug performance via Internet or VPN are low data throughput and high latency. The ways to improve performance by the debugger are limited: In PRACTICE scripts, use "SCREEN.OFF" at the beginning of the script and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated. "SYStem.POLLING SLOW" will set a lower frequency for target state checks (e.g. power, reset, jtag state). It will take longer for the debugger to recognize that the core stopped on a breakpoint. "SETUP.URATE 1.s" will set the default update frequency of Data.List/Data.dump/Variable windows to 1 second (the slowest possible setting). prevent unneeded memory accesses using "MAP.UPDATEONCE [address-range]" for RAM and "MAP.CONST [address--range]" for ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified address range only once after the core stopped at a breakpoint or manual break. "MAP.CONST" will read the specified address range only once per SYStem.Mode command (e.g. SYStem.Up). PPC600 Family Debugger 15

16 Setting a Software Breakpoint fails Ref: 0276 What can be the reasons why setting a software breakpoint fails? Setting a software breakpoint can fail when the target HW is not able to implement the wanted breakpoint. Possible reasons: The wanted breakpoint needs special features that are only possible to realize by the trigger unit inside the controller. Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set window). Breakpoints with checking in real-time for data-values ("Data"). Breakpoints with special features ("action") like TriggerTrace, TraceEnable, TraceOn/TraceOFF. TRACE32 can not change the memory. Example: ROM and Flash when no preparation with FLASH.Create, FLASH.TARGET and FLASH.AUTO was made. All type of memory if the memory device is missing the necessary control signals like WriteEnable or settings of registers and SpecialFunctionRegisters (SFR). Contrary settings in TRACE32. Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type> Onchip (HARD is only available for ICE and FIRE). RTOS and MMU: If the memory can be changed by Data.Set but the breakpoint doesn't work it might be a problem of using an MMU on target when setting the breakpoint to a symbolic address that is different than the writable and intended memory location. MPC7448 Single Step over store instruction fails Ref: 0339 MPC744X/745 X Flash/Memory Mapped Registers Invisible Ref: 0206 Is there a workaround for MP7448 chip errata #24? Due to MPC7448 chip errata #24, the processor may hang when store type instructions are single stepped with a JTAG debugger. If you encounter this problem while single stepping through code in RAM, there is also a workaround implemented in the debugger. Enable this workaround using the command: SYStem.Option.STEPSOFT ON See Processor Architecture Manual for details about this command. The debugger can not display flash data and/or memory mapped registers, although the target program can access this memory/registers. The MPC744X/5X debug controller only supports burst accesses for the debugger. Some devices however, like flash devices or peripherial controllers do not support burst accesses. There is a workaround, which can be activated using MAP.DENYBURST [address-range]. This workaround enables variable size memory accesses for the given address range. Please be aware that this workaround is very slow. Keep data.list/dump windows as small as possible and select a high JTAG frequency. This issue is documented in Freescale's MPC74XX chip errata, errata #8 "Variable size memory accesses via COP cannot be performed using the service bus". MPC7448 and newer are not affected. PPC600 Family Debugger 16

17 MPC744X/745 X/MPC86XX SYStem.UP fails when FLASH erased Ref: 0280 SYStem.UP fails with MPC744x/MPC745x or MPC86xx SYStem.UP of MPC744X/5X/MPC86XX can fail if the instruction at the reset address is invalid. This is a side effect of a chip errata (e.g. MPC7448 chip errata #7) If the FLASH memory at the reset address (0xFFF00100) is not programmed, the CPU will not stop at the reset address. The debugger will print an error message to the AREA window that the CPU stopped at a wrong address (0xFFF00800). In this case, use the sequence: SYStem.Mode.Attach Break to stop the CPU. If the SYStem.UP fails as described above, but it is known that the FLASH is programmed (e.g. boot loader running), usually the problem is that JTAG_HReset resets only the processor, but not other devices on the board, esp. the memory controller. If the memory controller will not be reset, the FLASH contents for the reset address are probably not mapped correctly. Make sure that JTAG_HReset resets processor and memory controller. MPC74XX Error Message: "emulation pod configuration error" Ref: 0105 Error message "emulation pod configuration error" after starting the T32 ICD software This error can have three sources: The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available. The CPU detection failed. Check the JTAG connection to the target. The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window. MPC74XX Instruction/Dat a Address Breakpoints do not work Ref: 0186 Data/Instruction address breakpoints do not work or stop working at a certain point in target code. The instruction/data address breakpoints probably stop working if the target program enables the memory management unit, i.e. MSR_IR and/or MSR_DR bit set to 1. Solution: Type MMU.ON to the command line. This command will enable MMU support of the debugger, which will configure the on-chip breakpoints properly. PPC600 Family Debugger 17

18 Debugging via VPN Ref: 0307 The debugger is accessed via Internet/VPN and the performance is very slow. What can be done to improve debug performance? The main cause for bad debug performance via Internet or VPN are low data throughput and high latency. The ways to improve performance by the debugger are limited: In PRACTICE scripts, use "SCREEN.OFF" at the beginning of the script and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated. "SYStem.POLLING SLOW" will set a lower frequency for target state checks (e.g. power, reset, jtag state). It will take longer for the debugger to recognize that the core stopped on a breakpoint. "SETUP.URATE 1.s" will set the default update frequency of Data.List/Data.dump/Variable windows to 1 second (the slowest possible setting). prevent unneeded memory accesses using "MAP.UPDATEONCE [address-range]" for RAM and "MAP.CONST [address--range]" for ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified address range only once after the core stopped at a breakpoint or manual break. "MAP.CONST" will read the specified address range only once per SYStem.Mode command (e.g. SYStem.Up). PPC600 Family Debugger 18

19 Setting a Software Breakpoint fails Ref: 0276 What can be the reasons why setting a software breakpoint fails? Setting a software breakpoint can fail when the target HW is not able to implement the wanted breakpoint. Possible reasons: The wanted breakpoint needs special features that are only possible to realize by the trigger unit inside the controller. Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set window). Breakpoints with checking in real-time for data-values ("Data"). Breakpoints with special features ("action") like TriggerTrace, TraceEnable, TraceOn/TraceOFF. TRACE32 can not change the memory. Example: ROM and Flash when no preparation with FLASH.Create, FLASH.TARGET and FLASH.AUTO was made. All type of memory if the memory device is missing the necessary control signals like WriteEnable or settings of registers and SpecialFunctionRegisters (SFR). Contrary settings in TRACE32. Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type> Onchip (HARD is only available for ICE and FIRE). RTOS and MMU: If the memory can be changed by Data.Set but the breakpoint doesn't work it might be a problem of using an MMU on target when setting the breakpoint to a symbolic address that is different than the writable and intended memory location. MGT5100/MPC 5200 Instruction/Dat a Address Breakpoints do not work Ref: 0186 MPC5100/5200 Error Message: "emulation pod configuration error" Ref: 0105 Data/Instruction address breakpoints do not work or stop working at a certain point in target code. The instruction/data address breakpoints probably stop working if the target program enables the memory management unit, i.e. MSR_IR and/or MSR_DR bit set to 1. Solution: Type MMU.ON to the command line. This command will enable MMU support of the debugger, which will configure the on-chip breakpoints properly. Error message "emulation pod configuration error" after starting the T32 ICD software This error can have three sources: The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available. The CPU detection failed. Check the JTAG connection to the target. The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window. PPC600 Family Debugger 19

20 Debugging via VPN Ref: 0307 The debugger is accessed via Internet/VPN and the performance is very slow. What can be done to improve debug performance? The main cause for bad debug performance via Internet or VPN are low data throughput and high latency. The ways to improve performance by the debugger are limited: In PRACTICE scripts, use "SCREEN.OFF" at the beginning of the script and "SCREEN.ON" at the end. "SCREEN.OFF" will turn off screen updates. Please note that if your program stops (e.g. on error) without executing "SCREEN.OFF", some windows will not be updated. "SYStem.POLLING SLOW" will set a lower frequency for target state checks (e.g. power, reset, jtag state). It will take longer for the debugger to recognize that the core stopped on a breakpoint. "SETUP.URATE 1.s" will set the default update frequency of Data.List/Data.dump/Variable windows to 1 second (the slowest possible setting). prevent unneeded memory accesses using "MAP.UPDATEONCE [address-range]" for RAM and "MAP.CONST [address--range]" for ROM/FLASH. Address ranged with "MAP.UPDATEONCE" will read the specified address range only once after the core stopped at a breakpoint or manual break. "MAP.CONST" will read the specified address range only once per SYStem.Mode command (e.g. SYStem.Up). PPC600 Family Debugger 20

21 Setting a Software Breakpoint fails Ref: 0276 What can be the reasons why setting a software breakpoint fails? Setting a software breakpoint can fail when the target HW is not able to implement the wanted breakpoint. Possible reasons: The wanted breakpoint needs special features that are only possible to realize by the trigger unit inside the controller. Example: Read, write and access (Read/Write) breakpoints ("type" in Break.Set window). Breakpoints with checking in real-time for data-values ("Data"). Breakpoints with special features ("action") like TriggerTrace, TraceEnable, TraceOn/TraceOFF. TRACE32 can not change the memory. Example: ROM and Flash when no preparation with FLASH.Create, FLASH.TARGET and FLASH.AUTO was made. All type of memory if the memory device is missing the necessary control signals like WriteEnable or settings of registers and SpecialFunctionRegisters (SFR). Contrary settings in TRACE32. Like: MAP.BOnchip for this memory range. Break.SELect.<breakpoint-type> Onchip (HARD is only available for ICE and FIRE). RTOS and MMU: If the memory can be changed by Data.Set but the breakpoint doesn't work it might be a problem of using an MMU on target when setting the breakpoint to a symbolic address that is different than the writable and intended memory location. PPC600 Family Debugger 21

22 MPC826x/80/7 x/41/42 BUS-ERRORS on valid addresses Ref: 0110 After SYStem.Up or when opening a dump/register window all displayed memory data is invalid (e.g. 0xDEADBEEx) Accesses to unimplemented memory address ranges (outside of valid chip selects), can cause a blocked memory bus which can only be resolved by a RESET. It is not possible to detect a blocked memory bus for the debugger, usually is appears that all displayed data has the value 0xDEADBEEx or random data. Debugger software before 04/2004: Make sure that none of the windows access unimplemented memory. Close the peripherial view window while changing the IMMR base address (by program or via debugger) Debugger software between 04/2004 and 11/2007: chip select 11 (or 7) will be activated on SYStem.UP. This prevents blocking the memory bus. NOTE: In some cases CS7/11 has to be disabled before changing the IMMR base address. Debugger software since 11/2007 and newer: The handling of CS7/11 has been improved, but has to be enabled using SYStem.Option.MemProtect ON together with SYStem.Option.BASE AUTO. The debugger software can detect IMMR changes during assembler steps and will handle CS7/11 accordingly. The base address of the peripherial view is automatically updated. Usage: Set SYStem.Option.BASE to AUTO if RSTCONF is read from FLASH, or set the IMMR base address manually for any other options. SYStem.Option.MemProtect ON ; CS7 or 11 will be enable on system.up for safe memory accesses SYStem.UP SYStem.Option.BASE AUTO ; enable automatic IMMR change detection Start execution until the instruction that changes IMMR is reached, e.g. GO 0xFFF09038 /ONCHIP Step.ASM ; assembler single step Now the debugger will use the new IMMR address for peripheral view and servicing the watchdog. PPC600 Family Debugger 22

23 MPC82XX Problems when changing IMMR (software before 11/2007) Ref: 0287 When changing the IMMR base address to a new value memory access results in a buserror (for software before 11/2007) The cause of the problem is that the MPC82XX series does not provide a possibility to read IMMR directly via JTAG. Only in a few cases the debugger can detect IMMR. If the IMMR known to the debugger does not match the IMMR of the processor, debugger accesses to the IMMR base can cause memory access errors. Here are the steps for handling IMMR address changes: For Software older than 11/2007: The debugger will only detect IMMR on SYStem.UP when SYStem.Option.BASE AUTO is used and RSTCONF can be read from FLASH. If the application changes IMMR, SYStem.Option.BASE has to be updated manually. Use a PRACTICE script (*.cmm): SCREEN.ON entry &NewBase if "&NewBase"=="" ENDDO &OldBase=IOBASE() PER.S ASD:(&OldBase 0x101A8) %LONG &NewBase SYStem.Option.BASE &NewBase PRINT "change old (&OldBase) IOBASE address to =: " iobase() ENDDO With screen!=always the hole file will be executed up to the end then the next access from the debugger take place. Iconize, close all windows or use a new empty WinPAGE.Create. Iconized/closed windows are inactive and do not cause a repeatedly access to the target CPU. Watchdog service (SYStem.Option.WatchDog.ON) will periodically access to the SWSR register, which is also within the internal memory space! If the IMMR register will be changed by the application, the SYStem.Option.BASE also has to be switched to the new value before the CPU is stopped or stops again! NOTE: This issue does not exist for MPC83XX and MPC85XX, as the IMMR base address can always be read via JTAG PPC600 Family Debugger 23

24 MPC82XX Problems when changing IMMR (sw since 11/2007) Ref: 0205 When changing the IMMR base address to a new value memory access results in a buserror (for software since 11/2007) The cause of the problem is that the MPC82XX series does not provide a possibility to read IMMR directly via JTAG. Only in a few cases the debugger can detect IMMR. If the IMMR known to the debugger does not match the IMMR of the processor, debugger accesses to the IMMR base can cause memory access errors. Here are the steps for handling IMMR address changes: New implementation for MPC82XX since 11/2007: SYStem.Option.BASE AUTO has been extended to detect IMMR changes automatically upon two events: Memory write / modify via Data.Set Assembler single step The new implementation makes it possible to change the IMMR base address with the debugger, even while SYStem.Option.WATCHDOG (watchdog is active and serviced by the debugger) is active, or single stepping a IMMR base address change. Usage: Set SYStem.Option.BASE to AUTO if RSTCONF is read from FLASH, or set the IMMR base address manually for any other options. SYStem.UP SYStem.Option.BASE AUTO ; enable automatic IMMR change detection Start execution until the instruction that changes IMMR is reached, e.g. GO 0xFFF09038 /ONCHIP Step.ASM ; assembler single step Now the debugger will use the new IMMR address for peripheral view and servicing the watchdog. NOTE: if SYStem.Option.BASE is not set to AUTO, the behavior is equal to software before 11/2007. This issue does not exist for MPC83XX and MPC85XX, as the IMMR base address can always be read via JTAG PPC600 Family Debugger 24

25 MPC82XX Processor seems to step backwards Ref: 0112 MPC82XX SYStem.Optio n.base.auto does not work Ref: 0163 Processor seems to step backwards. A bus error happened which cannot be recognized and/or handled by the debugger. Maybe any indirect store/load command use an un-initialized GPR register (R1-R15). R0 can only be used as offset zero!!! A complete new SYStem.Up and target init is necessary. There are few exceptions where SYStem.Option.BASE.AUTO (default setting) does not work: There are several MPC82xx CPU used as Master/Slave. Multiprozessor/multicore using CS0 memory will be changed right after HRESET from any target board logic. The RSTCONF word has to be readable by the debugger after system.up (HRESET) at CS0! RSTCONF[CIP] does not use the same memory area as the RST- CONF[BMS]. FLASH is empty/erased. Memory content is 0xffffffff. In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal default RSTCONF word has to be used. RSTCONF pin is HIGH. Internal/default RSTCONF word (0x ) is used. In this case set SYS.O.BASE to 0x0. In all these cases the SYStem.Option.BASE field has to be set to the true internal space base address which will be active right after HRESET. Only the 8 possible addresses from RSTCONF[ISP] are valid internal space base addresses. MPC82XX SYStem.Optio n.ip.auto does not work Ref: 0164 There are few exceptions where SYStem.Option.IP.AUTO (default setting) does not work: FLASH is empty/erased. Memory content is 0xffffffff. In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal default RSTCONF word has to be used. Wrong signal termination or a not finished board design prevent CPU to fetch the reset vector from the memory bus. Additional target board logic needs a huge time after negating the HRESET, for a specific board, logic or memory controller initialisation. The most time this problem could be solved with the SYStem.Option.SLOWRESET. In all these cases the SYStem.Option.IP field has to be set to: 0, if the reset vector is at 0x (RSTCONF[CIP]==1) 1, if the reset vector is at 0xfff00100 (RSTCONF[CIP]==0) PPC600 Family Debugger 25

26 MPC82XX SYStem.UP fails when flash is not programmed Ref: 0132 Why does the debugger fail to connect to the processor after erasing FLASH memory? The cause of this problem is that the CPU reads the HARD RESET CONFIGURATION WORD from the erased flash. The HRCW reads as 0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set. Solution: Switch the RSTCONF pin to HIGH to use the internal default reset configuration word (0x ). Set SYStem.Option.BASE to 0x SYStem.UP Set up chip select 0 for FLASH program reset configuration word to flash Switch the RSTCONF pin to LOW to use external reset configuration word Recommendation: Make sure to program reset configuration word to flash immediately after erasing it. MPC82XX/83X X Cannot write to SYPCR Ref: 0045 MPC82XX/83X X Error Message: "emulation pod configuration error" Ref: 0105 Writing SYPCR has no effect. The SYPCR register can only be written one time. If the SYSTEM.OPTION.WATCHDOG is set to OFF then the CPU WATCHDOG function will be disabled by the debugger during a SYSTEM.UP. To disable the WATCHDOG on the CPU the debugger writes to SYPCR and uses the one-time write access to the SYPCR register. Error message "emulation pod configuration error" after starting the T32 ICD software This error can have three sources: The CPU selection in the SYStem window does not match the CPU on the target. Check if the selection matches the processor on the target. Try to use auto detection (PPC..XX selection) if available. The CPU detection failed. Check the JTAG connection to the target. The CPU on the target is not supported by the used debugger software release. In most cases there is additional information given in the AREA window. MPC82XX/83X X Instruction/Dat a Address Breakpoints do not work Ref: 0186 Data/Instruction address breakpoints do not work or stop working at a certain point in target code. The instruction/data address breakpoints probably stop working if the target program enables the memory management unit, i.e. MSR_IR and/or MSR_DR bit set to 1. Solution: Type MMU.ON to the command line. This command will enable MMU support of the debugger, which will configure the on-chip breakpoints properly. PPC600 Family Debugger 26

27 MPC83XX Memory access fails after program ran Ref: 0360 The debugger's memory access works after SYStem.UP, but fails after the running the application. What can be the problem? For MPC834x, MPC837x and MPC831X, the unit performing memory accesses for the debugger is clocked together with another peripheral block. For proper memory access, make sure that this unit does not get disabled by your application. The units which must be kept enabled are: MPC834x: TSEC2 MPC837x: esdhc / I2C1 MPC831x: encryption engine Make sure that the corresponding peripheral block does not get disabled in the System Clock Control Register (SCCR). MPC83XX SYStem.UP fails when flash is not programmed Ref: 0288 Why does the debugger fail to connect to the processor after erasing FLASH memory? The cause of this problem is that the CPU reads the HARD RESET CONFIGURATION WORD from the erased flash. The HRCW reads as 0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set. Solution: Use SYStem.Option.HRCWOVR to override the HRCW with the debugger. Example: SYStem.CPU MPC8349 SYStem.Option.HRCWOVR 0xB060A ; 64-bit HRCW set by debugger SYStem.UP SYStem.Option.HRCWOVR ; disable HRCW override Notes: The Processor will keep the overridden HRCW intil the next power cycle or power-on reset If HRESET of the JTAG connector asserts PORESET on the target, then SYStem.Option.HRCWOVR does not work. When designing a target, is is recommended to connect JTAG_HRESET to CPU_HRESET. PPC600 Family Debugger 27

28 TRIG POWER 7-9 V TRIG POWER 7-9 V PODBUS SYNC POWER SELECT RUNNING LINK ACTIVITY PODBUS OUT PODBUS IN POWER SELECT EMULATE PODBUS OUT PODBUS EXPRESS OUT Configuration System Overview HUB 1 GBit Ethernet PC or Workstation POWER DEBUG II Debug Cable Target Ethernet Cable USB ETHERNET DEBUG CABLE DEBUG CABLE LAUTERBACH JTAG Connector LAUTERBACH POWER DEBUG II AC/DC Adapter PC Target Debug Cable USB Cable USB POWER DEBUG INTERFACE / USB2 LAUTERBACH DEBUG CABLE DEBUG CABLE LAUTERBACH JTAG Connector POWER DEBUG INTERFACE / USB 2 AC/DC Adapter PPC600 Family Debugger 28

29 PowerPC 600 Family Specific Implementations Breakpoints There are two types of breakpoints available: Software breakpoints (SW-BP) and on-chip breakpoints. Software Breakpoints Software breakpoints are the default breakpoints. They can only be used in RAM areas. There is no restriction in the number of software breakpoints. Please consider that setting a large number of software breakpoints will reduce the debug speed. All MPC60X, MPC7XX, MPC824X/6X, MPC74XX, MPC5100, MPC86XX MPC512X, MPC5200,MPC8280, MPC827X,MPC8247, MPC8248, MPX83XX Since this CPU can only be stopped by an on-chip breakpoint, TRACE32-ICD sets an on-chip breakpoint to the Trap exception handler, whenever a software breakpoint is used. Because of that, software breakpoints can not be used if all on-chip breakpoints are directly used. The current exception position must be known by the debugger at that time the SW-BP take place. See also SYStem.Option.IP. CPUs with at least two on-chip breakpoints can use SYStem.Option.IP BOTH. The debugger will set on-chip breakpoints to both interrupt addresses. For software breakpoint functionality, the debugger must set an on-chip breakpoint to the program interrupt address. In some applications, especially during the target initialization stage, some applications have interrupts disabled and use the interrupt address range for non-interrupt code. In this situation, there are two possible workarounds: Configure CPU and debugger to use the interrupt addresses that are not used at this stage. This can be done by setting MSR_IP. Please note that the target application can modify this value any time. Force on-chip breakpoints to a different address until target initialization is finished. E.g. set the on-chip breakpoint to the address where the code at the interrupt addresses is not executed anymore. If this point is reached, clear the on-chip breakpoint and continue debugging. If the used CPU has more than one on-chip breakpoint, set the second breakpoint to an unused address PPC600 Family Debugger 29

30 Software Breakpoint Handling For software breakpoint functionality, the debugger must set an on-chip breakpoint to the program interrupt address. As PPC603-based cores have two possible interrupt addresses based on MSR[IP]. In situations where there are less than two on-chip breakpoints available there is a resource conflict. The unavailability can be caused by CPU design, or if the user makes direct use of on-chip breakpoints. If the source code modifies MSR[IP], then a manual correction is necessary to use the correct exception handler. Following some logic structure examples to explain this special situations. Source code structure for all modes: 0x00 0x04 0x08 0x0C 0x10 0x14 0x18 0x1C 0x20 code code 1. SW-BP code code code change MSR[IP] bit to 0 code 2. SW-BP code AUTO-Mode: Command Sequence / CPU Status MSR[IP] Exception Pos Comment CPU is stopped, PC at 0x00 go CPU stop at 0x08 go CPU is still running / Break OK. Break error! Manual-Mode 0/1 Command Sequence / CPU Status MSR[IP] Exception Pos Comment CPU is stopped, PC at 0x00 go CPU stop at 0x08 set sys.option.ip 0 go CPU stop at 0x1C / Break OK. Break OK. PPC600 Family Debugger 30

31 Conclusion: This means, if you know, that your source code will change the MSR[IP] bit and your first SW-BP will take affect after this alteration, so use the SYStem.Option.IP to select the right exception handler. NOTE: If the target application uses page tables, software breakpoints can only be set to page tables which are already available. If it is necessary to set breakpoints in pages not yet mapped, only on-chip breakpoints can be used. Software breakpoints can be overwritten by the target application, e.g. if a breakpoint is set in an area which will be loaded by a boot loader. Use on-chip breakpoints in this case. PPC600 Family Debugger 31

32 On-chip Breakpoints The following list gives an overview of the usage of the on-chip breakpoints by TRACE32-ICD: CPU family Instruction breakpoints: Number of on-chip breakpoints that can be used for program and spot breakpoints Read/Write breakpoints: Number of on-chip breakpoints that can be used as read or write breakpoints. Can be only set on 8 byte boundaries Data breakpoints: Number of on-chip data breakpoints that can be used to stop the program when a specific data value is written to an address or when a specific data value is read from an address. CPU Family Instruction Breakpoints Read/Write Breakpoints Data Value Breakpoints Notes PPC603 RHPPC MPC8240 MPC8245 MPC8255 MPC8260 MPC8265 MPC single address Instruction breakpoint is not available if software breakpoints are used MGT5100 PPC7XX MPC74XX MPC86XX 1 single address 1 single address Instruction breakpoint is not available if software breakpoints are used MPC512X MPC5200 MPC8247 MPC8248 MPC8270 MPC8275 MPC8280 MPC83XX 2 single addresses or 1 range 2 single addresses or 1 range If software breakpoints are used, instruction breakpoints are reduced to one single address NOTE: On-chip breakpoints can be cleared by the target application or by a target reset. If an on-chip breakpoint is not hit, first check (with the peripheral view), if the on-chip breakpoint is set or not. PPC600 Family Debugger 32

33 Software Breakpoints in Interrupt Handlers If software breakpoints are used in interrupt handlers, the registers SRR0 and SRR1 will be overwritten, because software breakpoints also use SRR0/1. There are several ways to debug interrupt handlers without corrupting SRR0/1: If MPC82XX, MPC5200 or RHPPC (G2_LE cores) is under debug, set SYStem.Option NOTRAP ILL. Use on-chip breakpoints. On-chip breakpoints will not corrupt SRR0/1. Please note that if only a single on-chip instruction address breakpoint is available, using the on-chip breakpoint will prevent using any further software breakpoints. Patch the interrupt handler, so that SRR0/1 are saved upon interrupt entry and restored before interrupt exit. If the interrupt handler it patched that way, it is safe to use software breakpoints after SRR0/1 have been saved. Breakpoints in FLASH/ROM If an instruction breakpoint is set, per default, the debugger tried to set a software breakpoint. If writing to the breakpoint address failed, the debugger will set an on-chip breakpoint. With the command MAP.BOnchip <range> it is possible to inform the debugger where you have ROM (FLASH, EPROM) on the target. If a breakpoint is set within the specified address range, the debugger uses automatically the available on-chip breakpoints. Use this command, if write accesses to a read-only memory space are forbidden, e.g. because it could cause a reset etc. Example: MAP.BOnchip 0xFF xFFFFFFFF Breakpoints on Physical or Virtual Addresses On-chip breakpoints of almost all PPC603 based processors have a TE bit to configure if the breakpoint matches, if the access was performed on physical addresses (MSR_IR / MSR_DR off) of on virtual addresses (MSR_IR / MSR_DR on). In order to match, the processor compares IABR_TE / DABR_TE with MSR_IR for instruction and with MSR_DR for data accesses. Per default, the debugger configures the breakpoints to match on physical addresses. In order to set the onchip breakpoints to virtual addresses, use the command TRANSlation.ON (Activate MMU translation). This command will enable MMU support, including breakpoint configuration. Software breakpoints hit on virtual addresses if MSR_IR is set, and on physical addresses if MSR_IR is not set, regardless of any other configuration. PPC600 Family Debugger 33