FAQs for BDM-PPC440


The embedded tools company

Search FAQs



PDF document ( 66KB / 07-Sep-2016 )


TOP

APM86x90 verus APM86x90B (APM86190)

Ref: 0411
What is the difference between APM86x90 and APM86x90B?

Use CPU selection APM86x90 for -> Rev A (primary silicon)
Use CPU selection APM86x90B for -> Rev B,C,D,E (all newer one)

TOP

Protected Access Error (APM86190)

Ref: 0409
What does an "Protected Access Error" mean?

Section Memory Controller initialization of User Guide: After Reset the Memory Queue, Memory Controller and DDR PHY are hold in Reset and clocks are disabled. Any request on the PLB Bus designating DRAM or one of the above Peripherals (ERPN 0x0 to 0x3) will cause an infinite stall of the CPU (=>RESET). Furthermore the L2 Cache can not be enables (L2COBE) before the above mentioned Peripherals are out of Reset and working. A such situation is guarded by an "Protected Access Error". The Memory views addressing ERPN 0x0 to 0x3 (PLB5) are unlocked as soon as the clock gating is enabled and the reset is deasserted.

TOP

SYS.Detect.CPU ApmPacketProSingle/Dual (APM86190)

Ref: 0408
Why does SYStem.Detect.CPU detect an ApmPacketProSingle/Dual and not the correct CPU derivative.

Many devices of the APM86xxx family share common JtagIDs which do not allow to distinguish between the single derivatives. As a solution a general ApmPacketProSingle/Dual device is detected to allow general debugging.

TOP

SYStem.Up/InTargetReset with APM86xxx (APM86190)

Ref: 0410
The SYStem.Up/InTargetReset doesn't work with an APM86xxx device! The contents of the memory views are wrong.

Some Revisions of the APM86xxx family need a special handling for Reset. As a rule of thumb the Revison A e.g. of an APM86x90 requires an SYStem.Option.ResetMode CHIP while the later revisions require an SYStem.Option.ResetMode SYSTEM.

TOP

APM86x90 verus APM86x90B (APM86190B)

Ref: 0411
What is the difference between APM86x90 and APM86x90B?

Use CPU selection APM86x90 for -> Rev A (primary silicon)
Use CPU selection APM86x90B for -> Rev B,C,D,E (all newer one)

TOP

APM86x90 verus APM86x90B (APM86290)

Ref: 0411
What is the difference between APM86x90 and APM86x90B?

Use CPU selection APM86x90 for -> Rev A (primary silicon)
Use CPU selection APM86x90B for -> Rev B,C,D,E (all newer one)

TOP

Protected Access Error (APM86290)

Ref: 0409
What does an "Protected Access Error" mean?

Section Memory Controller initialization of User Guide: After Reset the Memory Queue, Memory Controller and DDR PHY are hold in Reset and clocks are disabled. Any request on the PLB Bus designating DRAM or one of the above Peripherals (ERPN 0x0 to 0x3) will cause an infinite stall of the CPU (=>RESET). Furthermore the L2 Cache can not be enables (L2COBE) before the above mentioned Peripherals are out of Reset and working. A such situation is guarded by an "Protected Access Error". The Memory views addressing ERPN 0x0 to 0x3 (PLB5) are unlocked as soon as the clock gating is enabled and the reset is deasserted.

TOP

SYS.Detect.CPU ApmPacketProSingle/Dual (APM86290)

Ref: 0408
Why does SYStem.Detect.CPU detect an ApmPacketProSingle/Dual and not the correct CPU derivative.

Many devices of the APM86xxx family share common JtagIDs which do not allow to distinguish between the single derivatives. As a solution a general ApmPacketProSingle/Dual device is detected to allow general debugging.

TOP

SYStem.Up/InTargetReset with APM86xxx (APM86290)

Ref: 0410
The SYStem.Up/InTargetReset doesn't work with an APM86xxx device! The contents of the memory views are wrong.

Some Revisions of the APM86xxx family need a special handling for Reset. As a rule of thumb the Revison A e.g. of an APM86x90 requires an SYStem.Option.ResetMode CHIP while the later revisions require an SYStem.Option.ResetMode SYSTEM.

TOP

APM86x90 verus APM86x90B (APM86290B)

Ref: 0411
What is the difference between APM86x90 and APM86x90B?

Use CPU selection APM86x90 for -> Rev A (primary silicon)
Use CPU selection APM86x90B for -> Rev B,C,D,E (all newer one)

TOP

Protected Access Error (APM86491)

Ref: 0409
What does an "Protected Access Error" mean?

Section Memory Controller initialization of User Guide: After Reset the Memory Queue, Memory Controller and DDR PHY are hold in Reset and clocks are disabled. Any request on the PLB Bus designating DRAM or one of the above Peripherals (ERPN 0x0 to 0x3) will cause an infinite stall of the CPU (=>RESET). Furthermore the L2 Cache can not be enables (L2COBE) before the above mentioned Peripherals are out of Reset and working. A such situation is guarded by an "Protected Access Error". The Memory views addressing ERPN 0x0 to 0x3 (PLB5) are unlocked as soon as the clock gating is enabled and the reset is deasserted.

