Hi,
I’m currently working on an electronic board based on the P1010. I’m trying to use global timers on the P1010 but I have been unable to get A0 and B0 global timers working. Indeed, timer interruptions don't cause external interrupts.
You could find below more explanations about what I have done so far.
Concerning the initialization of the processor, I have set two main things :
After having got the timer configuration register reference (CCSRBAR address + 40000h + 1100h for A0 Global timer and CCSRBAR address + 40000h + 2100h for B0 Global timer), I have :
Before the initialization of the A0 Global timer :
After initialization :
At runtime :
The global timers seem to work since I can see the PIC_GTCCRA0 register values decrementing. Reading the P1010 QorIQ Integrated Processor Reference Manual, it mentions that the PIC_GTCCRA0[TOG] is toggled when the current count decrements to zero and cleared when PIC_GTBCRA0[CI] goes from 1 to 0. However, the CI bit is always set to 1 and doesn’t change at all.
Looking at the PIC_GTVPRA0 register, I have noticed that the Activity bit is always set to 1 and interrupt request from the PIC should cause the processor to take an external interrupt, right ?
Is there any additional register/step needed to setup and use global timers? Anyone can explain me in details how they work?
Thanks,
Solved! Go to Solution.
I'm assuming you have IVPR/IVOR4 pointing at code to handle the interrupt, and that code isn't executing. You said the activity bit is "always" set -- this is from the instant you unmask it? Did you write to any of the timer registers (besides vector/priority and destination) between resetting the MPIC and unmasking the timer interrupt? Was the MPIC used at all before reset?
It looks like you're reading IACK before you put the MPIC into mixed mode, which is bad -- I'm not sure what effect that would have.
Hello HARRY JUCQUOIS,
Do you have valid interrupt routine to service this request?
As you wrote the "Activity" bit is always set, it seems there is interrupt pending on the same source, so the later ones are lost. I guess the two possibilities, one is there is timer interrupt with priority 0 pending there, it may happens when you clear its mask bit and priority is not setting yet; and the second one, there are higher priority interrupts.
You may try below sequence:
1. Reset PIC;
2. Disable all external interrupt of MSE;
3 Set priority and vector of GTVPR (Leave mask bit set);
4. Clear CTPR;
5. Set GCR[M] to be mixed mode;
6. Loop with FRR[NIRQ] to clear all IACK and write EOI;
7. Enable interrupt by GTVPR[MSE];
6. Set CTPR to be required;
7. Enable counting of GTBCR;
8. Enable external interrupt of MSE;
Have a great day,
Lunmin
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
I'm assuming you have IVPR/IVOR4 pointing at code to handle the interrupt, and that code isn't executing. You said the activity bit is "always" set -- this is from the instant you unmask it? Did you write to any of the timer registers (besides vector/priority and destination) between resetting the MPIC and unmasking the timer interrupt? Was the MPIC used at all before reset?
It looks like you're reading IACK before you put the MPIC into mixed mode, which is bad -- I'm not sure what effect that would have.
First of all, thanks for your quick answer!
The IVPR/IVORX registers are indeed all pointing at code to handle the specific interrupts.
When I'm saying the activity bit is "always" set, I mean it only changes to 1 when counting is enabled by setting the PIC_GTBCRXX register.
If I just specify the interrupt priority and set the vector field of the PIC_GTVPRA0/B0 register, the activity bit remains the same and doesn't change at all.
As you mentioned previously, I'm reading IACK before putting the PIC into mixed mode. As a consequence, I have tried to do the inverse and it seems to work properly. The timer interruptions cause external interrupts and call the corresponding handlers.