Topic: ETHAPI crash in sipif.cpp  (Read 10355 times)

Blair Fonville December 16, 2014, 09:21 PM

  • Member
  • *
  • Posts: 12
I am working on some code for an FMC150 on ML605 which indefinitely grabs blocks of data from the ADC. The code first does all the initializations (borrowed from the ref design) then starts a thread which continually arms the FMC150 SIP, sends a sw trigger, reads the ADC data block, and repeats. It works for a while, but at random occasions it crashes at sipif_readdata(void *buf, uint32_t size) within sipif.cpp. Specifically at the line:  rceth = g_pETH_ReadBlock((PUCHAR)buf, size, 0); within the switch-statement's SIPIF_ETHAPI case.

I know this isn't much to go on, but any ideas on this? Is this a known issue? Am I using an outdated API?

Thanks,
Blair Fonville

arnaudNL December 17, 2014, 07:51 AM (#1)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Blair,


First of all our software in not thread-safe so you need to make sure you don't have several players communicating from different threads. Then maybe the interface is stressed too much. I am not sure what data rate you are trying to achieve but generally anything above a few MB/s will tend to fail.


What would be interesting to know is if g_pETH_ReadBlock is getting NULL maybe. ETHAPI API is not reliable/streaming interface as it was designed for snapshots application. Maybe a memory leak bringing the whole thing down. Also makes sure to download and install the latest WinPCAP version from their website.


We haven't heard about such crashes. I know my answer is probably not helping you much and I am sorry about that. Have you tried to run the FMC Analyzer? I think the analyzer is doing pretty much that using the same code base.


Best Regards,
Arnaud

arnaudNL December 19, 2014, 10:13 AM (#2)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 7110
Dear Blair,


I haven't heard back from you, do you have any updated for us?


Best Regards,
Arnaud

ebarhorst December 22, 2014, 08:30 AM (#3)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Dear Blair,


Have your questions been answered and can I close the topic?


Best regards,
Erik

Blair Fonville December 24, 2014, 12:14 AM (#4)

  • Member
  • *
  • Posts: 12
Hi Arnaud,

Sorry for the late reply. I left for vacation on the day of my post (and will be out of the office until Jan 2). But I can answer most of your questions...

1. Before I left, I ran the FMC Analyzer several times for extended periods. Each time it also crashed at some point. Always at seemingly random intervals. I have no way to determine the cause of the Analyzer crashes, as I cannot run them within a debugger, of course.

2. The g_pETH_ReadBlock function was not receiving nullptr (this was the first thing I checked).

3. The threading is inconsequential in this problem. It is well protected but also this is a small application and there is no contention for communication. This is the only working thread, the main thread only waits for user interaction to change polling rates and such. The crash occurs without ever receiving user feedback from the main thread.

4. Finally, there is no memory leak. I also monitored this closely to be sure.

Blair


ebarhorst December 24, 2014, 05:14 AM (#5)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi Blair,


Arnaud is on vacation as well now  :)


As Arnaud indicated the ethernet interface for the FMC150 reference design is not designed to be a reliable, fail safe interface. It is there to get a quick and easy start with the FMC board and do burst based snapshots to analyse the ADC performance or your aalgorithm It is communicating on the RAW ethernet level with no data protection. Some of the more common reasons for the communication to fail are;
- HOST computer is not able to empty the etherenet receive buffer fast enough => packets are lost
- HOST starts to communicate on the ethernet link to request some global status. If this happens in the middle of a communication with the ML605 the ethernet interface will get stuck. To reduce the chances of this happening all ethernet adapter protocols apart from the 4DSP ethernet protocol driver shoudl be disabled through the adapter properties window.


You can contact the 4DSP sales and receive a license for our PCIecpress core  if you need a more reliable communication with the ML605


Best regards,
Erik

ebarhorst January 07, 2015, 09:50 AM (#6)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
Hi Blair,


would you have an update on this topic, or can I close it?


Best regards,


Erik

Blair Fonville January 07, 2015, 12:49 PM (#7)

  • Member
  • *
  • Posts: 12
Go ahead and close it. I'll design an TCP based solution instead. Thanks.

ebarhorst January 07, 2015, 01:05 PM (#8)

  • 4DSP Staff (EU)
  • Administrator
  • Member
  • *****
  • Posts: 1222
This topic is being closed because the issue is considered as resolved by 4DSP. Feel free to create a new topic for any further inquiries.