TOP

SYS.Detect.CPU ApmPacketProSingle/Dual (APM86491)

Ref: 0408
Why does SYStem.Detect.CPU detect an ApmPacketProSingle/Dual and not the correct CPU derivative.

Many devices of the APM86xxx family share common JtagIDs which do not allow to distinguish between the single derivatives. As a solution a general ApmPacketProSingle/Dual device is detected to allow general debugging.

TOP

SYStem.Up/InTargetReset with APM86xxx (APM86491)

Ref: 0410
The SYStem.Up/InTargetReset doesn't work with an APM86xxx device! The contents of the memory views are wrong.

Some Revisions of the APM86xxx family need a special handling for Reset. As a rule of thumb the Revison A e.g. of an APM86x90 requires an SYStem.Option.ResetMode CHIP while the later revisions require an SYStem.Option.ResetMode SYSTEM.

TOP

Protected Access Error (APM86692)

Ref: 0409
What does an "Protected Access Error" mean?

Section Memory Controller initialization of User Guide: After Reset the Memory Queue, Memory Controller and DDR PHY are hold in Reset and clocks are disabled. Any request on the PLB Bus designating DRAM or one of the above Peripherals (ERPN 0x0 to 0x3) will cause an infinite stall of the CPU (=>RESET). Furthermore the L2 Cache can not be enables (L2COBE) before the above mentioned Peripherals are out of Reset and working. A such situation is guarded by an "Protected Access Error". The Memory views addressing ERPN 0x0 to 0x3 (PLB5) are unlocked as soon as the clock gating is enabled and the reset is deasserted.

TOP

SYS.Detect.CPU ApmPacketProSingle/Dual (APM86692)

Ref: 0408
Why does SYStem.Detect.CPU detect an ApmPacketProSingle/Dual and not the correct CPU derivative.

Many devices of the APM86xxx family share common JtagIDs which do not allow to distinguish between the single derivatives. As a solution a general ApmPacketProSingle/Dual device is detected to allow general debugging.

TOP

SYStem.Up/InTargetReset with APM86xxx (APM86692)

Ref: 0410
The SYStem.Up/InTargetReset doesn't work with an APM86xxx device! The contents of the memory views are wrong.

Some Revisions of the APM86xxx family need a special handling for Reset. As a rule of thumb the Revison A e.g. of an APM86x90 requires an SYStem.Option.ResetMode CHIP while the later revisions require an SYStem.Option.ResetMode SYSTEM.

TOP

Protected Access Error (APM86791)

Ref: 0409
What does an "Protected Access Error" mean?

Section Memory Controller initialization of User Guide: After Reset the Memory Queue, Memory Controller and DDR PHY are hold in Reset and clocks are disabled. Any request on the PLB Bus designating DRAM or one of the above Peripherals (ERPN 0x0 to 0x3) will cause an infinite stall of the CPU (=>RESET). Furthermore the L2 Cache can not be enables (L2COBE) before the above mentioned Peripherals are out of Reset and working. A such situation is guarded by an "Protected Access Error". The Memory views addressing ERPN 0x0 to 0x3 (PLB5) are unlocked as soon as the clock gating is enabled and the reset is deasserted.

TOP

SYS.Detect.CPU ApmPacketProSingle/Dual (APM86791)

Ref: 0408
Why does SYStem.Detect.CPU detect an ApmPacketProSingle/Dual and not the correct CPU derivative.

Many devices of the APM86xxx family share common JtagIDs which do not allow to distinguish between the single derivatives. As a solution a general ApmPacketProSingle/Dual device is detected to allow general debugging.

TOP

SYStem.Up/InTargetReset with APM86xxx (APM86791)

Ref: 0410
The SYStem.Up/InTargetReset doesn't work with an APM86xxx device! The contents of the memory views are wrong.

Some Revisions of the APM86xxx family need a special handling for Reset. As a rule of thumb the Revison A e.g. of an APM86x90 requires an SYStem.Option.ResetMode CHIP while the later revisions require an SYStem.Option.ResetMode SYSTEM.

TOP

No Source Code shown on Xilinx Targets (MICROBLAZE)

Ref: 0214
Virtex: after loading an ELF file (PPC or Microblaze) to the target, no source code is displayed. Why?

The Xilinx compilers from the EDK operate inside a Cygwin environment and therefore create debug information with non-standard path names. Use the option /cygdrive when loading these ELF files: data.load.elf eventgen_ppc/executable.elf /CYGDRIVE

TOP

Connection to Target Fails (PPC440)

Ref: 0291
Why does the connection to the target fails?

When connecting to XILINX targets be sure to use a recent version of the debug cable (see picture).
With the old version of the debug cable target connection will fail or be unreliable.

TOP

No Source Code shown on Xilinx Targets (PPC440)

Ref: 0214
Virtex: after loading an ELF file (PPC or Microblaze) to the target, no source code is displayed. Why?

