Cypress / First touch I/O module recognition by DS after suspend

[heydowns]

Originally Posted by Jeanne Boyarsky

So thanks for posting about the problem and saving us!

Thank you, too, for posting that it happened to you as well.

Can you share your configuration at the time to help NI track this down (see Greg's requests above)? Be very specific. What devices were plugged into what ports? If using the hub, describe what was plugged into it and if you were running it from the single USB connection or both USB connections on the "Y" cable.

[Greg McKaskle]

I wanted to give an update on the Cypress identification issues.

First, some diagnostics.
--------------------------
If the board doesn't have power, no LEDs are on -- fix the cable.

If the board has one green LED, press the button on it. If no red LEDs turn on, your board is fine and working.

If one red LED, in position 2 I think, comes on, the board has not been recognized by the computer and reenumerated.

For testing, we placed a small clamp on the button and repeatedly cycled through different startup procedures.

If the Cypress is plugged into an external hub, it will fail to enumerate about half the time -- red light still on. Usually, moving the Cypress to be plugged directly into the Classmate immediately fixed the problem -- red light goes off -- with no need for reboot or DS restart.

*** The 2010FRCControl%20System-Getting%20Started-Rev-0.7.pdf is a bit weak in its directions. The intent was to have the I/O board plugged directly into a computer port due to power limitations. It will be updated to state this more strongly.

If the Cypress is plugged directly into the Classmate port, the I/O board would occasionally fail to be recognized on a cold boot -- approximately 1 in 8 would fail. When this failed, the CyMiniProg Service was always running, but restarting it always fixed the issue. Since there is no automated way to restart the service -- yet -- it may be easier to reboot when this occurs. We are still investigating this issue, and it may be timing related. This is not directly caused by the FMS field connection, but since the presence of an FMS could change timing, it could make the failure more or less likely to occur.

If the Cypress is plugged directly into the Classmate and in a recognized state, we saw no failures when suspended and reawakened.

To test/identify a joystick, press a button and watch for the LED to turn blue on either the Setup or Diagnostics tab.

My recommendations.
-------------------------
For teams using the I/O board, test it before each use by pressing the onboard button, especially after a cold boot.
1 Red LED = BAD
0 LEDs = GOOD

Do not plug it into an external hub even if using special pigtails that let the hub draw more current. Plug it directly into a Classmate port.

Test joysticks before each match. I have never seen failures except in over-current conditions, oh -- and then there is the cable not connected condition, but think like a pilot. Run through your checklist.

When not in use, suspend the Classmate by closing the lid. Briefly press the power button to wake it up. If the Classmate has slept for more than six hours, it may take thirty seconds to restore from disk, but for shorter sleeps it should resume from memory and take six seconds. I know of no issues with network recovery.

If I notice additional issues at the event I'm attending this weekend, I'll update this thread. Feel free to offer your own advice, but please explain why you believe it is good advice.

Greg McKaskle

[heydowns]

Greg - was able to do some additional testing here on Tuesday, but wasn't able to post until now. Glad to see you guys were able to reproduce the issues in some respects. My findings below in context of yours.

Originally Posted by Greg McKaskle

If the Cypress is plugged into an external hub, it will fail to enumerate about half the time -- red light still on. Usually, moving the Cypress to be plugged directly into the Classmate immediately fixed the problem -- red light goes off -- with no need for reboot or DS restart.

This is in line with our observations as well, more or less.

If the Cypress is plugged directly into the Classmate port, the I/O board would occasionally fail to be recognized on a cold boot -- approximately 1 in 8 would fail.
When this failed, the CyMiniProg Service was always running, but restarting it always fixed the issue.

While we were unable to run a significantly large number of tests due to time constraints, I can report that moving the device to being directly plugged in also has greatly increased success rate here - we didn't have any failures in the handful of cold boots that we did.

If the Cypress is plugged directly into the Classmate and in a recognized state, we saw no failures when suspended and reawakened.

To further this... we did a lot of mixed testing of suspend (as this is the primary use case of concern for us). That is, we did not cold boot when changing the configuration. Simply moved where the device was plugged in, waited for it to be recognize, and then started doing suspend/wake tests.
When directly plugged into the left-side classmate port we didn't see any failures suspending/awakening. When plugged into the hub, we saw intermittent failures.

We've since modified our physical enclosure to permit direct connection.

Unfortunately I was unable to gather any data on behavior with no loads connected to the Cypress because unhooking all the devices would've taken more time than we had to test.

[Jeanne Boyarsky]

Originally Posted by heydowns

Thank you, too, for posting that it happened to you as well.

Can you share your configuration at the time to help NI track this down (see Greg's requests above)? Be very specific. What devices were plugged into what ports? If using the hub, describe what was plugged into it and if you were running it from the single USB connection or both USB connections on the "Y" cable.

I don't remember specifically. Conceptually, we had three joysticks and the First Touch. I know that's not detailed enough to be useful.

I'm guessing the hub and all are in a crate traveling to our next match. I'll check with the team though and see if anyone remembers more specifically.

[Emily M.]

Originally Posted by Jeanne Boyarsky

I'll check with the team though and see if anyone remembers more specifically.

We had three joysticks plugged into the USB hub, which was only connected with the black USB cable. We sometimes plugged the Cypress into the hub, and sometimes into a separate port - I don't remember where it was when the Classmate was put to sleep, but afterward the Cypress was not recognized in any port.

We've had occasional problems with the Cypress in the past. Sometimes we'll be running the bot, and all the buttons connected through the Cypress will work fine, and then we suddenly get a single "enhancedIO not found" exception. However, the buttons continue to work properly. I suppose this could be a momentary power issue if the Cypress was connected through the hub, especially since the Cypress has to power several LEDs.

I hope some of this information can be helpful in the debugging process! Just to be safe, we mounted a little piece of plastic on our board to prevent the Classmate's lid from closing

[eugenebrooks]

We had the Cypress I/O module plugged in to the left side USB port
directly on the classmate and had it go off line when the classmate
lid was closed on the way to a match at SVR. Rebooting solved the
problem after we ran the match with joysticks only.

Our solution was to put two "DO NOT CLOSE LID" signs on the lid
to get us through the rest of SVR. We will likely put mechanical
closure stops on the corners of the keyboard so that this can not
happen again.

We will have to start testing with a tether after every cold boot,
although we have not had a cold boot where the cypress card
did not come up properly.

Eugene

[Mark McLeod]

Just an update after the SBPLI Regional.

Four teams had the issue with the Cypress board not being recognized after the Classmate went to sleep.
Restarting the service worked for all of them.