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.

RTI COMP0CLR

Other Parts Discussed in Thread: HALCOGEN

Hi,

I'm implementing a simple function with 16 channel ADC triggered by RTI.

Inside HalCoGen I've enabled RTI (comp0 every 1s), ADC1 and ADC interrupt.

My app should simply acquire 16 pins every RTI comp0 (1Hz) and after this call an interrupt funtion to retrive the values.

Mi main contains this setup:

    adcInit();
    adcREG1->GxINTENA[0] |= 1U<<3;
    adcStartConversion(adcREG1,0);
 
    rtiInit();
    rtiREG1-> SETINTENA = (0x01U << 0);
    rtiREG1->INTCLRENABLE &= 0xfffffff0;
    rtiREG1->COMP0CLR = 5000U;  // TODO: verify why the value doesn't care
    rtiStartCounter(rtiCOUNTER_BLOCK0);

the RTI->COMP0CLR instruction is required (if I commented it out the ADC IRQ is never called) but the assigned value seems not used. With this setup my intrrupt function is called every 1s even if I change the RTI->COMP0CLR value.

Why?

Thank you

  • Thanks for using the Hercules forum! An engineer has been notified of your question.

  • Matteo,

    I don't know the history of why this feature was added to the RTI, but there are two ways to clear the interrupt request.  The first is by the CPU writing to the interrupt flag register,  a '1' in the bit positions that you want to clear.

    The second method is more elaborate, there is a second compare register which is used to clear the interrupt request.

    This has the same structure as the compare that 'sets' the flag, except this compare register is used to clear the flag.

    If you wanted the interrupt pulse to be 3 rti clock cycles long and repeat periodically every 5000 cycles you could do something like initialize the compare set to 1000 and compare clear to 1002 (3 counts apart) and set the update compare registers to the same value (5000).   The request would go on at 1000, off at 1002, and on again at 6000, off at 6002, etc.

    For sending an interrupt to the CPU then you probably shoudl not use this mode because the CPU interrupt controller is level sensitive, and if you clear the request automatically then it may not be there by the time the  CPU gets to service the VIM.  In that case you would get the phantom interrupt vector -- (interrupt that came but disappeared on it's own before the CPU could find out which it was..)    

    But if you're sending a signal to another peripehral like the ADC then it may be that if the signal isn't long enough that peripheral won't see it.  This would be the case if the peripheral were using a slow clock to sample the RTI interrupt reqeust. I don't know off hand if this is required for the ADC but it might be if the ADC uses its ~30MHz clock to sample the RTI trigger.

    Curious - did you find this example somewhere?

     

  • I've build the code by myself, trying different possibilities.

    Currently the RTI is used to trigger the ADC every 1000ms. Based on your explanation, and because my RTI clock is set at 50MHz) probably I don't see any difference changing the COMP0CLR untils it's value is a magnitude less then the compare value (actually 50M). The right values should be something like CMP=49000000 COMP0CLR=500000, right?


    I have another code where RTI is used to trigger DMA and in this case the continuous trigger works without setting the COMPCLR. Why?

  • Matteo,

    I think your assessment of what's going on is correct, although I don't you should use the RTICOMPCLR.

    The TMS570 interrupt controller (VIM) expects level sensitive requests.  So creating an artificial pulse interrupt by using the RTICOMPCLR feature is probably a bad idea.   Instead I recommend servicing the RTI via the RTIINTFLAG register as would be typical of other peripherals.   I suspect your other code does this and that's why it works.

    I'm trying to find out if we have a use case for COMPCLR registers,  but I suspect we do not on the TMS570 and that this feature was added for IP reuse on another TI design.  If that's the case we'll probably 'undocument' the feature to avoid confusion.   If there is a use case on TMS570 though -- I don't see VIM as being it - it would be something related to perpheral cross triggering instead.

     

  • Thank you Antony,

    I'm going to try the setup you suggest and let you know.