![]() |
Second clock/timer causes red light of death
I'm working with Kevin Watson's 2008 codebase.
I've been fiddling with a clock (based on IFI's whitepaper on the subject) for far too much time I care to remember. I waded through many mistakes on my part along the way (as I am a relative neophyte in programming) but I'm finally stumped. Here's my relevant code: Code:
/*******************************************************************************Code:
// if Brian has stopped being an idiot (unlikely) this will move us for 5 secondsCode:
extern timerSecondCount;My code has been compiling fine (after much trial and tribulation :P ), but as indicated in the topic subject, it results in a red program state light. When I disable the timer 1 overflow interrupt (PIE1bits.TMR1IE), the program state light is green (but as my count-incrementing code is within an ISR, doing so renders my code useless). Strangely, however, if I re-enable the interrupt but comment out the contents of the ISR function, I once again see red. Can anyone point me in the right direction? Thanks. |
Re: Second clock/timer causes red light of death
Are you actually calling your timer interrupt handler from the Interrupt_Handler_Low() in ifi_frc.c? Also, your timer interrupt handler isn't clearing the Timer 1 Interrupt Flag. You need this:
PIR1bits.TMR1IF = 0; in your interrupt handler to clear the interrupt, or you'll just end up right back in it. Also, also, if you're preloading TMR1L and TMR1H, then you need to preload them again in your interrupt handler, or they'll start counting again from 0 instead of your preloaded value. |
Re: Second clock/timer causes red light of death
Quote:
Edit: Your code looks very good. The counter variables need to be global though. My bet is that you just forgot to enable the timer 1 ISR in ifi_frc.h. -Kevin |
Re: Second clock/timer causes red light of death
A nit, but it could cause unpredictable program results - no red-light-of-death - but weird things on occasion.
The timerSecondCount is a multibyte variable. Reading it's value needs to be protected by disabling the timer interrupt enable to avoid issues. For example, code reads lower byte and its 0xFF - before the code can operate on the upper byte a timer interrupt happens and the upper byte gets changed. The user code then reads the upper byte and completes whatever operation its working on but now it believes the timer count is a lot larger than it really is. (For example code thinks the value is 0x1FF when it is 0x100). Code:
PIE1bits.TMR1IE = 0;You only need to do this for multibyte variables that are written to within the ISR routine AND which you access at non-interrupt level. |
Re: Second clock/timer causes red light of death
Thank you very much to everyone for your responses!
Quote:
My understanding is that after calling Initialize_Timer_1() within Initialize(), the ISR for timer 1 (if enabled) should be called every time timer 1 overflows (in this case, every 25ms). Am I missing something (or was it an issue of me miscommunicating by forgetting to mention that I initialized timer 1)? Quote:
Quote:
Quote:
Quote:
Quote:
Quote:
On a related note, how do I distinguish between a multibyte and a single-byte variable? I'm afraid I'm quite ignorant concerning this bit and byte business. Also, to anyone who might be able to answer, was using "volatile" in my variable declaration correct (purely out of curiosity)? Again, thank you very much to everyone who responded; I'll modify my code ASAP. All this is very frustrating, but I'm ecstatic at how much I've been learning! |
Re: Second clock/timer causes red light of death
I think volatile is correct in this context. It tells the compiler that it needs to read the memory every time it accesses a particular variable (not use a register cached value), since the variable may change outside of the compiler's ability to predict or controll. In this instance, the variable might be updated by your interrupt service routine.
|
| All times are GMT -5. The time now is 23:12. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi