Ok, good thoughts Nick and Rob,
What you say Nick is perfectly true,and my brain tends to think that way when in diagnostic mode.
My preference is to debug the real system as from my experience finding tricky problems on half baked systems designed to trap the error usually does not trap the error.
What I have done is to bring some of the values of Timer3, specifically function "setPwmDuty(char pin, int duty)" to be viewable on the web.
The debug code now looks like this;
void TimerThree::setPwmDuty(char pin, int duty)
{
unsigned long dutyCycle = pwmPeriod;
dutyCycle *= duty;
dutyCycle >>= 10;
dutyCycleDebug = dutyCycle; // XXX test
if(pin == 5) OCR3A = dutyCycle;
if(pin == 2) OCR3B = dutyCycle;
if(pin == 3) OCR3C = dutyCycle;
OCR3BDebug = OCR3B; // XXX test
}
T3 PWM Period should stay as a constant at 12500.
The value for T3 Duty Cycle should always equate tothe same value of T3 OCR3B, if not then we have a problem.
Also, I took on your suggestion Nick and modified those values you mentioned in post #4 and right away I noticed no PWM and the PID max'd out at 1023 trying to bring down the battery volts back to setpoint.
Then restoring the back to original and it works again, the PID settles back as the PWM does its thing
So, seemingly no go there. I am reading the datasheet on OCR3 but it is a bit to wade through,especially at 01h15.
At least I can now see the actual OCR3B register value in next to real-time on the web so I can keep an eye on it if it decides to fall over.
Paul