AM2732: AM2732 Interrupt Nesting Exception

Hi There,

Before I answer your questions, I have a few questions for you.

How did do your experiment?

What is the hardware platform are you using (AM273x EVM)?

What version of the MCU+ SDK you are using (09.02.00.52 is the latest one)?

Are you using FreeRTOS or NORTOS?

In general, the high priority interrupt can interrupt the low interrupt handling, if the nested interrupt is supported. However, if the high priority ISR is not exited properly (interrupt masking, or without EOI), then the higher priority interrupt may not be properly processed thereafter.

Best regards,

Ming

Thank you for your answer. I will answer your questions one by one.

1. I entered a "while (1)" loop in the low priority IRQ2 and did not let IRQ2 exit. I waited for the high priority IRQ1 to interrupt, and used the variable "Irq1_Cnt" to count in the interrupt service function of IRQ1. In the end, I found that the value of Irq1_Cnt was 1; So IRQ1 can interrupt IRQ2, but only once.

2. The platform I am using is AM273x EVM.

3&4. I did not use any SDK related code for interrupt handling. We adapted the AUTOSAR OS for this chip, drove interrupts, protected the scene, restored the scene, entered interrupts, confirmed interrupts, and exited interrupts, all of which were implemented by ourselves.

Attachment: I found that after IRQ1 cannot interrupt IRQ2, when observing the VIM register, the corresponding interrupt displayed in PRIIRQ is IRQ1, and the interrupt displayed in ACTIRQ is IRQ2;
Note: The interrupt number corresponding to IRQ1 is 109, and the interrupt priority is 2
The interrupt number corresponding to IRQ2 is 13, and the interrupt priority is 3
Attached below are corresponding on-site screenshots:https://i.afbcs.cn/vCfGru

Hi There,

The first place to check is the I bit of the Program Status Register

The other register to check is the IRQ mask register. Make sure IRQ1 is not masked

Please check the value of the following registers:

#define VIM_STS(j) (0x404U + ((((j) >> 5) & 0xFU) * 0x20U))
#define VIM_INT_EN(j) (0x408U + ((((j) >> 5) & 0xFU) * 0x20U))
#define VIM_INT_DIS(j) (0x40CU + ((((j) >> 5) & 0xFU) * 0x20U))

Best regards,

Ming

Thank you for your reply:
I have confirmed CPSR The value of I is 0, which belongs to the enable global interrupt state;
The corresponding registers for high priority IRQ1 (interrupt source 109) are as follows:
The bit of the VIMsTS register corresponding to IRQ1 is 1 (VIMsTS_3=0x00002000);
The bit bit of the VIP_EN_SET (VIP_INT_1N) register corresponding to IRQ1 is 1 (VIP_EN_SET_3=0x00002000);
The bit of the VIP_EN-CLR (VIP_INT-DIS) register corresponding to IRQ1 is 1 (VIP_EN-CLR-3=0x00002000);

I cannot achieve it using the above method,
Could you please provide the corresponding driver or test routine

Hello, these days I have been trying to fix the hardware issue using the method described in the AM273x errata manual. However, after testing, we have found that although the original issue has been fixed, it will cause new problems. We have found that there are some interruptions that have not been responded to correctly.

Hi There,

Can you elaborate the "there are some interruptions that have not been responded to correctly" a little bit more.

Best regards,

Ming

Hello, after completing the interrupt nesting test described above, I caused the system to exit IRQ2. At this time, I found that other interrupt IRQ3 (interrupts with lower priority than IRQ2)  could not receive a normal response. However, before the interrupt nesting test, IRQ3 was able to run normally. I observed the VIM_STS register corresponding to IRQ3 and found that the corresponding bit could not be set properly, but its VIM_EN_SET was successfully set, and the peripheral interrupt flag corresponding to IRQ3 could also be set normally.

Hello:
I am certain that there is no other way to clear VIM_STS because we are using the RTI module, which triggers a cycle timer interrupt. We found that the RTI counter is running normally, the comparator can also refresh normally, and the interrupt flag bit RTIINTFLAG corresponding to the RTI module can also be set normally, but the interrupt cannot be triggered. We cannot understand the reason for this situation.

Hi There,

Can you share your CCS project and source code, so that we can reproduce the same on our side?

Best regards,

Ming 

Hi Currin,

Thanks a lot for your source code and document. I will test it out on the AM273x EVM and get back to you early next week.

Best regards,

Ming 

hello Ming:
I will provide the following answers to your doubts.
1. Our current solution is to strictly follow the Workaround corresponding to the problem (i2162) described in the errata manual provided by TI. Each step can be compared with the solution provided by TI. If you doubt our approach, we hope to receive your driver routine to solve the problem.
2. Regarding the issue mentioned in "1. abc" above, do you wish to actually trigger the IRQ (76) interrupt and execute the interrupt callback program? However, the solution provided by TI clearly states that the interrupt does not need to enter a specific interrupt callback, and can even be masked.
3. The question "2" you raised corresponds to steps 3 and 5 in Workaround. If you have any questions, you can read this manual or provide us with corresponding solutions.
thank you.

Hi Renjia,

I will contact the person who wrote the workaround for this erratum and ask for the test code for this workaround. Will get back to you early next week 

Best regards,

Ming

hello Ming:
I used the hardware development board in my hand again for testing, and the phenomenon is still abnormal. Based on your test results, is it possible that the difference is caused by the inconsistency of our hardware? I will take a photo of my hardware and send it to you. I hope you can help me.

thank you.

Hi Renjia,

I noticed two differences between your EVM and my EVM:

1. You are using the "No Boot" mode. I am using the QSPI Boot mode. How do you initialize your SOC? (using GEL file?) Please try to use the SBL_NULL with QSPI Boot mode and load your program.

2. My EVM has the HS-FS device, but yours has the GP device, but I do not think it should cause any issue. I will try the same test on a GP EVM soon.

Both our EVMs are Rev. C

Best regards,

Ming

Hello Ming:
Is this issue related to the chip batch

Hello, Ming:
Sorry, due to personal reasons, I was unable to work properly during this period, so I am only replying to you now. I don't know how to use QSPI boot mode, I hope you can help me. And I'm not sure why different boot modes lead to such a big difference, and can you use no boot mode to help test it.

Hi Ming:

    I have successfully downloaded the sbl-NULL file as described in the document.But I couldn't successfully connect to it.Even if the chip is reset, it cannot be connected.What could be the reason.Thanks!

Hi Ming:

    Thank you for your support. The problem really doesn't arise anymore.But the true cause of the problem is still unclear.NO BOOT mode uses GEL file to boot,and in QSPI boot mode,what is the difference between using the default_sbl_qspi.cfg file and the default_sbl_null.cfg file? What did they do?