Flushing FIFO crash

[nikolaskaralis]

The following issue(s) happen on both Ubuntu 13 and Mac OS X Mavericks and with both the RHD2132 Amplifier and the RHD2132 Amplifier/Accel. Board.

When connecting the headstage, only one channel is enabled and no signal is displayed (the same as if I had not headstage connected). Also, on the board, the left (red) ~OUT and (green)~IN are lit, but not the right ones.

Dropping the RHYTHM FPGA module on the signal chain gives :

---

FrontPanel DLL loaded. Built: Feb 1 2012 17:34:05

Scanning USB for Opal Kelly devices...

Found 1 Opal Kelly device connected: Device #1: Opal Kelly XEM6010LX45 with serial number 1328000638

FPGA system clock: 100 MHz Opal Kelly device firmware version: 3.1 Opal Kelly device serial number: 1328000638��� Opal Kelly device ID string: Opal Kelly XEM6010

Rhythm configuration file successfully loaded. Rhythm version number: 1

---

Clicking Rescan gives me :

---

Button clicked. Sample rate set to 30000 Number of enabled data streams: 8 Checking for connected amplifier chips... Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Enabled channels: 0 0 0 0 0 0 0 0 Number of enabled data streams: 0 Sample rate set to 30000

---

If I select 16 or 32 channels on the respective A/B/C/D connector on the Source module and click the play button, then either of two things happen :

1. Acquisition starts with no signal shown on the LFP display. Clicking on the play button again to stop acquisition, halts the GUI and the terminal displays: Flushing FIFO
2. Alternatively, the GUI crashes immediately with the following at the terminal :

   ---

   Activating editor Cleared editor array. Inserting Rhythm FPGA at point 0. No source found. No dest found. Updating settings. Rhythm FPGA updating settings. Editor for Rhythm FPGA updating settings. 34 buttons needed. Finished adding new editor.

Play button pressed. Updating connections: Signal chain 0 Source node: Rhythm FPGA, no dest node. Connecting to audio and record nodes.

Enabling processors... Source node received enable signal Expecting 35 channels. Number of 16-bit words in FIFO: 0 Is eval board running: 0 Starting acquisition. Filter Viewport disabled. THIS IS THE MESSAGE THREAD -- CONTROL PANEL CONTROL PANEL GOT THAT LOCK! Segmentation fault (core dumped)

---

From what I understand from these messages, the board does not recognize the headstages.

In addition to the above problem, the GUI seems to respond to this problem in an unpredictable way (either not flushing or crashing immediately).

Any help would be appreciated.

[jsiegle]

You're right...the main problem is that the board does not recognize the headstages, and all the other issues stem from that.

Did you try plugging in the headstages to other input ports (B,C,D)? It's possible that a different one will work.

All the other errors you describe are expected, but we should try to make the program fail more gracefully if no headstages are present.

[jsiegle]

Also make sure the Opal Kelly FPGA is plugged firmly into the acquisition board. If the connection isn't solid, it won't detect the headstages.

[nikolaskaralis]

I couldn't get it to work with none of the ports and the FPGA is plugged in firmly. Thanks for the reply though.

[jsiegle]

It really sounds like a hardware bug, but it's strange that it happens for all of the headstage ports. Can you try it with the Intan interface software: http://www.intantech.com/downloads.html ? It must be compiled from source on Mac and Linux.

If it doesn't work, there could be something wrong with your cable (you can check for continuity with a multimeter). If it does work, then it means something about our software is incompatible with your OS version (I know it hasn't been tested with Mavericks, not sure about Ubuntu 13).

[ckemere]

I'm running on Mavericks without a problem.

Could also be a faulty headstage?

--caleb On Nov 30, 2013 10:34 PM, "Josh Siegle" notifications@github.com wrote:

It really sounds like a hardware bug, but it's strange that it happens for all of the headstage ports. Can you try it with the Intan interface software: http://www.intantech.com/downloads.html ? It must be compiled from source on Mac and Linux.

If it doesn't work, there could be something wrong with your cable (you can check for continuity with a multimeter). If it does work, then it means something about our software is incompatible with your OS version (I know it hasn't been tested with Mavericks, not sure about Ubuntu 13).

— Reply to this email directly or view it on GitHubhttps://github.com/open-ephys/GUI/issues/90#issuecomment-29567220 .

[jsiegle]

Hey Nikolas—have you made any progress in tracking down the problem?

[nikolaskaralis]

Hey Josh. The current status is : I tested the cable and it works (all 12 pins), I believe the headstage is not the cause, because I we have two different headstages (one with accelerometer and one without) and neither works, so it shouldn't be that, none of the four ports works, fpga is plugged in well (and it is recognized by the software anyway) and the issue is the same on Mavericks and Ubuntu. I should mention I had tried to record (from signal generator) a few months ago and it did work at the time, so I'm thinking it is probably hardware issue (board related?) that occurred in between. I will try to compile the Intan software in the next days, to see if by any chance I can get it working with that.

In any case, another "issue" I notice (under these pathological conditions at least) is that the LED activity of the board is somewhat unpredictable. Meaning that different sets of LEDs are active in different instances under the same condition. Also the left-most out and in LEDs corresponding to two of the HDMI ports are most of the time on, with red and green color respectively (not sure if this is related with the issues above).

[jvoigts]

Hi, this does sound like there is some issue with the board. The fact that the SPI for the headstages is broken and the leds are not always showing the same pattern suggests that the connection between the fpga and the board is not working correctly. The last two LEDs should be red and green (this is just some leftover code from testing that we never removed from the final bit file). Can you try checking the soldering on the two long fpga board connectors?

Another thing thats easy to test are the voltage levels, we have a few test points on the board that are labelled with 3.3 and +-5V. If a regulator got damaged somewhere along the way you would see it there.

[jsiegle]

My money is on the 3.5V regulator for the headstages. That would explain why all four headstages ports don't work, and it's a problem we saw with one other system after shipping. You can check this by flipping the board over and putting a multimeter between the GND_3 and +3V5_1 pins.

If so, it's cheap to order a replacement from DigiKey.

[nikolaskaralis]

Hey Jakob and Josh. I tested all the test points. It turns out that as you predicted the 3.5V regulator is the problem, since testing between the GND_3 and +3V5_1 pins I get 60mV. I will get a replacement soon. Since you say it happened again, do you have any idea on what could be the reason for that? Could it be dangerous for the headstage such a damaged regulator?

Thanks for all the help.

[jvoigts]

Hi, good to hear, at least it's a tractable issue and something thats easy to fix. I don't think this should affect headstages, in both cases that we've seen the voltage just drops.

We'll try to figure out what could have caused this, i just looked at the circuit again and there's nothing obvious, its just a standard regulator after all. I'll poke at it some more and see if maybe we need to add some over voltage protection on the input side or something like that.

[nikolaskaralis]

Hi all! This is to say that I finally got and installed the replacement voltage regulator and this fixed the issue.

Thanks again!

Nikolas