How do I know if I'm overloading the RC program?

[Eldarion]

Originally Posted by PhilBot

1) What causes the Program State light to flash? Is it detecting that my code is not doing something in particular (like servicing the shared memory)?

I have run into a similar situation with the RC. Try commenting out ALL of your printfs and see if you get the red light of death. Also, the processor hates the use of long data types (don't ask me why, but replacing all longs with ints magically made a program of ours work). I think that under certain circumstances the user code can corrupt the I2C datastream that links the user and master processor, confusing the master. It would probably be helpful to have the IFI I2C link's source code to figure out what is happening, but I don't think there is any way to obtain that!

As a side note, did you try protecting GPR14 (the old 8.2V bug fix)?

[Qbranch]

When you say you used all 6 interrupts, did you put encoders on all six of these pins? Make sure you watch your interrupt rates...

If you're questioning how long it takes a routine to run you can always set a pin in the beginning then clear it at the end, just use a scope to time it. Or, if you want to see how often your procesor is idle, just toggle a pin in process_data_from_local_IO() and watch how much time you get a constant frequency compared to how long you have constant up/down states (this would mean your doing something else, not toggling your pin).

I had an issue with encoders having too high an interrupt rate myself, so we switched to a different encoding technology. Remember the ISR that the compiler puts in also takes time, can't quite remember how long.

Remember that floating point operations use the same two registers, so if you interrupt a floating point operation and start doing one in the interrupt, you'll get junk data when you return from the interrupt. Stack overflows on rare occasion will not cause the processor to crash, however usually this will cause the 'code error' light to flash.

If you need anything I havent listed here just give me a pm/email.

-q

[PhilBot]

Thaks for the good insights... (I'll have to track down that "protecting GPR14" fix... we do/did have the 8.2 bug).

I found part of my real bug. It was a very nastie case of code reentrancy gone wild. It wasn't planned reentrancy, but a certain state transition was causing A to call B who called A who called B etc.... until all memory was used up. Not very smart.

Now that's fixed I can continue to look for the odd behavior bug.

Phil.

[PhilBot]

Originally Posted by Eldarion

As a side note, did you try protecting GPR14 (the old 8.2V bug fix)?

Oh Boy, that was a great tip. It took me a while to find the reference but I did... Here is the link to the actual file.

http://www.chiefdelphi.com/forums/sh...3&postcount=96

I have disovered that I am using the V2.0 version of Kevin's camera code, which does not have the GPR14 protected. I see that V2.1 does have it protected. That will teach me to be afraid of the "Latest version" of code.

This explains a LOT of the strange behaviour that I was seeing (inputs on the wrong channels etc)

Maybe I'll get some sleep now

[dcbrown]

Also be aware that the hardware call (PC address) stack is limited. The 256 bytes of allocate stack space in ram/bank memory is for allocation of automatic variables at function call time.

"After the PC is pushed onto the stack 31 times (without popping any values off the stack), the STKFUL bit is set. The STKFUL bit is cleared by software or by a POR (Power-On-Reset)." [PIC Spec]

Typically the processor will reset when the STKFUL bit is set, but the behavior depends on the state of the STVREN (Stack Overflow Reset Enable) configuration bit. This should be enabled to allow the resets in FIRST environments. Runaway re-entrant functions will cause bad behavior including resets as a result of stack overflow. Moreover, out of the stack depth must be reserved call space for low and high interrupts. If the chip isn't being reset because STVREN is clear, then you should be able to check the STKFUL bit in the STKPTR hardware register as the bits will remain on until POR condition or software resets them.

The high priority interrupt is a two deep stack on the slave processor:
     . (1) InterruptHandlerHigh
         . (2) Prep_SPI_4_First_Byte
         . (2) Handle_Spi_Int

The low priority interrupt is at least another 4 stack levels in the MPLAB default environment:
     . (1) InterruptHandlerLow
         . (2) CheckUartInts
              . (3) Handle_Panel_Data
              . (3) Process_TX
                   . (4) DisableXmitInts
              . (3) Serial_Char_Callback

So at LEAST 6 stack frames must be reserved for interrupts, maybe more.

Bud