• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 407 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

MCU-PLUS-SDK-AM263X: RTI interrupt configuration

Oleg Chaichenko
Prodigy 140 points
Part Number: MCU-PLUS-SDK-AM263X
Other Parts Discussed in Thread: SYSCONFIG

I use RTI for SOC ADC. And set up EOC ISR for reading value.

I noticed the EOC ISR starts earlier than the RTI callback.

In my expectation, it should be: RTIstarts -> RTI SOC ADC -> RTI cb -> EOC ISR

but in real case it is: RTIstarts -> RTI SOC ADC -> EOC ISR -> RTI cb 

1st question where I should I stop RTI timer?

When I configuring RTI timer it shows me 0 priority is highest, 15 is lowest. But in generated code, it performs via the HwiP_Params_init function, where initially setts it up to params->priority = (HwiP_MAX_PRIORITY-1); where HwiP_MAX_PRIORITY is 16.

2nd question is, is it a bug?

3rd question is, why it is forbidden to configure the isPulse field via syscfg ?

Regards!

  • 0
    TI__Guru*** 135355 points

    Hello Oleg,

    Oleg Chaichenko said:
    But in generated code, it performs via the HwiP_Params_init function, where initially setts it up to params->priority = (HwiP_MAX_PRIORITY-1); where HwiP_MAX_PRIORITY is 16.

    Correct, that is just initializing the structure for the HwiP_Params.

    Once the structure has been initialized with base values, the code is then updating what needs to be modified based on the SysConfig.

    Then the Timer is actually created via HwiP_construct.

    After the HwiP_construct, the priority should match what you have set in the SysConfig.

    Oleg Chaichenko said:

    In my expectation, it should be: RTIstarts -> RTI SOC ADC -> RTI cb -> EOC ISR

    but in real case it is: RTIstarts -> RTI SOC ADC -> EOC ISR -> RTI cb 

    1st question where I should I stop RTI timer?

    The second order is what I would typically expect. The EoC ISR should be triggered as soon as the conversion is over so unless you want your timer to trigger before the conversion ends, that would be the expected order.

    My follow-up question would be if you are using an RTI timer, why would you want to stop it and not keep it running continuously? And in addition, why would the timer firing after the ADC EOC be an issue for your use case?

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 140 points

    Hi Ralph!

    I think, you did not get my 2nd question. In sysconfig (see attached screenshot) there are hint "Interrupt priority 0 (highest) 15 (lowest)"

    But in HwiP_Params_init function it is use macros HwiP_MAX_PRIORITY (16), but in generated code, it does not set via `.priority = (HwiP_MAX_PRIORITY - $enteredValue)` it sets directly `.priority = ($enteredValue)`

    My question is, is it correct hint information "Interrupt priority 0 (highest) 15 (lowest)". From my perspective, the 16 is the highest priority

    Ralph Jacobi said:
    My follow-up question would be if you are using an RTI timer, why would you want to stop it

    Right now it is a requirement. It should work for a limited time, then it could switch to another SOC or stop working.

    Ralph Jacobi said:
    why would the timer firing after the ADC EOC be an issue for your use case?

    I am figuring out is it possible the race condition in this logic.

    Regards!

  • 0 in reply to Oleg Chaichenko
    TI__Guru*** 135355 points

    Hello Oleg,

    Oleg Chaichenko said:

    I think, you did not get my 2nd question. In sysconfig (see attached screenshot) there are hint "Interrupt priority 0 (highest) 15 (lowest)"

    But in HwiP_Params_init function it is use macros HwiP_MAX_PRIORITY (16), but in generated code, it does not set via `.priority = (HwiP_MAX_PRIORITY - $enteredValue)` it sets directly `.priority = ($enteredValue)`

    My question is, is it correct hint information "Interrupt priority 0 (highest) 15 (lowest)". From my perspective, the 16 is the highest priority

    Okay I can understand the confusion here and while I do get what our software team is going for, you aren't wrong to make the assumption that you did.

    In this case, "Max" does not equate to "Highest". Rather "Max" equates to the highest numerical value allowed. The reason for this is likely due to also supporting FreeRTOS which defines the priority count via configMAX_PRIORITIES.

    So the code is just configuring the configuring the initial priority to be at the maximum allowed value which is the lowest priority. If the code configured "HwiP_HIGHEST_PRIORITY" I would 100% agree that is a bug.

    Again, I can fully understand where your conclusion came from and it's justified given that is not necessarily intuitive, but hopefully now you understand the reasoning behind the nomenclature used for that variable.

    Oleg Chaichenko said:
    Ralph Jacobi said:
    My follow-up question would be if you are using an RTI timer, why would you want to stop it

    Right now it is a requirement. It should work for a limited time, then it could switch to another SOC or stop working.

    Ralph Jacobi said:
    why would the timer firing after the ADC EOC be an issue for your use case?

    I am figuring out is it possible the race condition in this logic.

    So do you want effectively a one-shot timer which is why you are asking about the pulse functionality?

    As far as switching to another SoC goes, that needs to be part of your ADC configuration. You can trigger a sequence of conversions from a single trigger which is strongly recommended as the ADC is designed for that exact use case. We have multiple_soc examples provided in the SDK to illustrate how to achieve this.

    Best Regards,

    Ralph Jacobi

  • 0 in reply to Ralph Jacobi
    Prodigy 140 points

    Hi Ralph!

    Ralph Jacobi said:

    So do you want effectively a one-shot timer which is why you are asking about the pulse functionality?

    It is not one shot.

    Oleg Chaichenko said:

    Right now it is a requirement. It should work for a limited time, then it could switch to another SOC or stop working.

    Ok I will try describe my case more precisely, RTI should work with some periodicity (let it be 10 us) 32 times and it should do SOC0 lineX, after 32 EOC times it should stop. After that, this SOC could be assigned another lineY from another ADC module.

    So is it safe to use this scenario, and reconfigure SOC with RTI and line on a fly?

  • 0 in reply to Oleg Chaichenko
    TI__Guru*** 135355 points

    Hi Oleg,

    Oleg Chaichenko said:
    So is it safe to use this scenario, and reconfigure SOC with RTI and line on a fly?

    That's something that you'd need to determine if you end up going down that route but I don't believe that approach is the way to go.

    Oleg Chaichenko said:
    RTI should work with some periodicity (let it be 10 us) 32 times and it should do SOC0 lineX, after 32 EOC times it should stop. After that, this SOC could be assigned another lineY from another ADC module.

    Okay so what you want is to use the RTI to set a sequence of ADC conversions then. Using the same trigger with multiple ADC channels is definition of generating a sequence of conversions.

    I'll return back to my recommendation to review our multiple_soc examples. If you are finding that setup has a limitation to what you are trying to achieve, let me know what those are and we can work through how to configure the ADC sequence per your requirements.

    Best Regards,

    Ralph Jacobi