The Xilinx compilers from the EDK operate inside a Cygwin environment and therefore create debug information with non-standard path names. Use the option /cygdrive when loading these ELF files: data.load.elf eventgen_ppc/executable.elf /CYGDRIVE

TOP

Enable/configure mixed TRACE Interface (PPC440GX)

Ref: 0203
How to enable/configure muxed trace interface for TRACE

1. Enable Trace Broadcast:
  • CCR0[DTB]=0
    (Register can be found in the tree "Instruction and Data Cache"-"Core Configuration Registers")
2. Select the pin group for the trace signals:
    (! [CTEMS] register bit description in "PPC440GX_UM2001_v1_04.pdf" is upside down!)
  • SDR0_PFC1[CTEMS]=0 == GROUP A
    • TrcTS1:6 muxed with GPIO
    • (muxes the CPU trace functionality on the trace interface signals TrcTs1, TrcTS2, TrcTS3, TrcTS4 and TrcTS5. With this selection ethernet groups 4, 5 and GPIO's GPIO27, GPIO28, GPIO29, GPIO30 and GPIO31 cannot be used.)
    Configure GPIO pins:
  • SDR0_PFC0[G18E-G22E]=1 (Select TrcESx as GPIOx)
  • SDR0_PFC1[CTEMS]=1 == GROUP B
    • TrcTS1:6 muxed with EBC/EBMI
    • (muxes the CPU trace functionality on the external master interface signals BusReq, ExtAck, ExtReq, HoldAck, HoldReq and PerErr. With this selection the external master interface cannot be used.)
    Disable the Lauterbach analyzer TERMINATION of the Trace Preprocessor during initialization:
  • a.TERMINATION OFF
    • if termination is enabled, the signals will be terminated to the THRESHOLD voltage. (e.g 1.5 V). This will disturb/lock the "HoldReq" signal and stop the CPU at all.
    • after the EBC bus interface is disabled for trace (SDR0_PFC0[TRE]=1 + SDR0_PFC1[CTEMS]=1), the termination can be enabled afterwards.
3. Enable Trace output:
  • SDR0_PFC0[TRE]=1


TOP

Software Breakpoints Problem (PPC4XX)

Ref: 0244
Error message: software breakpoints not possible with current system setting

One reason for this error message is that the option sys.o.icflush is OFF. Without being able to flush the ICache the debugger cannot write software breakpoints. Use the following command to allow the debugger to flush the ICache after writing a SW breakpoint:
sys.o.icflush ON

TOP

Stepping over TLBWE instruction (PPC4xx)

Ref: 0377
Stepping over TLBWE instruction result in another program flow as in run mode.

There is a difference between stepping and running over a tlbwe instruction sequence.

In run mode, the CPU performs the code as usual, the execution of a tlbwe instruction changes the UTLB contents but does not cause a context synchronization and thus does not invalidate or otherwise update the shadow TLB entries.
Any modification in the UTLB will not be active until the next context synchronizing (ISYNC, RFI, RFCI, SC, interrupts) takes place.
In usual, the application prepare the hole new MMU map, and switch to the new MMU table with a context synchronising instruction at the end of the TLB instruction sequence.

If debug mode, CPU is stopped and the debugger have access to register and memory, each single step forces implicit an ISYNC command. This is a special behaviour of the debug mode and mean, with each step a context synchronizing will be forced. Therefore its not possible to step over the standard MMU initialisation sequence.

A recommendation is to set at breakpoint (BP) at the end or after of the TLB init loop. May be at the ISYNC instruction, and run over the TLB setup routine to the BP.

TOP

ISOCM Access in Xilinx VirtexFX Chips (VIRTEX-PPC440)

Ref: 0216
How can I enable access to ISOCM memory in Xilinx VirtexFX chips?

For accessing the ISOCM memory (instruction side OCM) attached to the PPC405 in Xilinx VirtexFX chips, a special access mechanism via DCR is required. This mechanism is only available from Virtex4 onwards. It is not supported in Virtex2Pro.
For enabling the ISOCM access in Trace32 use the option
sys.o.isocm BASEADDR
where BASEADDR is the beginning of the ISOCM memory. The default value is 0xFFFF.FFFF (disabled).
The feature requires Trace32 SW from 2006-10-20 or later.

TOP

Debugging and Tracing Embedded PPC Cores in Xilinx FPGAs (Virtex-PPC4XX)

Ref: 0208
How should I connect TRACE32-ICD JTAG connector to a Xilinx target? What are the correct IRPRE/IRPOST and DRPRE/DRPOST settings?

This document describes for Xilinx Virtex chips how to:
  • Calculate the multicore pre/post settings
  • Debug the embedded PPC405/PPC440 cores
  • Trace the program flow of PPC405/PPC440 cores NOTE: In some cases the application advises to use the CPU setting "VirtexPPC". You will need a SW from May 2006 or later for this. If your SW does not offer this setting, you need to get an update. Any attempt to use PPC405F or PPC405D instead will fail and is a waste of time. To debug PPC440 cores in a Virtex5 (e.g. SYStem.CPU Virtex5PPC, PPC440G, ...) will need SW newer than March 2008.




  • 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: 22-Sep-2016