MCF5374 PCI->XLB->FLEXBUS aligned transfers hang the core?

--000e0cd24746d16e4e0468db58e5
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have ported a previously working USB host EHCI driver from an MCF5373 with
an internal USB host to an MCF5474 with an NXP ISP1564 HS USB PCI Host
controller on the PCI bus. The USB controller is a PCI bus master and it
initiates transfers over the PCI bus, which then accesses the Flex bus via
the XLB bus.

During the setup phase 8 byte command packets are sent and these are located
in a 32 bit wide SRAM on a chip select. If the command is not on an 8 byte
boundary then it works as expected. If the transfer is on an 8 byte boundary
then the CPU seems to halt. If I hit break in my debugger then the PC is on
the first instruction of my XLB interrupt handler. If I hit run then the
interrupt handler runs and reports a bus error at the address of my command
packet. It indicates that it is an 8 byte burst transfer on the XLB.

If I make the XLB timeout very big, e.g. 8191, clocks then I don't get a bus
timeout but the processor still gets stuck. When I hit break it is always on
the first instruction of an unrelated DMA interrupt handler. If I run then
the USB transaction completes successfully and the processor halts at the
next one, and so on.

Note the debugger is not having to do a force TA, it is simply asserting
BKPT and waiting for FREEZE.

I can't see how this is anything other than a bug in the CPU. What state can
the CPU be in where it is not processing instructions but it will respond to
* *BKPT?

--000e0cd24746d16e4e0468db58e5
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I have ported a previously working USB host EHCI driver from an MCF5373 wit=
h an internal USB host to an MCF5474 with an NXP ISP1564 HS USB PCI Host co=
ntroller on the PCI bus. The USB controller is a PCI bus master and it init=
iates transfers over the PCI bus, which then accesses the Flex bus via the =
XLB bus.<br>
<br>During the setup phase 8 byte command packets are sent and these are lo=
cated in a 32 bit wide SRAM on a chip select. If the command is not on an 8=
 byte boundary then it works as expected. If the transfer is on an 8 byte b=
oundary then the CPU seems to halt. If I hit break in my debugger then the =
PC is on the first instruction of my XLB interrupt handler. If I hit run th=
en the interrupt handler runs and reports a bus error at the address of my =
command packet. It indicates that it is an 8 byte burst transfer on the XLB=
.<br>
<br>If I make the XLB timeout very big, e.g. 8191, clocks then I don&#39;t =
get a bus timeout but the processor still gets stuck. When I hit break it i=
s always on the first instruction of an unrelated DMA interrupt handler. If=
 I run then the USB transaction completes successfully and the processor ha=
lts at the next one, and so on.<br>
<br>Note the debugger is not having to do a force TA, it is simply assertin=
g BKPT and waiting for FREEZE.<br><br>I can&#39;t see how this is anything =
other than a bug in the CPU. What state can the CPU be in where it is not p=
rocessing instructions but it will respond to<b> </b>BKPT?<br>
<br><br><br><br><br>

[email protected]=09Send a post to the list.
[email protected]=09Join the list.
[email protected]=09Join the list in digest mode.
[email protected]=09Leave the list.
--000e0cd24746d16e4e0468db58e5--