Delayed Red Light of Death

Ok, so we had a snow day today, and luckily I brought home the electronics board and such, and was able to program. I had been going at it, and had everything I had done so far working. I left the board on while I coded another section. After a few minutes (5-15?) I hear the click of relays reverting to neutral, and sure enough the lights are orange again. I look at the board, and the red light of death is blinking at me, despite the fact I touched none of the controls, and had no counters or anything that would have made any program flow changes. Any ideas?

I really have no idea… You may want to leave the board on again for a length of time to see if you can replicate the error. If nothing happens, then you’re all set, and don’t have to worry about it. Or I believe dashboad will allow you to get more descriptive code error reports. (Not sure about that, though. Something does.)

When I run our code without the sonar unit attached, it runs for about ten seconds and hangs (red lights). Then I disable the sonar code and it runs fine.

So if you can repeat the problem reliably, try disabling sections of code to see if any particular section is making it hang.

You can get the red light of death if there is a branch of your code that takes too long to execute. You can also get it if you are stomping on memory (for example if you keep writing past the end of an array). You can also get it if you generate too many interrupts, take too long to process them, or forget to clear them. If you have too many printfs (writing to the serial port is slow) you can also cause one.

There’s probably a lot of other things that can cause it, but those are things to look at.

One last thing to do is check the battery voltage on the OI display before and after the red light of death. There is one (supposedly fixed) bug that causes the battery voltage to display 8.2 or 8.3.

1075 has also experienced a RLOD if you have the motor outputs of a victor shorted (by accident) and activate some code that should run that victor.

Another possible cause.

Running interrupts? If the proper context isn’t saved then it will run almost all the time without a problem until the particular context that isn’t saved happens to be in use in user code when an interrupt happens. The longer the code runs, the more chances you’ll finally hit the timing needed to make this happen.

For example, PCLAT isn’t saved but a computed function call is executed in the interrupt routine which uses the PCLAT AND the interrupt happened to catch the user code doing the same thing and it was partially through loading the registers (for example PCLATH loaded but not PCLAT)… upon returning the user code finishes the computed call and vectors off in some random program memory because the data in PCLAT is left over from the interrupt routine and not what the user code had loaded.

Similar issues can exist with any of the other compiler managed resources.

The easiest way to test this is to load up the save= list will ALL compiler managed resources and see if the code can run longer idling without RLOD.

save=PROD,TBLPTR,TABLAT, PCLATH,PCLATU,section(".tmpdata"),section("MATH_DATA")

I think that covers them all.

That should cause a voltage drop (brown-out) processor reset. The victor is trying to tie the battery + and - together through a low resistance connection. ouch. Did you lose the victor?

I’ve seen this happen to a team that was pushing the limit on fitting their processing within the duration of the 26ms of the slow loop.

They were dropping every other radio packet which wasn’t quite enough to fail, but eventually if they ran for a long enough period of time they finally dropped several packets in a row triggering the RLOD.

If it’s that it’s pretty obvious if you time the duration of your loop.

We got an error very similar to yours by misusing the serial drivers. You sure nothing like that is happening?

Nope, didn’t lose the victor… I don’t even think we blew a breaker… it was weird.