FAQ for JTAG-PQ2


BUS-ERRORS on valid addresses (MPC826x/80/7x/41/42)
		After SYStem.Up or when opening a dump/register window all displayed memory data is invalid (e.g. 0xDEADBEEx)
	Accesses to unimplemented memory address ranges (outside of valid chip selects), can cause a blocked memory bus which can only be resolved by a RESET. It is not possible to detect a blocked memory bus for the debugger, usually is appears that all displayed data has the value 0xDEADBEEx or random data. Debugger software before 04/2004: Make sure that none of the windows access unimplemented memory. Close the peripherial view window while changing the IMMR base address (by program or via debugger) Debugger software between 04/2004 and 11/2007: chip select 11 (or 7) will be activated on `SYStem.UP` . This prevents blocking the memory bus. NOTE: In some cases CS7/11 has to be disabled before changing the IMMR base address. Debugger software since 11/2007 and newer: The handling of CS7/11 has been improved, but has to be enabled using `SYStem.Option.MemProtect ON` together with `SYStem.Option.BASE AUTO` . The debugger software can detect IMMR changes during assembler steps and will handle CS7/11 accordingly. The base address of the peripherial view is automatically updated. Usage: Set `SYStem.Option.BASE` to `AUTO` if RSTCONF is read from FLASH, or set the IMMR base address manually for any other options. `SYStem.Option.MemProtect ON` ; CS7 or 11 will be enable on system.up for safe memory accesses `SYStem.UP` `SYStem.Option.BASE AUTO` ; enable automatic IMMR change detection Start execution until the instruction that changes IMMR is reached, e.g. `GO 0xFFF09038 /ONCHIP` `Step.ASM` ; assembler single step Now the debugger will use the new IMMR address for peripheral view and servicing the watchdog.

Problems when changing IMMR (software before 11/2007) (MPC82XX)
		When changing the IMMR base address to a new value memory access results in a buserror (for software before 11/2007)
	The cause of the problem is that the MPC82XX series does not provide a possibility to read IMMR directly via JTAG. Only in a few cases the debugger can detect IMMR. If the IMMR known to the debugger does not match the IMMR of the processor, debugger accesses to the IMMR base can cause memory access errors. Here are the steps for handling IMMR address changes: For Software older than 11/2007: The debugger will only detect IMMR on `SYStem.UP` when `SYStem.Option.BASE AUTO` is used and RSTCONF can be read from FLASH. If the application changes IMMR, `SYStem.Option.BASE` has to be updated manually. Use a cmm script file: `SCREEN.ON entry &NewBase if "&NewBase"=="" ENDDO &OldBase=IOBASE() PER.S ASD:(&OldBase\|0x101A8) %LONG &NewBase SYStem.Option.BASE &NewBase PRINT "change old (&OldBase) IOBASE address to =: " iobase()` `ENDDO` With screen!=always the hole file will be executed up to the end then the next access from the debugger take place. Iconize, close all windows or use a new empty `WinPAGE.Create` . Iconized/closed windows are inactive and do not cause a repeatedly access to the target CPU. Watchdog service (SYStem.Option.WatchDog.ON) will periodically access to the SWSR register, which is also within the internal memory space! If the IMMR register will be changed by the application, the SYStem.Option.BASE also has to be switched to the new value before the CPU is stopped or stops again! NOTE: This issue does not exist for MPC83XX and MPC85XX, as the IMMR base address can always be read via JTAG

Problems when changing IMMR (sw since 11/2007) (MPC82XX)
		When changing the IMMR base address to a new value memory access results in a buserror (for software since 11/2007)
	The cause of the problem is that the MPC82XX series does not provide a possibility to read IMMR directly via JTAG. Only in a few cases the debugger can detect IMMR. If the IMMR known to the debugger does not match the IMMR of the processor, debugger accesses to the IMMR base can cause memory access errors. Here are the steps for handling IMMR address changes: New implementation for MPC82XX since 11/2007: `SYStem.Option.BASE AUTO` has been extended to detect IMMR changes automatically upon two events: Memory write / modify via `Data.Set` Assembler single step The new implementation makes it possible to change the IMMR base address with the debugger, even while `SYStem.Option.WATCHDOG` (watchdog is active and serviced by the debugger) is active, or single stepping a IMMR base address change. Usage: Set `SYStem.Option.BASE` to `AUTO` if RSTCONF is read from FLASH, or set the IMMR base address manually for any other options. `SYStem.UP` `SYStem.Option.BASE AUTO` ; enable automatic IMMR change detection Start execution until the instruction that changes IMMR is reached, e.g. `GO 0xFFF09038 /ONCHIP` `Step.ASM` ; assembler single step Now the debugger will use the new IMMR address for peripheral view and servicing the watchdog. NOTE: if `SYStem.Option.BASE` is not set to AUTO, the behavior is equal to software before 11/2007. This issue does not exist for MPC83XX and MPC85XX, as the IMMR base address can always be read via JTAG

