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.

AM2634: What should be the operation timing sequence for the IRQPRIMSK register? Why did modifying the code for operating the IRQPRIMSK register, adding delay instructions and readback, solve the problem?

Part Number: AM2634

Tool/software:

In the AM2634 chip project, customers disabled interrupt response by masking the interrupt priority method using the IRQPRIMSK register. It was found that after setting the IRQPRIMSK register to 0, the IPC interrupt with priority 15 could not be masked and still responded. However, no other interrupts in the same project were found to be unmaskable. After modifying the IRQPRIMSK register code, the issue was resolved, and no recurrence was observed during operation for over 12 hours. Please refer to the attachment for detailed issue description and code modifications. Since the AM2634 and AM263p chips we are currently adapting both use the IRQPRIMSK register to mask interrupt priorities, their operation methods are identical. The IRQPRIMSK register is managed by the VIM module of the TI chip. We hope TI experts can assist in investigating and responding to the following questions. 1. Compared to other interrupts, what are the differences in the triggering and disabling mechanisms of IPC (Inter-Process Communication) interrupts? Why do RTI (Real-Time Interrupt) and CAN (Controller Area Network) interrupts, which have a higher triggering frequency in engineering projects, not experience the issue of disabled interrupt failure, while this issue is only observed with IPC interrupts. 2. The client utilizes IPC interrupts in both AM2634 and AM263p projects. This issue was identified in the AM2634 project, but the inability to disable IPC interrupts was not observed in the AM263p project. Are there any differences between the VIM and IPC modules in AM2634 and AM263p? Why does this phenomenon occur? Does AM263p also face the risk of IPC interrupts being unable to be masked? What should be the operation timing sequence for the IRQPRIMSK register? Why did modifying the code for operating the IRQPRIMSK register, adding delay instructions and readback, solve the problem? Please assist in confirming whether this method can solve the current problem. Can this method solve the problem of invalidated interrupt priority masking for all interrupts?
  • Hi ,

    Apologies this was dropped off from our radar and we could not respond earlier. I'm looking into the issue.

    Regards,
    Shaunak

  • Hi ,

    There is a HW bug in VIM related to IRQPRIMSK, due to which it won't take effect immediately and have some side effects of re-triggering an interrupt etc. As a result, we see adding a delay is working here.

    We have fixed this in SW in the SDK and added proper sequence to mask interrupts and restore them back, which will be a part of the next official SDK release v11.0 in August 2025. I'll share more details (hopefully by Thursday) once we have the codebase synced on the public GItHub, so I can share the direct files which you can diff and observe the changes.

    Does AM263p also face the risk of IPC interrupts being unable to be masked?

    Yes, since this is a HW issue with VIM related to IRQPRIMSK.

    Regards,
    Shaunak

  • Hi Neusoft team,

    The patch for the implementation of IRQPRIMSK is shared to you internally by TI FAE.

    Please let us know if you are able to resolve the same after looking into this patch

    Thanks and Regards,

    Nikhil Dasan

  • 1. Compared to other interrupts, what are the differences in the triggering and disabling mechanisms of IPC (Inter-Process Communication) interrupts? Why do RTI (Real-Time Interrupt) and CAN (Controller Area Network) interrupts, which have a higher triggering frequency in engineering projects, not experience the issue of disabled interrupt failure, while this issue is only observed with IPC interrupts. 

    Answer : The concept of PriMask should only depend on the Priority of the interrupt and the type of the interrupt (Pulse or Level). The masking and execution of the same depends only on these 2 parameters.

    The documentation shared offline explains the flow.

    2. The client utilizes IPC interrupts in both AM2634 and AM263p projects. This issue was identified in the AM2634 project, but the inability to disable IPC interrupts was not observed in the AM263p project. Are there any differences between the VIM and IPC modules in AM2634 and AM263p? Why does this phenomenon occur?  Does AM263p also face the risk of IPC interrupts being unable to be masked? What should be the operation timing sequence for the IRQPRIMSK register? Why did modifying the code for operating the IRQPRIMSK register, adding delay instructions and readback, solve the problem? Please assist in confirming whether this method can solve the current problem. Can this method solve the problem of invalidated interrupt priority masking for all interrupts?

    Answer: I would suggest trying this with the latest implementation provided by TI, which should resolve the above issues.

    Thanks and Regards,

    Nikhil Dasan