FAQs for PowerQUICC II/Pro Debugger
The embedded tools company

Search FAQs



PDF document ( 161KB / 27-Mar-2022 )


After SYStem.Up or when opening a dump/register window all displayed memory data is invalid (e.g. 0xDEADBEEx). (MPC826x/80/7x/41/42)
Ref: 0110

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.



The debugger's memory access works after SYStem.UP, but fails after the running the application. What can be the problem? (MPC83XX)
Ref: 0360

For MPC834x, MPC837x and MPC831X, the unit performing memory accesses for the debugger is clocked together with another peripheral block. For proper memory access, make sure that this unit does not get disabled by your application.

The units which must be kept enabled are:
  • MPC834x: TSEC2
  • MPC837x: eSDHC / I2C1
  • MPC831x: encryption engine
Make sure that the corresponding peripheral block does not get disabled in the System Clock Control Register (SCCR).

There are few exceptions where SYStem.Option.BASE.AUTO (default setting) does not work: (MPC82XX)
Ref: 0163

  • 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.

There are few exceptions where SYStem.Option.IP.AUTO (default setting) does not work: (MPC82XX)
Ref: 0164

  • 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)


What causes "emulation pod configuration error" when trying to start the debug session?
Ref: 0105

This error can have several 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 automatic detection (SYStem.DETECT CPU).
  • The CPU on the target is not supported by the used debugger software version. Please check if a new version is available in the Downloads section.
In any case please check the AREA window (Menu: View - Message Area) for further information.

When changing the IMMR base address to a new value, memory access results in a buserror (for software since 11/2007). (MPC82XX)
Ref: 0205

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.
  • Execute SYStem.UP
  • Set SYStem.Option.BASE AUTO (enable automatic IMMR change detection)
  • Start execution until the instruction that changes IMMR is reached, e.g. GO 0xFFF09038 /ONCHIP
  • Execute an assembler single step Step.ASM
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


When changing the IMMR base address to a new value, memory access results in a buserror (for software before 11/2007). (MPC82XX)
Ref: 0287

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 PRACTICE script (*.cmm): 
    SCREEN.ON
ENTRY &NewBase
IF "&NewBase"==""
  ENDDO
&OldBase=IOBASE()
PER.Set ASD:(&OldBase|0x101A8) %LONG &NewBase
SYStem.Option.BASE &NewBase
PRINT "change old (&OldBase) IOBASE address to =: " iobase()
ENDDO

    With SCREEN.ALways not se 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 command 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


Why does the debugger fail to connect to the processor after erasing FLASH memory? (MPC82XX)
Ref: 0132

The cause of this problem is that the CPU reads the HARD RESET CONFIGURATION WORD from the erased flash. The 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.

Why does the debugger fail to connect to the processor after erasing FLASH memory? (MPC83XX)
Ref: 0288

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
Notes:
  • The Processor will keep the overridden HRCW intil the next power cycle or power-on reset
  • If HRESET of the JTAG connector asserts PORESET on the target, then SYStem.Option.HRCWOVR does not work. When designing a target, is is recommended to connect JTAG_HRESET to CPU_HRESET.





Copyright © 2023 Lauterbach GmbH, Altlaufstr.40, 85635 Höhenkirchen-Siegertsbrunn, Germany   Impressum     Privacy Policy
The information presented is intended to give overview information only.
Changes and technical enhancements or modifications can be made without notice. Report Errors
Last generated/modified: 02-Jan-2023