Processor seems to step backwards (MPC82XX)
		Processor seems to step backwards.
	A bus error happened which cannot be recognized and/or handled by the debugger. Maybe any indirect store/load command use an un-initialized GPR register (R1-R15). R0 can only be used as offset zero!!! A complete new SYStem.Up and target init is necessary.

SYStem.Option.BASE.AUTO does not work (MPC82XX)
		There are few exceptions where SYStem.Option.BASE.AUTO (default setting) does not work:
	There are several MPC82xx CPU used as Master/Slave. Multiprozessor/multicore using CS0 memory will be changed right after HRESET from any target board logic. The RSTCONF word has to be readable by the debugger after system.up (HRESET) at CS0! RSTCONF[CIP] does not use the same memory area as the RSTCONF[BMS]. FLASH is empty/erased. Memory content is 0xffffffff. In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal default RSTCONF word has to be used. RSTCONF pin is HIGH. Internal/default RSTCONF word (0x00000000) is used. In this case set SYS.O.BASE to 0x0. In all these cases the SYStem.Option.BASE field has to be set to the true internal space base address which will be active right after HRESET. Only the 8 possible addresses from RSTCONF[ISP] are valid internal space base addresses.

SYStem.Option.IP.AUTO does not work (MPC82XX)
		There are few exceptions where SYStem.Option.IP.AUTO (default setting) does not work:
	FLASH is empty/erased. Memory content is 0xffffffff. In this case the RSTCONF[CDIS] bit is set to "disable core" and the internal default RSTCONF word has to be used. Wrong signal termination or a not finished board design prevent CPU to fetch the reset vector from the memory bus. Additional target board logic needs a huge time after negating the HRESET, for a specific board, logic or memory controller initialisation. The most time this problem could be solved with the SYStem.Option.SLOWRESET. In all these cases the SYStem.Option.IP field has to be set to: 0, if the reset vector is at 0x00000100 (RSTCONF[CIP]==1) 1, if the reset vector is at 0xfff00100 (RSTCONF[CIP]==0)

SYStem.UP fails when flash is not programmed (MPC82XX)
		Why does the debugger fail to connect to the processor after erasing FLASH memory?
	The cause of this problem is that the CPU reads the HARD RESET CONFIGURATION WORD from the erased flash. The HRCW reads as 0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set. Solution: Switch the RSTCONF pin to HIGH to use the internal default reset configuration word (0x00000000). Set SYStem.Option.BASE to 0x00000000 SYStem.UP Set up chip select 0 for FLASH program reset configuration word to flash Switch the RSTCONF pin to LOW to use external reset configuration word Recommendation: Make sure to program reset configuration word to flash immediately after erasing it.

Cannot write to SYPCR (MPC82XX/83XX)
		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.

Error Message: "emulation pod configuration error" (MPC82XX/83XX)
		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.

Instruction/Data Address Breakpoints do not work (MPC82XX/83XX)
		Data/Instruction address breakpoints do not work or stop working at a certain point in target code.
	The instruction/data address breakpoints probably stop working if the target program enables the memory management unit, i.e. MSR_IR and/or MSR_DR bit set to 1. Solution: Type `MMU.ON` to the command line. This command will enable MMU support of the debugger, which will configure the on-chip breakpoints properly.

SYStem.UP fails when flash is not programmed (MPC83XX)
		Why does the debugger fail to connect to the processor after erasing FLASH memory?
	The cause of this problem is that the CPU reads the HARD RESET CONFIGURATION WORD from the erased flash. The HRCW reads as 0xFFFFFFFF, which menas that the CORE_DISABLE bit of the HRCW is set. Solution: Use SYStem.Option.HRCWOVR to override the HRCW with the debugger. Example: SYStem.CPU MPC8349 SYStem.Option.HRCWOVR 0xB060A00004040000 ; 64-bit HRCW set by debugger SYStem.UP SYStem.Option.HRCWOVR ; disable HRCW override Note: The Processor will keep the overridden HRCW intil the next power cycle

Copyright © 2008 Lauterbach Datentechnik GmbH, Fichtenstr. 27, D-85649 Hofolding, 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: Oct-10-2008