This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hello,
we use the method descriped in the following document the generate a system tick for our OS: https://www.ti.com/lit/fs/spna123/spna123.pdf
In this example (and also in our implementation) we reset the interrupt pending bit INT3 (because we use the compare 3 for this) in the RTI Interrupt Flag Register (RTIINTFLAG) by software.
I want to change it in that way, that this interrupt pending bit will be reset automatically. For this I
- defined the counter-value CMP3CLR in the RTI Compare 3 Clear Register (RTICOMP3CLR) and
- activated the auto-reset by writing 0xA in the INTCLRENABLE3-bits of the the RTI Compare Interrupt Clear Enable Register (RTIINTCLRENABLE),
but it's not working.
On the other hand we also use conversion with the internal ADC, triggered cyclic by the compare 0 of the RTI by using the auto-reset feature. There it works.
Is there a limitation with the RTI auto-reset feature? Or do I something wrong?
I'm asking my, why the example in spna123.pdf will not use the auto-reset feature?
Thanks for help.
Hi Jens,
Apologies for the delay in my late response. I was stuck with other issues in this mean time.
I don't understand what is mean by automatic reset of interrupt flag.
The interrupt flag will be set after the each compare match, for example if i set interrupt for 1ms then for every 1ms interrupt flag will get set and we should need to verify this flag and should need to take the action. And after or before the action we should clear the interrupt flag to identify the next interrupt flag.
I don't understand why you would like to clear this interrupt flag automatically. No one will do that.
If you verify HALCoGen generated code for interrupt, you can see the first step in the driver handler code is to clear the interrupt flag and then calling the notification function.
In the notification function we can take the necessary action by the user.
If you don't want RTI interrupt at all then you can use polling method also, that is manual way of verifying the flag.
I am attaching two codes here; one is polling method and other one is interrupting method.
Please review both.
3386.RTI_Interrupt_Generation_For_50ms_LC4357.zip
--
Thanks & Regards,
Jagadish.
Hello Jagadish,
if you need some more details about the initialization steps/values, please let me know.
Best regards,
Jens
Hello Jagadish,
thank you for helping me.
first: please ignore my previous answer regarding more details about the initialization steps/values. I didn't saw your answer because my browser has not refreshed this page.
now, to your answer:
> I don't understand what is mean by automatic reset of interrupt flag.
What I mean is the use of the RTICOMPxCLR register (x = 0..3).
> I don't understand why you would like to clear this interrupt flag automatically.
Because of the desription of the RTI Compare Interrupt Clear Enable Register (RTIINTCLRENABLE)...
Source: Technical Reference Manual, SPNU563A, March 2018, chapter 17.3.35
... I think, it's a nice feature, when there is no need to clear the INT-Flag manually.
And for me, the use of the "auto-clear" feature would fit my needs.
> No one will do that.
Isn't it a good idea to use the offered features of this MCU?
But back to my problem...
I use the compare 3 for the system-tick (1 ms).
After configuring compare 3 the free running counter 0 was started.
Then the compare 0 was configured to trigger an internal ADC cyclic (2 ms). For this, it uses also the free running counter 0.
For the compare 0 the auto-clear was working, for compare 3 not.
What could be the reason for the non working auto-clear of compare 3 INT-flag?
Hi Jens,
Isn't it a good idea to use the offered features of this MCU?
My apologies!
I never saw or used before this Auto-Clear feature in RTI, that is the reason i am asking that.
Now come to the question:
After carefully reading this, i understood that this auto-clear feature is not for the interrupts it is only helpful while we configure RTI trigger to the DMA or other peripherals.
If we enable this auto-clear feature in the case of RTI interrupt generation, what happen is that the RTI flag will get clear before the interrupt generation itself. So, that means we no longer can able to go to the handler routines (rtiCompare0Interrupt or rtiCompare3Interrupt etc).
However, in the case of RTI trigger generations to DMA or other peripherals, in this case we don't need to run any code from handlers. We just want that RTI trigger should need to be route to the corresponding DMA or peripherals, so in this case this auto-clear feature will helpful.
I also verified this in practical, and i am right about the above behavior.
--
Thanks & regards,
Jagadish.
Hello Jagadish,
> After carefully reading this, i understood that this auto-clear feature is not for the interrupts it is only helpful while we configure RTI trigger to the DMA or other peripherals.
I'm afraid that you read this more carefully than me! :-)
> If we enable this auto-clear feature in the case of RTI interrupt generation, what happen is that the RTI flag will get clear before the interrupt generation itself. So, that means we no longer can able to go to the handler routines (rtiCompare0Interrupt or rtiCompare3Interrupt etc).
I'm wondering why this RTI-flag will be cleared before the interrupt was generated if the clear-counter-value is half between the compare-counter-update value.
The initial values before starting the free running counter at 0 are:
RTICOMP3 = 1000
RTIUDCP3 = 1000
CMP3CLR = 1500
(1000 are 1000 µs = 1 ms in our system)
But anyway... you have tested and confirmed that auto-clear is not working with compare-interrupts.
Thanks for helping!!!
Kind regards,
Jens