Connect with us

PCI configuration transaction problem

Discussion in 'Electronic Design' started by Guenter Ebermann, Feb 28, 2007.

Scroll to continue with content
  1. We have designed a PMC card for FlexRay (time triggered bus sytem used
    in the automotive sector) based applications.

    Our Setup (PMC Card):
    - CPU: MPC5200B (acts as PCI-Arbiter)
    - PCI Bridge: PI7C8150B (driven in asynchronous mode)
    - components also connected to the extended local bus of the MPC5200B:
    Flash, USB, FPGA, CPLD

    We are using our PMC card plugged into a PCI slot (via a PMC Carrier
    Card) to use it in normal PC's.

    We have succesfully made startups of the whole board.

    At last we are trying to test the PCI unit and we discovered the
    following problem when trying to make PCI configuration read accesses
    from the host PC (linux 2.4.27, debian sarge) to the target MPC5200B
    (RedBoot, initializing the PCI unit):

    When the computer (host) starts, the linux-kernel is able to correctly
    read out the Vendor and Device-ID from the PCI Bridge and the MPC5200
    device, during traversing the PCI bus upon boot to configure all
    connected devices. This can be tested using lspci (pciutils package)
    after booting (this command reads out the PCI data structures of
    the kernel) or enabling PCI debug messages in the kernel and watch
    console output during boot time.

    After booting we made several tests to read out the configuration
    section of the PCI bridge in a loop comparing them with previous
    reads. This test went ok.

    But when we are trying to read the PCI configuration section of the
    MPC5200B, we get differing results mostly every time. We read out the
    configuration section by reading from the proc file system (e.g. xxd
    /proc/bus/pci/devices/02/0a.0 reading the whole configuration
    area). The kernel then makes a PCI Type 1 configuration transaction to
    the PCI bridge, which in turns makes a PCI Type 0 transaction to the
    MPC5200B for each byte we want to read.

    We also issue setpci -d<VENDOR><DEVICE> VENDOR_ID/DEVICE_ID to trigger
    exactly one PCI read transaction from the MPC5200 confiuration area.
    For the Vendor and Device ID registers we get 0xFFFFFFFF. This is
    strange since the linux kernel itself read out the right values during
    boot time.

    Furthermore, when we read out the PCI status registers of the Bridge,
    we see that Bit 29 (Received Master Abort) and Bit 31 (Detected Parity
    Error on secondary side) are both set to 1. When we read out the status
    registers of the MPC5200 the parity error bit is set there too.

    Do you have any idea, what could cause such a behaviour?
    Guenter Ebermann

    P.S.: We can send parts of our schematic to interested partys.
  2. I am posting this answer here, just if other people has
    similar problems making startups with their pci-boards.

    Our problem was with the clock: We connected the
    clock output from the MPC5200B to the an internal
    prescaler of the Asynchrous PCI bridge just to feed-back
    the prescalers output to the real clock intput of the Bridge.

    As we connected the MPC5200 clock output directly to the
    bridge clock input the board worked (PCI transactions ...).

    The bridge just had the possibility of the prescaler to
    directly connect an oscillator to it and use the output
    of the prescaler as clock input for the secondary PCI bus.
    It was not meant to be used as clock source if another
    device generates the clock (in our case the MPC5200), as
    this will generate a phase shift in how the MPC5200 generates
    the clock and the Bridge sees the clock (because if the bridge's
    internal prescaler).
Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day