Unknown Blinky-light type Errors.

I have been having problems with my code for a while. I perpetually get some kind of program-state error (either the green-orange or just a time out), and I don’t know why.

I had it going for a little while, but PID would only drive the wheels at 254 (nothing real PID about it). But then I changed the code and the problems came back.

Currently, I have the time-out error. It happens before the initialization message is printed. (Meaning all I see in the terminal is “IFI>”, no “IFI 2005 User Processor Initialized …”). It happens a second or two after a reset (it’s green for a few seconds, then goes red). The green-orange (OGLOD?) happens immediately.

I have absolutely no idea where this is coming from. I have both the Navigation code and the Camera code (though the camera code is disabled at the moment).

Can anyone help me as to where I should look? I have no idea whatsoever as to what is the cause. I can post whatever code you want.

I have had the same errors for a few days as well. I did notice that if I turned the OI off, the blinky lights would go away after reset, and would come back on after reset if OI was on.

Also, I noticed http://www.chiefdelphi.com/forums/showthread.php?threadid=34301. Did that fix it for you? (I will try to check all my printfs tomorrow).

Not entirely. Just took me from green-orange to a normal red/time-out.

I’d need to see the whole project to track a problem like this one down.
I’d also like to know what external sensors you have hooked up and the theoretical (or actual) interrupts per second you expect.

I was getting the same error for a while when I was trying to get interrupts working. I eventually abandoned that at about week 3 and just went with polling. Not sure what caused the problem… :frowning: It’ll probably end up being an after season project.

Currently, we have just the drive train and encoders hooked up. I’m using primarily the Navigation/camera code. The generated doxygen version can be found (hopefully) at http://endeavour.zapto.org/astro73/tgdocs/.

The ZIP version is at http://endeavour.zapto.org/astro73/tg_2005.zip. I couldn’t get it under 100 KB.

(see my other post for other half.)

The problem seems to be fixed by removing the double calls to OpenADC(). Check gyro.c and ifi_utilities.c for the implementation.

So you found and solved the problem.
That’s good news!

You’re using gyro code that is two revisions behind. I would dump that code and use the latest. BTW, what was the problem (I’m having trouble keeping track of the various CD and e-mail discussions I’ve got going)? Was it something knuckleheaded I was doing?

-Kevin

I had a similar problem. The code would work fine after a download, but would cause a fault shortly after a reset.

I my case it was due to commenting out the serial initialization but not removing code from the interupt handler that looked at these pins. I suspect the state of the serial pins can float during an FRC reset, then the interupt handler attempts to go somewhere it can’t. Either way, including the serial initialization cleared the problem.

Jeff

Sorry, I didn’t make either post very clear.

In the old version of the gyro code, the initialize function would call OpenADC() but not CloseADC(), leaving the A/D converter open. If you wanted to get an analog value by calling IFI’s function, it would also call OpenADC(), which is probably bad, and CloseADC(), also bad. The interupt that handled the gyro doesn’t call anything other than to get the value. The only way this would work is if Microchip’s code kept track of nested Opening/closing of the ADC.

The way I solved this is that I put Set_Analog_Channels() in an Initialize_Analog_Channels() (or similar) call, which would call OpenADC(). Then I changed Get_Analog_Value() so it set the analog channel without opening/closing. I also changed the Gyro interupt so that it would switch channels as well.

I haven’t checked this yet for the new code, I’m in the process of merging them. And a few of the function names are probably wrong.