We have a producer / consumer application that uses a BF537 on a custom board.
The producer is multi-channel data acquisition controlled by an FPGA over the PPI port.
The consumer (the BF537) streams the data to a Windows host over Ethernet.
The app used to work, but the hardware had to be updated due to parts obsolescence. On the new hardware, the app hangs. The app uses semaphores to manage consumer / producer synchronization.
Differences between the old and new revision per the BF537 program are:
--updated (obsolete PHY per http://www.analog.com/media/en/technical-documentation/application-notes/EE_315_Rev_1_06_07.pdf
--slightly higher data throughput rate: PPI and Ethernet
The hang only occurs if when PPI and Ethernet I/O run concurrently.
When the app hangs, the code sits in the idle thread, and PPI interrupts continue to trigger. The handler posts new data-ready semaphores, but the thread that pends on data-ready never wakes up (or has disappeared). Unhit breakpoints at the end of each thread imply the threads should still be running. After more time, a PPI FIFO overflow is generated and the call stack shows a lock up around __wab7 + xxxx.
We are looking for any suggestions on possible causes and things to try to isolate the issue.
FYI, we checked stack usage on all threads ... plenty of room prior to hang. We have also checked the SDRAM / EBIU settings, and ran a successful SDRAM sweep without error.