??? 10/29/04 10:10 Read: times |
#79991 - RE: Prog.CounterArray irq problem Responding to: ???'s previous message |
hi,
it is still hardly to understand you but I`ll try. I.e. in unkown (for me) situation CH/CL == CCAP0H but ISR doesn't execute... There are two questions of matter: 1. Is match has been detected really? By other words - when CH,CL == CCAP0, then is CCF0 bit set to 1? If match is not detected then it means that bit MATn was not set. Reasons of it: 1a. You configured PCA module wrong. For example, it is in Capture Mode while it must be in Compare Mode. 1b. You wrote to register CCAPnL but did not do to CCAPnH. You know, when MATn is set and software writes to CCAPnL then MATn bit is reseted. To set it back you should write to CCAPnH. 2. Match has been detected and bit CCF0 is set but ISR is not executed anyway. It means that PCA interrupt is blocked. There are some reasons for it: 2a. Global interrupt disable (EA=0); 2b. PCA interrupt disable (EC=0); 2c. PCA module interrupt disable (ECCFn=0); 2d. the ISR has the same or lower priority level than current executed ISR. (For example, when match is detected inside PCA ISR then new ISR will not be executed until program leaves current ISR). Reading your post once again I see that your problem is related to what Peter said somehow. For example, - you configured PCA module 0 to Compare Mode with CCAP0=0x0100. - you enable the interrupt (ECCF0=1, EC=1, EA=1) and start PCA timer. - at match (CH,CL=0x0100) the ISR is executed. - you increase CCAP0 with, let say, 0x0050 and so the new compare value loaded into CCAP0 is 0x0150. - during ISR, PCA timer (CH,CL) is not stopped, it still runs! It may happen that it counted upto 0x0200 before you setup new value into CCAP0. Take in consideration that it may occur not only because your code is huge and slow but because an interrupt with highter priority may take program execution time as well. - so let say, CH,CL is 0x0200 when you load 0x0150 into CCAP0. Then you leave ISR. Now, match control is enabled and PCA timer counts up. But its value is already above compare one! So it counts upto 0xFFFF then to 0x0000... And only when it comes to 0x0150 then new ISR is executed. Regards, Oleg |
Topic | Author | Date |
Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem | 01/01/70 00:00 | |
RE: Prog.CounterArray irq problem![]() | 01/01/70 00:00 |