FAQ for JTAG-MPC5500
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) home Documents FAQ FAQ for JTAG-MPC5500 PDF document ( 13KB / Nov-3-2008 )

FAQ for JTAG-MPC5500

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.