next topic »

[Reply #30 on:]

Nick,

Try different values. In particular, extreme ones (eg. 0, 1023 or close to that)

On the board running the program the values do go from 0 to 1023 and anything in between.
 
When the PID is not putting out any output, it is zero and that is what is fed into the function Timer3.setPwmDuty(..).
Then when the PID is wanting maximum output, that is 1023, that is what is fed into that same function.

So, the value going into the function every 100mSec is more or less constantly on the move.
The problem is not to do with the value I provide to the function I am certain, more that Timer Control Register 3A (TCCR3A) becomes cleared to zero at some point in time.

Paul

[Reply #31 on:]

Now, every 100mSec I make a call to a TimerThree function, the PWM function, and this is where TCCR3A is able to be changed, as follows;

Well why do you call that every 100 mS? You don't need to change the period, do you? Only the duty cycle.

[Reply #32 on:]

The thing is, it is hard to debug from snippets. Stuff you don't think is relevant might actually be the problem. Just as an example the Servo library clears TCCR3A.

I feel confident that the hardware registers don't just clear themselves for no reason. Something in your code, or in a library, is doing it. Possibly due to a buffer overrun somewhere.

[Reply #33 on:]

Nick

Well why do you call that every 100 mS? You don't need to change the period, do you? Only the duty cycle.

I call the Timer3.setPwmDuty(..) every 100mSec because I need to give a new duty value to the function as provided from the PID output.
I am not changing the value of the Timer3 pwm period at all.

I hope you're not getting confused by the fact that I have the Timer3 period set to 100mSec as well as my function call to set the duty being called every 100mSec.

In the test program, you can see that I initialise the Timer3 with a 100mSec period.
Then quite apart from this, I have a call to the process100ms routine being called every 100mSec.

The two are totally separate timings.

Paul

[Reply #34 on:]

Does this code have interrupts? For something that goes wrong very occasionally it sounds like a timing issue.

[Reply #35 on:]

Nick

Something in your code, or in a library, is doing it. Possibly due to a buffer overrun somewhere

Check post #22, where I check for all references of TCCR3A in the complete project, only found in the Timer3 library.
All my dealings with Timer3 are via those very functions as in the test program, nothing else.

Does this code have interrupts?

No interrupts anymore, as I mentioned in reply post #20

Firstly, I have removed the TimerThree generated 100mSec interrupt used to call a routine.
That interrupt has been replaced with a standard 100mSec millis() time check, which works fine.

Which is what we have in the test, it is from my actual program.

For something that goes wrong very occasionally it sounds like a timing issue

Well, yes, timing of sorts I guess, being that it takes a while for the problem to manifest itself.

I am feeling somewhat stuck and a little embarrassed as I think I should be able to sort this out.
But it is proving to be a curly one.

Paul

[Reply #36 on:]

OK, let me ask you this. If I changed that test code to randomly generate a number in the range 0 to 1023 (or you do it), and then let it run for a couple of days, is your theory that the PWM output will eventually stop?

[Reply #37 on:]

is your theory that the PWM output will eventually stop?

Not so much my theory, but my experience, yes.
It sounds so totally strange, I see no reason whatsoever that it should stop, but stop it does.

Maybe put some extra serial debugs in the test code, such as what I have and I hope you have seen on my web page.
Particularly TCCR3A, that is the one that is getting changed, bit 5 from being set to being cleared.

I will do some tests on hard coding  the value and writing on the Timer3.pwm(..) function just as it does in Timer3.setPwmDuty(..) function to find out what happens.

I do appreciate your help Nick, and Rob too.

Paul

[Reply #38 on:]

I'm trying to get my Mega running so I can try the code, can't get past the dreaded "sync" error.

In an attempt to at least fix the symptoms, how about running a watchdog task that checks the TCCR3A value and changes it to 32 if 0. For that matter just write 32 every time but record that the value was wrong.

Such a weird thing smells of memory leaks or an overflow somewhere. Bloody hard to find normally.

_____
Rob

[Reply #39 on:]

Hi Rob,

can't get past the dreaded "sync" error.

I'm recalling that is the error you sometimes get from the Arduino IDE when you you try to upload?
It's been awhile since I used it last, so I am unsure what might be the problem there for you on that one, sorry.
Hopefully you have been able to upload now?

For that matter just write 32 every time but record that the value was wrong.

Yes, I think I will for a test, just set bit 5 of TCCR3A in the function I call every 100mSec after checking if it was still set.
If it was not set, I will raise a flag and look at ways to used that to check what caused it to be cleared.

smells of memory leaks

Yes, a stinky foulish pukey leak, it could be.

I will make the change shortly and let it run overnight and see what happens by morning.

Paul