PCI configuration transaction problem

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_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? Thanks! Guenter Ebermann

P.S.: We can send parts of our schematic to interested partys.

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