• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 30 subscribers
  • Views 841 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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: Which procedure is picked for handling VIM interrupt in MCU+ SDK of AM263x

Will Gao
Intellectual 2335 points
Part Number: MCU-PLUS-SDK-AM263X

Hi experts, 

From the TRM, I find that there are three VIM interrupt handling methods: 1. through Vector interface; 2. Through MMR interface; 3. Through MMR interface (alternative). 

I want to confirm that which one is picked in our SDK (HwiP_init)? May be the last one? 

 

Best Regards, 

Will 

  • +1
    TI__Mastermind 29198 points

    Hi Will,

    The MCU+ SDK uses the VIC interface described in the AM263x TRM (spruj17.pdf), 10.2.1.8.1 Servicing IRQ Through Vector Interface.

    The VIM is configured in HwiP_init(), and all VIM ISR addresses are set to HwiP_irq_handler() in a loop via calls to HwiP_setVecAddr(). The VIC port is enabled by a call to HwiP_enableVIC(), which sets the R5F SCTLR.VE=1.

    When an IRQ occurs, the ISR address (HwiP_irq_handler()) is supplied to the R5F via the VIC port. The R5F then executes the assembly language HwiP_irq_handler() dispatcher, which calls a C language dispatcher. The C language dispatcher then calls the registered ISR callback function.

    The HwiP_irq_handler() dispatcher is defined for the FreeRTOS and No RTOS cases in the following files:

    • <SDK>/source/kernel/freertos/portable/TI_ARM_CLANG/ARM_CR5F/portASM.S:166:HwiP_irq_handler:
    • <SDK>/source/kernel/nortos/dpl/r5/HwiP_armv7r_handlers_nortos_asm.S:47:HwiP_irq_handler:

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    TI__Intellectual 2335 points

    Hi Frank, 

    Thanks for your reply. From the TRM, if the VIC interface is used, the same interrupt signal will not interrupt the running ISR handler, right? (because they have same priority). 

    But my customer meets a problem: the PWM interrupt ISR is nested repeatedly (because the ISR's running time is larger than the PWM cycle) and will result in stack overflow, then result in prefetch abort exception. 

    Therefore, I recommended them to increase the PWM cycle so that repeated nested-interrupt will not happen. 

    But after reading your reply, I am a little confused why the same priority interrupt will be nested. 

    Anyway, I will study the VIM deeper by myself. Thanks for your guidance. 

    Best Regards, 

    Will 

  • +1 in reply to Will Gao
    TI__Mastermind 29198 points

    Hi Will,

    Is your customer using FreeRTOS, or NoRTOS? Nested interrupts are disabled for FreeRTOS, and enabled for No RTOS. Please see:

    Will Gao said:
    if the VIC interface is used, the same interrupt signal will not interrupt the running ISR handler, right? (because they have same priority)

    Correct, please see the TRM, 10.2.1.5 VIM Interrupt Prioritization

    • VIM supports the interruption of the currently active interrupt by one with a higher priority
    • When an interrupt goes from pending to active (FIQ: reading the FIQ Vector Address, IRQ: reading the IRQ Vector Address, or the coreN_IRQACK going high), then the interrupt is loaded into the corresponding Active Register, and all interrupts of an equal or lesser priority are masked off
    Will Gao said:
    ut my customer meets a problem: the PWM interrupt ISR is nested repeatedly (because the ISR's running time is larger than the PWM cycle)

    Can you please elaborate? How is the same interrupt source being nested? The PWM interrupt source shouldn't be taken if it's already active. If a PWM interrupt arrives while the ISR for a previous PWM interrupt is executing, the next PWM interrupt should only be serviced after the current interrupt is marked complete via an R5F write to the VIM IRQ Vector Address.

    Will Gao said:
    and will result in stack overflow

    Do you mean the IRQ stack overflows on the R5F?

    Will Gao said:
    Therefore, I recommended them to increase the PWM cycle so that repeated nested-interrupt will not happen. 

    How do they know a nested interrupt is occurring? Is there some other interrupt source in the system with higher priority than the PWM interrupt? I suggest driving GPIOs in the ISRs for different interrupts to clearly observe the behavior causing the issue.

    By increase the PWM cycle, do you mean reduce the cycles used in the PWM ISR? That's a good idea, since it seems they don't meet real-time for PWM with their current software, and the system won't work properly even if the interrupt problem is sorted out.

    Does they need R5F nested IRQ support for their application? If not, I suggest setting all VIM priorities to the same value.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    TI__Intellectual 2335 points

    Hi Frank, 

    Thanks for your reply.

    Frank Livingston said:
    Is your customer using FreeRTOS, or NoRTOS?

    They are using NORTOS to develop the software. 

    Frank Livingston said:
    Does they need R5F nested IRQ support for their application? If not, I suggest setting all VIM priorities to the same value.

    They set all interrupt's priorities to 4. 

    Frank Livingston said:
    Do you mean the IRQ stack overflows on the R5F?

    May be the general stack is overflowed. 

    Frank Livingston said:
    I suggest driving GPIOs in the ISRs for different interrupts to clearly observe the behavior causing the issue.

    This is a good idea, and I will let them try it. But after I recommend them to increase the PWM cycle, this problem have been solved. So I thought they meet the nested interrupt problem. 

    Now, I suppose that the interrupt may not nested, but the user stack still overflows in their original configuration. The reason behind this phenomenon may be the pending PWM interrupt break the process of pop data from stack? 

    I will try to test it asap.

    Best Regards, 

    Will

  • 0 in reply to Will Gao
    TI__Mastermind 29198 points

    Hi Will,

    Will Gao said:
    I will try to test it asap.

    Sounds good, I'll wait for the result of your test.

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    TI__Intellectual 2335 points

    Hi Frank, 

    Sorry for my late reply. I have found out the reason why my customer's program will be stack-overflow. The first reason is that they add HwiP_ackIRQ in end of the ISR (they have this habit because of C2000); The second reason is the operating time is larger than the PWM cycle they configured.

    Another key point is that they treat the PWM interrupt signal as a pulse. 

    In order to re-produce their problem, I write a following Timer project: 

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    void TIMER_0_callback(void)
    {
    HwiP_clearInt(TIMER_0_INT_NUM); // to simulate isPulse, because the Timer interrupt is not pulse by default.
    TimerP_clearOverflowInt(TIMER_0_BASE_ADDR) ;
    while( !TimerP_isOverflowed(TIMER_0_BASE_ADDR) ) ;
    timer_cnt = 0xFFFFFFFFu - TimerP_getCount(TIMER_0_BASE_ADDR) ;
    timer_prd = 0xFFFFFFFFu - TimerP_getReloadCount(TIMER_0_BASE_ADDR) ;
    // HwiP_clearInt(TIMER_0_INT_NUM);
    HwiP_ackIRQ(TIMER_0_INT_NUM) ;
    }
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    And the program will get into prefetch abort exception handler: 

    As you can see, before getting into prefetch_abort, the prefetched instruction is at 0x67BDA020. Therefore I think it is because the stack is overflowed. 

    BR, 

    Will 

  • 0 in reply to Will Gao
    TI__Mastermind 29198 points

    Hi Will,

    My thanks for follow up! Is there any way you could share your entire CCS project as a .zip file?

    Regards,
    Frank

  • 0 in reply to Frank Livingston
    TI__Intellectual 2335 points

    Hi Frank, 

    Please check my attachment below. 

    hello_world_am263x-cc_r5fss0-0_nortos_ti-arm-clang.zip

    Best Regards, 

    Will 

  • 0 in reply to Will Gao
    TI__Mastermind 29198 points

    Hi Will,

    Thanks for sharing the code!

    I'll review your code to better understand the problem and solution. However, my understanding is the issue is resolved, so I'll close the thread for now. I'll re-open the thread and post additional comments depending on what I find in your code.

    Regards,
    Frank