FAQ for NEXUS-MPC5500
Target Aux Port Connector Location and Extension Cables Accessing Flash Memory via Nexus R/W (MPC55XX) Bus Errors in Internal SRAM (MPC55XX) Error Message: "emulation pod configuration error" (MPC55XX) eTPU Debugger (MPC55XX) Flash programming after ECC error (MPC55XX) Flash Programming Errors (MPC55XX) Using Cache as SRAM / Bus Error on locked Cache line (MPC55XX) VLE/FLE display and trace issues (MPC55XX) Debugger Differences 4/12 Bit Mode (NEXUS-MPC5500) Debugger Impacts (NEXUS-MPC5500) JTAG-PQ2 (NEXUS-MPC5500) Lost Messages (NEXUS-MPC5500) Nexus Class Support (NEXUS-MPC5500) Slow Reset (NEXUS-MPC5500) home Documents FAQ FAQ for NEXUS-MPC5500 PDF document ( 18KB / Nov-3-2008 )

FAQ for NEXUS-MPC5500

Target Aux Port Connector Location and Extension Cables
		Can I use a longer extension cable?
	Often customer ignore the warnings regarding the locaction of the aux port connector and regarding additional extension cables between the debugger and the target. This can cause a lot of trouble, especially for high speed applications. We strongly recommend to place the aux port connector as close as possible nearby the CPU. As closer as better. Take care about the signal trace length. Do not connect aux port signals to other connectors than the aux port connector and prevent signal stubs. Connect a proper termination to the signals coming from the probe, close to the CPU. Signals from the CPU to the probe should not be terminated. One can add 0 Ohm resistors in line of each Nexus signal close to the CPU. If necessary 0 Ohm can be replaced by a better value. The debugger does normally not need any pull-up or pull-down, except for reset. Care must just be taken just for non-Nexus signals. Bear in mind that the target needs possibly a pull-up or pull-down for certain signals if the debugger is not connected. Pay attention about the recommendations of the device manufacturer regarding the circuitry around the Nexus Aux port. We also recommend to use no other extension cables than the cables which come with the debugger. If possible do not use additional cables at all. Longer cables may work, but must not. It is the customers risk to use longer once as recommended. We can not guarantee proper operation.
Accessing Flash Memory via Nexus R/W (MPC55XX)
		Why does accessing internal flash memory via NEXUS fail?
	By default, the Nexus client does not have access to the internal Flash. Modify the BIUAPR register to make Flash memory visible for Nexus. (d.s ASD:0xC3F88020 %LONG 0x000000FF)
Bus Errors in Internal SRAM (MPC55XX)
		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
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.
eTPU Debugger (MPC55XX)
		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). It is just like the known multi-core debugging.
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.
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 IC: or DC:. Data.Assemble IC:0x40040000 addi r1, r1, 1 Data.Set DC:0x40040000 %long 0x12345678
VLE/FLE display and trace issues (MPC55XX)
		The disassembly shows invalid code with many undef/align "instructions". Trace list shows FLOWERRORS. How can I fix this?
	This issue can occur in the context of VLE encoded or in mixed VLE/fixed instruction length applications. Check the following items to solve this issue: The disassembler is 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 use the information from debug symbols or CPU status if no debug symbols are loaded. The debug symbols contain erroreous attributed about the used instruction set. Please compare the data from the debug symbols (with sYmbol.List.ATTRIBUTE) against the TLB setup of the CPU (MMU.TLB1 or MMU.view). Check your linker configuration file to fix the problem. 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. Additional hints for mixed VLE/FLE code: In case of mixed VLE/FLE code, try to use SYStem.Option.DisMode AUTO , which is the default setting. Check if the code attributes are correct recognized for the loaded program. ( sYmbol.List.ATTRIBUTE ). If this is not the case, one can not expect proper disassembled results in the liste window and will possibly get Flowerrors in the trace list windows. The Compile/Linker normally marks all functions of the code with a VLE or FLE attribute. These attributes are displayed by sYmbol.List.ATTRIBUTE . The T32 disassembler and the trace reconstruction mechanism refers to these attributes. Make also sure that the MMU settings are really correct. In case of Flowerrors in trace.list, make sure the disassembled code is correctly displayed. Check also sYmbol.List.ATTRIBUTE for a proper VLE/FLE image.
Debugger Differences 4/12 Bit Mode (NEXUS-MPC5500)
		What are the differences for the debugger between 4 bit and 12 bit mode?
	The bandwidth of the Nexus port is reduced in 4 bit mode. Therefore the FIFO full error (caused by the MCU Nexus cell) may appear more often. There is no Complex Trigger Unit (CTU) for the 4 bit mode.
Debugger Impacts (NEXUS-MPC5500)
		Is there any impact using Nexus trace and JTAG debugger?
	Utilizing the Trace only features cause no impact in performance. Read write accesses can cause minor impact if large Read/Write accesses are being performed. Nexus tries to use the system bus in between CPU accesses, but a fetch or load could be held off under some conditions.
JTAG-PQ2 (NEXUS-MPC5500)
		Can you support two Mictor type for 12 bit mode?
	Yes, normally most customers want the "single Mictor" solution. But the probe has been designed to support also the "double Mictor" solution. It must be ordered separately, because the current order number fits to the "single Mictor" solution for 4 and 12 bit mode.
Lost Messages (NEXUS-MPC5500)
		Why are sometimes certain messages not visible in the trace?
	The collision priority management of the MPC5500 family causes, that lower priority messages are canceled by higher priority messages if they occur at the same time. Refer to Motorola's documentation. ============================================================================ All messages have the following priorit: WPM - OTM - BTM - DTM. A BTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message will be lost. An error message will be sent indicating the BTM was lost. The following direct/indirect branch will queue a direct/indirect branch w/ sync. message. The count value within this message will reflect the number of sequential instructions executed after the last successful BTM Message was generated. This count will include the branch which did not generate a message due to the collision. A DTM message which attempts to enter the queue at the same time as a watchpoint message or ownership trace message or branch trace message will be lost. A subsequent read/write will queue a data trace read/write w/ sync. message. =============================================================================
Nexus Class Support (NEXUS-MPC5500)
		Is there any difference for NEXUS signals for class1 to class3?
	Nexus class 1 is just a BDM debugger without trace. All trace signals which are needed for class 2 and class 3 can be dropped. (MDO0...11, MSEO0/1, EVTI, EVTO, MCKO, CLOCKOUT, etc). We are supporting a 14 pin connector for class1.
Slow Reset (NEXUS-MPC5500)
		Why does Reset take longer if a Nexus Class 2/3+ debugger is used in respect to a class 1 Nexus debugger or if no debugger is attached?
	The delay is caused by the debugger. During target reset, all breakpoints, watchpoints and other settings are cleared by the reset logic of the CPU. The NEXUS class 2/3+ debugger will detect a target reset on the signals RSTIN and (optional) RSTOUT. After reset, the debugger has to program the debug registers, breakpoints and watchpoints again. This causes an extra delay between asserting reset and start of program execution.