[panels] Re: freeze-ups

  • From: Mark Frye <frye@xxxxxxxxxxxxxxx>
  • To: panels@xxxxxxxxxxxxx
  • Date: Fri, 14 Jul 2006 13:46:41 -0700

Hi Mike,
I think we have the problem narrowed down to a screwy panel. When the freeze happens, Brian power cycles the arena only, and the system picks up as if the freeze didn't happen, so it's not likely to be the controller.


We're trying to isolate the bad panel. Could there be a static electricity problem? Seems that the problem is worse the last few days, it's been very dry and hot.

-Mark


Michael Reiser wrote:
Hi Mark, All -

Everyone has their own take on debugging, for me the first rule is "pay attention to the conditions that give rise to the bug...no detail is too small"
There are many reasons why the system might freeze: one component is stuck - could be Matlab, the controller, or (a few, all of) the panels. Also it could be a communication problem - the PC might be having communication problems with the controller (this could be controller-side or PC-side), the controller may not be able to communicate with the panels. I could imagine that any of these would cause the system to freeze, and a different remedy would be necessary for each of these problems. The best thing to do would be to keep a small list of freezing occasions, and try to find some pattern. In the Dickinson lab we have about 5-6 controllers being used regularly and I have not heard anyone complain about repeated freezing problems.


If I had to guess at the cause, I think the most likely source of a system freeze is actually the comm. link between the CF card and the Atmel microcontroller that reads data from this card. I have had one controller (the oldest and most heavily-used) that has frozen up a few times during an experiment. This problem was remedied by using a different (new) CF card. A related problem some people may have observed is a resetting of the CF-reading controller (probably the only way this would be observed is if the second serial port monitor is being used) - the controller starts its initialization routine and then quickly resets (either at the end or in the middle of this routine), and repeats this indefinitely. This problem also goes away if the CF card is replaced with a new one (or even just pressing firmly on the CF card). My guess is that there are slight misalignments between pins of the controller's CF card slot and the contacts on the CF card -- this would explain why I have only seen these problems with an older controller and with frequently used cards (repeated insertion moved the pins a bit). It is true that the $8 CF card reader you probably own never freezes - this could be due to a better connector, but is probably just better software. An improvement to address this problem would be to add another layer of error checking in the CF reading code (would repeat a read from the card when something fails). I have not pursued this yet, because 1) the fix is easy (get a new card), and 2) bugs that appear once in a blue moon are just not the easiest ones to investigate and repair (and verify).

Does anyone else have some thoughts on this?

MR




Mark Frye wrote:

Hi All,
We get system crashes (freeze-ups). Not all that frequently, but when it happens in the middle of an 8 minute experiment, right near the end, and causes us to have to scrap the trial to reboot, it's a bummer.


Any ideas?

-Mark





Other related posts: