FAQ for BDM-PPC
Sporadic Debug Port Fail Cannot write to SYPCR (MPC5XX/8XX) ICTRL register access (MPC5XX/8XX) Step or Go can't be executed Successful (MPC5XX/8XX) With connected debugger program behaves in a different way (MPC5XX/8XX) Exceptions and Stepping (MPC8XX/5XX) Software runs differently with ICD (MPC8XX/5XX) Using NOTRAP Option (MPC8XX/5XX) What means "stopped by SEI"? (MPC8XX/5XX) Runtime Accuracy (MPCXXX) Verify Error at Single-Step or Breakpoint (MPCXXX) home Documents FAQ FAQ for BDM-PPC PDF document ( 15KB / Nov-3-2008 )

FAQ for BDM-PPC

Sporadic Debug Port Fail
		The debugger crashes sporadically when a dump window is open or a system up is sometimes not possible.
	Be sure that the "VCC PIN" of the debug port connector is connected directly to the VCC of your target board. The Lauterbach debugger uses this voltage to supply a buffer that drives the debug lines to the CPU. If there is a resistor between the VCC of your board and our VCC pin, our supply voltage might drop too low.
Cannot write to SYPCR (MPC5XX/8XX)
		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.
ICTRL register access (MPC5XX/8XX)
		Write access to the ICTRL register by the program does not take any effekt!
	If BDM (background debug mode) is enabled, the ICTRL register CAN NOT be modified through the program and can only be modified through RCPU development access (by debugger). [MPC565 user manual, chapter 23.2.5.1 Program Trace Guidelines] The BDM is enalbed if the Debugger is connected and CPU is up. (e.g. SYStem.Mode.Up, SYStem.Mode.Go) The BDM is disabled even if the debugger is connected when SYStem.Mode.NoDebug is used. The debug mode will be enable with a DSCK assert HIGH while SRESET asserted.  SRESET __________/------------    DSCK -----------xxxxxxxxxxxx If there is no debugger connected and there is the same behavior, maybe a pull-up at DSCK causes the BDM automatically. Note: Use the SYStem.Option.IBUS [xxx] to set the ICTRL[ISCT_SER] bits. Manual access to the ICTRL register (SPR 158./0x9E) will be overwritten by the debugger with each Step or Go!
Step or Go can't be executed Successful (MPC5XX/8XX)
		Step or go result in a error message!
	... VFLS0/1 pins have wrong status. Freeze connected? sys.o.freeze VFLS from MIOS modul used? PU is missing 10 kOhm Right after reset VFLS pins are also inputs! State is non-recoverable!
With connected debugger program behaves in a different way (MPC5XX/8XX)
		With connected debugger program behaves in a different way
	sys.o.ibus == debug register ibus has priority, register will be overwritten. RSTCONF for IBUS will be overwritten. sys.nodebug only will not enable the BDM interface. sys.o.freeze.off (default) assumes VFLS0/1 at BDM connector and overwrites SIUMCR bits. (MPC8XX)
Exceptions and Stepping (MPC8XX/5XX)
		What happens if I debug my code and an exception occurs?
	The MPC8xx/5xx can react in two ways when an exception occurs: The exception is handled by the exception handler. This way the exception is not detected by the debugger (default). The program execution is stopped at the exception and the debug mode is entered, if the exception is enabled by the command "TrOnchip.Set <exception>". Refer also to the description of the Debug Enable Register in your processor manual. TRACE32 displays the reason for the program stop in the state line (refer also to the Exception Cause Register description in your processor manual). The program execution is stopped in most cases exactly at the instruction that caused the exception, in some cases at the next instruction. On some exceptions it is not possible to continue the debugging.
Software runs differently with ICD (MPC8XX/5XX)
		The target runs fine without the ICD attached. But with the ICD attached, the target runs for a while and then it hangs up.
	If the debug mode is enabled, the serialize control bit and the instruction fetch show cycle control bits are set to SERALL after reset. In SERALL mode the processor is fetch serialized and all internal fetch cycles appear on the external bus. The processor performance is, therefore, much slower. If only a BDM debugger is used perform the command "SYStem.Option IBUS NONE". In NONE mode the processor works in normal mode and no show cycles are performed. There is no performance degradation in this mode. If a RISC Trace or a PowerTrace is used, perform the command "SYStem.Option IBUS IND". In IND mode the processor works in normal mode and show cycles are performed for all indirect changes in the program flow. The performance degradation in this mode is about 1 %. For more information refer to the description of the ISCT_SER register in your processor manual.
Using NOTRAP Option (MPC8XX/5XX)
		How do I use the TRAP exeption for my own application?
	Use the command SYStem.Option NOTRAP ON With this setting the TRAP exception is no longer used for software breakpoints. UNDEF 0 is used instead. Use the command TrOnchip.Set PRIE OFF With this setting the debug mode is no longer entered when a TRAP occurs. See also the Debug Enable Register in you processor manual. Now your application can handle the TRAP instruction.
What means "stopped by SEI"? (MPC8XX/5XX)
		Where can I find more information about the acronyms SEIE, PRIE, MCIE, ...?
	These names reflect the bits of the DER Register (Debug Enable Register), ECR (Exception Cause Register for MPC5xx family) and ICR (Interrupt Cause Register for MPC8xx family). The TRACE32 Debugger evaluate these bits all the time the processor change from running mode to stop status. The abbreviation of these corresponding exceptions/interrups handler differ a little bit between the MPC5xx and MPC8xx family and several sub-derivatives manual. Additional Information: In a debug session almost all exception could be used/enabled/configured to stop the CPU and enter the debug mode instead of executing the corresponding exception handler. This could be set up in the T32 PowerView Menue: Break - OnChip_Trigger - Set - [MCIE] (MCIE is used as example here) or alternatively in the command line or script language: TrOnchip.Set [MCIE] ON If the option is enabled (box is checked), the CPU will stop right at the instruction cause this exception/interrupt and enter the debug mode.
Runtime Accuracy (MPCXXX)
		When stepping with the ICD debugger, the runtime counter shows too long count values.
	The runtime counter unit of the PowerPC debugger is realized using a software counter of the host and a hardware counter of the Lauterbach tool. The accuracy is about 10 us.
Verify Error at Single-Step or Breakpoint (MPCXXX)
		I get the error message: verify error at address ...,
	By default TRACE32-ICD uses software breakpoints to set a breakpoint to an instruction. Software breakpoint means the original instruction is replaced by to TRAP in order to stop the program. This is the reason why a software breakpoint usually requires that the instruction is in RAM. Otherwise the error message verfiy error at address (address) is displayed. The reasons for these errors are: The instruction is in ROM/FLASH/EPROM. To set software breakpoints in FLASH refer to the command "FLASH.Auto". The appropriate CS is switched to ReadOnly mode. In this case it is not possible to patch the code. It is possible to use a limited number of on-chip breakpoints to set a breakpoint to ROM/FLASH/EEPROM or ReadOnly memories. For more information refer to the command "MAP.BOnchip <range>".