• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 31 subscribers
  • Views 593 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.

Original question:

AM2634-Q1: Autosar : ADC ISR not triggered on period match event of PWM

AM2634-Q1: Autosar : ADC interrupt notification is called only once for CAT1 and CAT2 ISR configurations

Ashish Sebastian
Prodigy 225 points
Part Number: AM2634-Q1

MCAL8.6.2 and MCAL8.6.2.1

In the context of ADC SoC being triggered from PWM period match events; the EoC ISR and the corresponding notification is only triggered once. This issue was from the context of the below issue.

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1240070/am2634-q1-autosar-adc-isr-not-triggered-on-period-match-event-of-pwm/4691640#4691640

The temp solution is to call Adc_EnableHardwareTrigger API cyclically, but is expected to be called only at Init. 

Creating the ticket for reference to get to know when the fixed MCAL would be available to be used in the project.

  • 0
    TI__Genius 12380 points

    Hi Ashish,

    We have filed internal ticket MCAL-12616 and will be fixing in upcoming MCAL_AM263_09.00.00 release scheduled on July 31st 2023.

    Thanks And Regards,

    Sunil Kumar M S

  • 0 in reply to Sunil Kumar M S
    TI__Genius 12380 points

    Hi Ashish,

    Can we close this ticket?

    Thanks And Regards,

    Sunil Kumar M S

  • 0 in reply to Sunil Kumar M S
    Prodigy 225 points

    I am not clear on your process Sunil. Usually, once we receive the package and test the working is when we consider it as closed. Cuase for the question; 'Did this fix your issue'; we cannot be sure until we got a package and see it working. Thats my thinking. 

    But if you have already implemented and tested the fix at TI side; and would like to consider that as the closing criteria, then you could follow that as well.

  • 0 in reply to Ashish Sebastian
    TI__Genius 15435 points

    Hi Ashish,

    Ashish Sebastian said:
    I am not clear on your process Sunil.

    The process of E2e is that, you can keep the ticket as long as you require and till you're satisfied the issue is resolved. 

    Ashish Sebastian said:
    Usually, once we receive the package and test the working is when we consider it as closed

    In case if there's a urgency and can't be waited till official release is made, you can request Sunil and team to make a patch release for you which can be accomodated by the Sunil's team and only after testing that patch if you feel the issue is resolved you can close the E2e. :)

    Thanks

  • 0 in reply to Kowshik Gudimetla
    Prodigy 225 points

    Hi Kowshik,

    We are planning to take the next official release for the integration as; MCAL to SIP integration is going to be time consuming. That's why we are waiting for Septembers release to have as many fixes available; (as you you know for the other tickets that we have created as well), so that we can minimize the number of SIP integration activity.

    I would say; that we keep it in Halt/Waiting feedback state if possible. Or if you are confirmed that the fix is already tested and in the MCAL_AM263_09.00.00 release scheduled on July 31st 2023; then you can close it by proving that the package details for everyone's benefit. The reason being; there can be unexpected slippages, which could result in the fix being in another package than what was initially planned. Just keeping the worst case scenario in mind. :)