FAQs for JTAG-PQ2


The embedded tools company

Search FAQs



PDF document ( 47KB / 19-May-2016 )


TOP

BUS-ERRORS on valid addresses (MPC826x/80/7x/41/42)

Ref: 0110
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.


  • TOP

    Problems when changing IMMR (software before 11/2007) (MPC82XX)

    Ref: 0287
    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


    TOP

    Problems when changing IMMR (sw since 11/2007) (MPC82XX)

    Ref: 0205
    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


    TOP

    Processor seems to step backwards (MPC82XX)

    Ref: 0112
    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.

    TOP

    SYStem.Option.BASE.AUTO does not work (MPC82XX)

    Ref: 0163
    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.

    TOP

    SYStem.Option.IP.AUTO does not work (MPC82XX)

    Ref: 0164
    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)


    TOP

    SYStem.UP fails when flash is not programmed (MPC82XX)

    Ref: 0132
    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.

    TOP

    Cannot write to SYPCR (MPC82XX/83XX)

    Ref: 0045
    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.

    TOP

    Error Message: "emulation pod configuration error" (MPC82XX/83XX)

    Ref: 0105
    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.


    TOP

    Instruction/Data Address Breakpoints do not work (MPC82XX/83XX)

    Ref: 0186
    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.

    TOP

    Memory access fails after program ran (MPC83XX)

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

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

    TOP

    SYStem.UP fails when flash is not programmed (MPC83XX)

    Ref: 0288
    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
    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 © 2016 Lauterbach GmbH, Altlaufstr.40, D-85635 Höhenkirchen-Siegertsbrunn, Germany  Impressum
    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: 19-Aug-2016