intermittent sysACE hang on ML310

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
After adding Ethernet core (full) to our ML310 design, (with an Intel
development PHY board connected through spare GPIO pins on PM1), we are
seeing intermittent sysACE / Compact Flash lockups in the vxWorks boot.

Through many toils and snares, we have determined that when this lockup
occurs, the actual hang is occurring on the line:

while (XSysAce_Lock(AcePtr, XFALSE) != XST_SUCCESS);

in the xsysaceblkadapter.c file in the function:
"XSysAceBlkAdapter_Init(Xuint16 DeviceId, unsigned MaxPartitions)."

It seems that disconnecting our Ethernet cable during the boot-up, makes the
problem disappear--- and I have no earthly idea how Ethernet
traffic/interrupts can affect sysACE controller. I'm guessing a timing/FPGA
build issue, but have no clue where to start on finding/isolating/fixing the
issue--if indeed it is in the FPGA place/route/timing arena.

The comments in the xsys driver code, are puzzling to me. In particular, it

"This function blocks waiting on a lock from the System ACE controller. If
 a JTAG configuration is in process, this function will block until the
 configuration process is done."

and in the comments for the XSysAce_Lock() function:

"If the user requests a forced lock, the JTAG configuration controller will
 be put into a reset state in case it currently has a lock on the
 This effectively aborts any operation the configuration controller had in
 progress and makes the configuration controller restart its process the
 next time it is able to get a lock.

 A lock must be granted to the user before attempting to read or write the
 CompactFlash device.

Force is a boolean value that, when set to XTRUE, will force the MPU
lock to occur in the System ACE.  When set to XFALSE, the lock is
requested and the device arbitrates between the MPU request and
JTAG requests. Forcing the MPU lock resets the configuration
controller, thus aborting any configuration operations in progress.

return  XST_SUCCESS if the lock was granted, or XST_DEVICE_BUSY if the lock
not granted because the configuration controller currently has access to the

If the lock is not granted to the MPU immediately, this function removes its
request for a lock so that a lock is not later granted at a time when the
application is (a) not ready for the lock, or (b) cannot be informed
asynchronously about the granted lock since there is no such interrupt

Now this leads me to the following questions:

1) why isn't the initialize function forcing a lock? Would something bad
happen if it did?

2) I don't understand what will happen in the lock routine if force is true
when it 'releases the reset'. Does this mean it'll try to re-configure the

3) Should I put a timer/timeout around the while statement and if it times
out, call it again with Force=TRUE?

Has anyone else encountered problems like this? I admit is very peculiar and
troubling that adding an Ethernet core is impacting the sysACE at all.



re:intermittent sysACE hang on ML310

   Why do you need to add an ethernet core? I think there has alread

been an ethernet core on ML310. I also want to access the ethernet
which is connectted to PCI bus. But I cannot figure out how to acces
it through PCI. Do you have any experience about that?

   Thank you

Site Timeline