intermittent sysACE hang on ML310

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 says

"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 CompactFlash. 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 was not granted because the configuration controller currently has access to the CompactFlash.

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 event."

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 FPGA?

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.

Thanks,

Paul

Reply to
Bo
Loading thread data ...

Hi

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

Reply to
more

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.