FAQs for BDM-PPC400
|
|
 PDF document ( 34KB / 3-May-2011 ) |
FAQs for BDM-PPC400 |
|
|||
|
|
||||
| ||||
 |
||
Wrong Reset Address (IOP480) |
||
 |
Why does the reset vector of the IOP480 not point to the reset vector of the 401 core? | |
|
In the default setting for the PPC400 family the option SYStem.Option.ResetMode.SYSTEM is chosen. After SYStem.Up the PC points to the address of the last session or to any other address. Use the SYStem.Option.ResetMode.CHIP or SYStem.Option.ResetMode.CORE, because the system reset is not implemented on the IOP480. |
||
|
||
Connection to Target Fails (PPC400) |
||
|
Why does the connection to the target fails? | |
|
When connecting to XILINX targets be sure to use a recent version of the debug cable (see picture). With the old version of the debug cable target connection will fail or be unreliable. 
Debug Cable Versions (282K)
|
||
|
||
Emulation Debug Port Problem (PPC4XX) |
||
|
On system.up I got emulation debug port problem. | |
|
The JTAG protocol is not running on a good physical connection. There are two possiblities can cause this.
The T32 debugger has an internal 1kOhm pull-down for a safe detection of target power on/off. As result of this voltage divider (the internal 1kOhm pull-down and the target pull-up) the ICD detects a wrong target voltage and disables the output drivers if the detected voltage is lower than the voltage for a HIGH detection. Replace the pull-up by a 10 Ohm resistor. The JTAG signals are not terminated or have some overtalk. Put a 1 kOhm pull-down at TCK, TMS and TDI. |
||
|
||
Software Breakpoints Problem (PPC4XX) |
||
|
Error message: software breakpoints not possible with current system setting | |
|
One reason for this error message is that the option sys.o.icflush is OFF. Without being able to flush the ICache the debugger cannot write software breakpoints. Use the following command to allow the debugger to flush the ICache after writing a SW breakpoint: sys.o.icflush ON |
||
|
||
Stepping over TLBWE instruction (PPC4xx) |
||
|
Stepping over TLBWE instruction result in another program flow as in run mode. | |
|
There is a difference between stepping and running over a tlbwe instruction sequence. In run mode, the CPU performs the code as usual, the execution of a tlbwe instruction changes the UTLB contents but does not cause a context synchronization and thus does not invalidate or otherwise update the shadow TLB entries. Any modification in the UTLB will not be active until the next context synchronizing (ISYNC, RFI, RFCI, SC, interrupts) takes place. In usual, the application prepare the hole new MMU map, and switch to the new MMU table with a context synchronising instruction at the end of the TLB instruction sequence. If debug mode, CPU is stopped and the debugger have access to register and memory, each single step forces implicit an ISYNC command. This is a special behaviour of the debug mode and mean, with each step a context synchronizing will be forced. Therefore its not possible to step over the standard MMU initialisation sequence. A recommendation is to set at breakpoint (BP) at the end or after of the TLB init loop. May be at the ISYNC instruction, and run over the TLB setup routine to the BP. |
||
|
||
Flow Errors (Virtex-PPC400) |
||
|
Why does the debugger show only flow errors? | |
|
In contrast to most PPC405 cores, the PPC405 in Xilinx Virtex devices uses the falling edge for clocking out trace data. Add an inverter for the trace clock to your design as illustrated in the application note app_xilinx_ppc400.pdf.
Application Note (250K)
|
||
|
||
Flow Errors while Tracing works (Virtex-PPC400) |
||
|
Why do flow errors exist while ML310 tracing works? | |
|
In some samples of ML310 the GND plane in the middle of the mictor is not connected to the GND signal of the board. The floating GND connection will cause flow errors, especially at higher frequencies. To fix the problem establish a proper GND connection on the board. To work around the problem temporarily, it may help to vary the detected threshold (e.g. from 1.3 V to 1.1 V). Also be sure that your design contains an inverter for the trace clock (see above). |
||
|
||
ISOCM Access in Xilinx VirtexFX Chips (VIRTEX-PPC405) |
||
|
How can I enable access to ISOCM memory in Xilinx VirtexFX chips? | |
|
For accessing the ISOCM memory (instruction side OCM) attached to the PPC405 in Xilinx VirtexFX chips, a special access mechanism via DCR is required. This mechanism is only available from Virtex4 onwards. It is not supported in Virtex2Pro. For enabling the ISOCM access in Trace32 use the option sys.o.isocm BASEADDR where BASEADDR is the beginning of the ISOCM memory. The default value is 0xFFFF.FFFF (disabled). The feature requires Trace32 SW from 2006-10-20 or later. |
||
|
||
Debugging and Tracing Embedded PPC Cores in Xilinx FPGAs (Virtex-PPC4XX) |
||
|
How should I connect TRACE32-ICD JTAG connector to a Xilinx target? What are the correct IRPRE/IRPOST and DRPRE/DRPOST settings? | |
|
This document describes for Xilinx Virtex chips how to:
Application Note (250K)
|
||
|
Copyright © 2012 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany Impressum The information presented is intended to give overview information only. Changes and technical enhancements or modifications can be made without notice. Last generated/modified: 1-Feb-2012 |