 |
|
Device censored (MPC55XX)
|
|
 |
There is no debugger access due to a censored device. What can I do ?
|
| |
|
If the device has been censored anyhow, it may happen that it must be dropped
if the keycode is unknown. Almost all JTAG accesses are blocked, as
it stated in the Reference Manual of the device. In this case the debugger can
not work.
To recognize if the device is in censoreship mode is almost impossible.
An indication may be a similar message in the AREA window like below,
after System.UP
emulation debug port fail
JTAGID=0x827401D
system.up error: received invalid OSR (0x000)
- does the target assert TRST while JTAG_HRESET is asserted?
- is the device censored?
error: received invalid OSR (0x000)
Depending on the keycode contents, one may open it again (by System.Option KEYCODE with known keycode value) or nevermore.
Normally the device can be accessed according to the description in the device
target manual. Refer to
System.Option Keycode
However the Keycode must be known.
If it′s not possible to open the device again, the CPU or board can only be dropped.
If there is a CPU socket on board, the CPU can simply be changed. A new
device should work if the problem is caused by censorship mode.
|
|
|
Devices with Censorship Mode (MPC55XX)
|
|
|
How does the debugger deal with devices which support censored mode ?
|
| |
|
Some MPC5/6xx devices support a code protection mechanism, called censored mode. Censorship mode can be use, but must not. Censored mode can exclusively be reached during Flash programming. During Flash programming, censored mode can be enabled and a 64 bit keycode must then also be programmed into the device. If
a device is in censored mode, it can not be debugged, if the keycode is unknown. Almost all debugger accesses are blocked in this case. There is no way to get into device anymore and it must be dropped.
Normally , the delivery state of a device is unprotected.
If the device is not protected, one must not take care about the description below. Everything works
as usual.
If there is no access to the device, first of all, verify which boot mode is used. Depending on the boot mode
(Flash Boot or Serial Boot Mode) and on the contents of the censorship control register, debugger access is
possible or not. Refer to the Flash Access Disable Logic diagram in the appropriate reference manual of the device.
To be able to debug a device in censored mode, the debugger must start communication with the device in a slightly different way as usual. The value of the flashed keycode is needed to open up the device. To inform the debugger SW to use that specific procedure, an additional instruction must be inserted in the startup script.
SYStem.Option KEYCODE 64bitkeycode
This instruction informs the tool that the device is in censorship mode and the specific procedure during SYSTEM.UP should be used to open the device for debugging. The entered 64 bit code will be compared with the flashed 64 bit keycode in the device during SYSTEM.UP. If both codes fit, the device is open and can be debugged. If once this option has been enabled, it remains active.
If the keycodes do not match, the AREA window gives the following information:
emulation debug port fail
JTAGID=0x827401D
Could not enter debug mode (OSR=0x000)
Device is probably censored
The serial password set with SYStem.Option KEYCODE does not match or the
password programmed to the shadow row is invalid.
error: received invalid OSR (0x000)
The user of the debugger may disable that procedure by the same system option instruction, just without a keycode value.
The status of the debugger after that instruction is also the default for the debugger.
If the device is not in censored mode, but the user enters a
SYStem.Option KEYCODE 64bitkeycode
, the entry procedure with keycode will be ignored. The debugger enters debug mode as normal.
One should consider the description above and should carefully use censored mode. Take also care about the keycode!
|
|
|
EBI problems on MPC5510 (MPC55XX)
|
|
|
The external bus interface (EBI) fails when the debugger (JTAG or NEXUS) is connected.
|
| |
|
The cause of this problem is that there are two signals which are multiplexed between debugger and EBI usage: EVTI and EVTO.
For the MPC5510 series, the function of these signals is controlled by the EVT_EN bit in the NPC_PCR register, which again is controlled by the debugger. The debugger will per default set the pin function to EVTI/EVTO. In order to use the signals for EBI (R/!W and !TA), use the EVTEN setting in the TrOnchip window:
TrOnchip.EVTEN ON ; signals have EVTI/EVTO function. EBI functions disabled (default)
TrOnchip.EVTEN OFF ; signals free for use by EBI or GPIO
IMPORTANT NOTES:
- If the NEXUS adapter LA-7610 is used, EVTI must be physically disconnected from the debug/trace connector, because the LA-7610 will permanently drive EVTI.
- If the NEXUS adapter LA-7630 is used, the EVTI pin will be tristated if TrOnchip.EVTEN is set to OFF. It is recommended to disconnect EVTI/EVTO from the debug connector anyway (see below).
- If the signals are used for EBI, it is strongly recommended to disconnect EVTI/EVTO from the debug connector. Unterminated signals can cause EBI problems, especially if the debugger is not connected.
|
|
|
Error Message: "emulation pod configuration error" (MPC55XX)
|
|
|
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.
|
|
|
Flash programming after ECC error (MPC55XX)
|
|
|
How can I erase/reprogram after causing a flash ECC error?
|
| |
|
When there is an ECC error in Flash memory, reprogramming the FLASH memory using the command
FLASH.AUTO
will fail. The reason is, that when using
FLASH.AUTO
, the debugger will try to read FLASH memory containing the ECC error and fails.
In order to sucessfully program the Flash memory, please run the FLASH programming script provided with the debugger (path T32/demo/powerpc/flash). When the dialog box appears, click "NO" and type the command
FLASH.ERASE ALL
to the command line. After erasing the FLASH memory, the ECC error should be removed.
|
|
|
Flash Programming Errors (MPC55XX)
|
|
|
When I try to program an ELF file to flash, I get a flash programming error. Programming binary files works without error.
|
| |
|
The minimum programmable flash size of the MPC55XX series internal flash is 8 bytes. ELF (and other) files can contain sections that are not aligned to this 8 byte boundary. In this case, use FLASH.AUTO instead of FLASH.PROGRAM.
|
|
|
Problems with displaying and/or tracing VLE code (MPC55XX)
|
|
|
The disassembly shows invalid code with many undef/align "instructions". Trace list shows FLOWERRORS. How can I fix this?
|
| |
|
This problem can occur when the target application consists of
VLE (variable length encoding) instructions, or both VLE and
standard PowerPC instructions (aka FLE, fixed instruction length). Following
issues can cause problems in disassembly or trace analysis:
- If debug symbols have not been loaded, the disassembler is probably not configured to display the currently used instruction set. Use
SYStem.Option.DisMode VLE | FLE
to configure manually, or use
SYStem.Option.DisMode AUTO
(default) to display the instruction set according to the current state of the CPU. You can still use
SYStem.Option.DisMode VLE | FLE
to manually force a specific decoding.
- If debug symbols have been loaded, the debugger will use the information from the debug symbols if
SYStem.Option.DisMode AUTO
is selected.
- If the debug symbols are loaded, but the disassembly is still wrong, the information about the used instruction set may be wrong. With
sYmbol.List.ATTRIBUTE
you can open a window which displays all address ranges of the debug symbols and if the instructions are FLE or VLE. The information from
MMU.DUMP.TLB1
(former MMU.TLB1.view) can help to compare current VLE setup in the MMU with the information from the debug symbols. If the information in
sYmbol.List.ATTRIBUTE
is wrong, please check your linker configuration.
- If the debugger lists VLE/FLE instructions as expected for the address ranges shown in
sYmbol.List.ATTRIBUTE
but there are still sporadic errors in the disassembly, then the used linker is not properly configured to link VLE code. In this case it was observed that all debug symbols were aligned to 4 byte boundaries, while the actual code was aligned at 2 byte boundaries. Check linker version and linker configuration.
- Early complier versions supporting VLE often had buggy VLE debug symbols. Check if a compiler update is available.
|
|
|
Using Cache as SRAM / Bus Error on locked Cache line (MPC55XX)
|
|
|
If I use cache as SRAM, I get wrong or no data displayed in the Data.List window.
|
| |
|
By default, the debugger does not read the cache contents for displaying instructions in a Data.List window. Instead, only physical memory is accessed. Besides to normal cache operation, if you have configured your cache to work as SRAM, there is no RAM that corresponds to the cache contents. Switch on the ICREAD option in the system window to configure the debugger to display cache contents when instructions are to be displayed (like in the Data.List window). The DCREAD option (enabled by default) acts the same regarding data accesses (like Data.Dump). In order to write to such memory, you have to use one of the memory classes
|
|
|
Bus Errors in Internal SRAM (MPC55XX/56XX)
|
|
|
Why do I get partial bus errors (question marks) when I open a data.dump or data.list window at the internal SRAM address (0x40000000)
|
| |
|
The MPC55XX′s internal SRAM has ECC protection. After power up, this memory is not initialized, and thus the data bits do not match the parity bits. The memory has to be initialized with 64-bit write accesses. You can use the following command:
D.S A:0x40000000--0x4000FFFF %QUAD 0x1111222233334444
|
|
|
Run-Time Memory Access Restrictions (MPC55XX/56XX)
|
|
|
Some variables show wrong values or can not be modified during run-time. What causes this problem and how can it be solved?
|
| |
|
The run-time memory access of the debugger is performed via the "Nexus Read/Write Access". As explained in the e200 core reference manuals, the Nexus Read/Write Access is designed to perform memory accesses to "Memory-mapped registers and other non-cached memory". The Nexus Read/Write Access can not access or snoop the cache of the e200 core.
Because of this restriction, data currently cached by the core can either be accessed read-only or cannot be accessed at all, depending on the configuration of the core.
In order to gain read or write access, one of the following changes can be made to the configuration:
- To gain
read-only access to all memory
, configure the cache mode to "write through". This is done via the WM or DCWM field of the L1CSR register.
- To gain
read-only access to certain memory spaces
, configure or create a TLB entry for this address range and set the W (write-through) bit.
- To gain
read/write access to all memory
, the data/unified cache has to be disabled. This is done via the L1CSR register (cache enable bit).
- To gain
read/write access to certain memory spaces
, configure or create a TLB entry for this address range and set the I (caching inhibited) bit.
Note: All of the above configuration changes have impact on the processor performance. Global configuration settings (like done via L1CSR) have more impact than settings for small address ranges. Therefore it is recommended to control the access via TLB settings and keep the page sizes for read and/or write acceses as small as possible. For example, keep the stack memory range fully cachable, as the stack does usually not need to be accessed via run-time memory access.
|
|
|
XPC56XX EVB motherboard issues (MPC56XX)
|
|
|
What problems cau cause that the debugger fails to connect to an XPC56XX EVB motherboard?
|
| |
|
When working with the XPC56XX EVB motherboard + a processor minimodule, the debug and trace signals have more than one end point: The JTAG connector, the trace connector and the pin array on the motherboard. The end points are unterminated and can cause signal reflections which disturb debugging. Especially the branch line of TCK to the EVB motherboard can cause problems.
If the debugger should fail to connect (configuration error or debug port fail), we recommend to terminate TCK at the XPC56XX EVB motherboard′s pin array with a 220~470 Ohm resistor to GND.
|
|
|
eTPU Debugger (MPC5XXX)
|
|
|
Do you have any plan to support eTPU HLL debugger?
|
| |
|
Yes, eTPU debugging and tracing is supported with an additional SW package. The PowerPC core and both eTPU cores can be debugged and traced at the same time (one trace/debug box, one host, but different SW packages).
Demo scripts are available in \demo\etpu in the Trace32 installation folder or on the installation DVD.
Note: MPC563xM (Monaco) only supports NEXUS class 1 for eTPU. Tracing the eTPU on this processor is not possible.
|
