RTOS/AM5746: HwiHdr is called twice

It also occurs with other GPIO interrupts. This issue is frequent.

Hi Rahul,

I got a GPIO waveform from customers.(waveform.pdf)
The transition is clear and there is no chattering.
The problem is confirmed in SMP mode.
(We don't know AMP.)
GPIO debounce control is disabled and register settings are the following.

GPIO_PinConfig gpioPinConfigs[] = {
// Timer2_5
GPIO_DEVICE_CONFIG( HAL_GPIO_GPIO_PORT5 ,17 ) | GPIO_CFG_IN_INT_HIGH | GPIO_CFG_INPUT,
｝;

They are experimenting and working on problem solving.

waveform.pdf

Regards,
Rei

Hi Rahul,

They check on the Debounce feature. However, they say that "know the impact of enabling Debounce".

For example, they are concerned about the effect of interrupt in 10 µs cycle.

Regards,

Rei

Hi Rahul,

My customers confirmed the transition of GPIO again. The transition is very clear, we think no problem. (They are set to High level trigger.)
They confirmed the Debounce feature.

Interrupts came in many times, the situation got worse. From these things, we think it's not a problem of the signal.

waveform2.pdf

Could you investigate the cause, focusing on software and SMP?

They think that there is a problem with the level trigger of GPIO driver. It is strange to be interrupted many times by Debounce feature.

Please tell me the cause.

Regards,
Rei

Hi Rei,

Does the interrupt issue occur with non-SMP mode as well?

Can you please send us a simple example of the GPIO interrupt with SMP mode so we can try to reproduce and debug?

Regards,
Garrett

Hi Garrett,

I tried the procedure (project) of the above guide.
But because it was triggered by SW, I could not reproduce the problem.

I will try to make project of HW trigger, however it may take any time.
Could you also make sample code?

Thank you so much.

Regards,
Rei

Hi Garrett-san,rei-san,

Thank you very much for your help as always.
And we need your help more as always again.

>Garrett-san,
Is there a test-case in SMP mode that generates an interrupt by putting an external signal into GPIO?

This is a mandatory test-case for embedded systems.
I think you already had it and tested it. Didn't you?

We have few time to reproduce on AM574xIDK.
Could you test it again?
And please tell me about possibility of this phenomenon's cause.

Best regards,
Hajime

Hi Hajime, 

The external GPIO triggered interrupt in Processor SDK is as Rahul posted above on July 18, which is non-SMP mode.

Rei,

The GPIO interrupt from Processor SDK is Hwi based with a callback function.

How does the SMP configuration look like in the SMP test case with multiple interrupts? Would it be possible Hwi_Params.targetProcList is configured to route the interrupt to both core?

Regards,

Garrett

Hajime, Rei,

I added some basic Task_setAffinity() functions in the external GPIO triggered example after SMP is enabled, and monitored myIntNum variable added for counting the number of calling GPIO callback function. There is no double interrupt issue in my setup/configuration. 

I can see myIntNum increase to 0x10 after I connect the GPIO pin to ground 16 times.

If you could send us the SMP configuration of the double interrupt use case, I can try to replicate that in my setup and work with RTOS kernel team to resolve.

Regards,
Garrett

Rei,

Can you check your Mmu settings for the GPIO register space?  They need to be set to strongly-ordered.

Here's a e2e forum thread showing a customer double-interrupt issue that was solved by doing so:

Regards,

- Rob

Hi Garrett-san Rob-san,

Thank you for your reply.
My customers are checking the MMU settings.

I also created a project to reproduce.
I made the Example project with some changes.
It is a little arrangement to the introduced procedure.
(IDK574 + Pull down setting + Highlevel trigger)

http://software-dl.ti.com/processor-sdk-rtos/esd/docs/latest/rtos/index_how_to_guides.html#rtos-customization-using-an-external-input-to-trigger-an-interrupt-on-am57x

gpio_interrupt.zip

8640.gpio.pdf

This happens with single core(not SMP).

It gets worse when debounce is set.

Regards,
Rei

Their Mmu settings for the GPIO register space are "strongly-ordered".

We think the setting of the sample project is strongly-ordered.

Regards,

Rei

Rei,

So the pull up/down and GPI signal level (low/high) between PDK reference project and your project makes difference. Good finding. We will replicate your setup and try to root cause it.

Regards,

Garrett

Rei,

With the IDK574 + Pull down setting + rising edge trigger, the issue is not reproducible on my setup. I don't have a function generator on hand, so connect the GPIO pin to V3_3D (pin 1 of J21).

I tried the default SYS/BIOS bundled with PDK 1.0.11 as used in your project, also the recent 6.76.1.12, both works fine.

Without debounce enabled, there were more interrupts than expected. But once debouce is set, the counter contains the exact number as triggered GPIO by touching V3_3D. 

I noticed the signal level setting to 2.00V in your setup, can you try to increase it to see if any impact? From AM5746 datasheet Table 5-14. Dual Voltage LVCMOS DC Electrical Characteristics, in 3.3v mode, the minimum voltage is 2V for VIH.

Regards,
Garrett

Hi Garrett,
Thank you for trying.

Even in my environment, when it is set to "rising edge trigger", it seems to work properly. (without debounce setting)

However try "Hwi.addHookSet". Callback function (counter) is executed once, you can see that Hwi happened twice. (useless processing has occurred.)
My customers have confirmed so far.
Could you confirm it?

＞I noticed the signal level setting to 2.00V in your setup, can you try to increase it to see if any impact?

Sorry, I don’t know how to increase the signal level.
Does it mean that the high level threshold can be changed by software?

Regards,
Rei

Rei,

Please let us know if the issue is still pending. I am closing the thread...

Regards,

Garrett

Sorry, I was resting.
I'll summarize this issue.

＊customers issue
Customers input a interrupt signal(3.3V 10µs) from FPGA.
Customer's setting is level-sensitive, interrupt handler executed twice.
They also verified the edge-sensitive setting, hwi Handler is executed once, but interrupt(Hwi_begin) has actually occurred twice.
It was confirmed with Hwi.addHookSet(). (as GPIO_interrupt.pdf)

Hwi.addHookSet({
/* registerFxn:'&myHwi_registerFxn',*/
createFxn:'&myHwi_createFxn',
beginFxn:'&myHwi_beginFxn',
endFxn:'&myHwi_endFxn',
deleteFxn:'&myHwi_deleteFxn'
});

///////////////////////////////////////////////////////////////////
* Reproduced project created by me (single)
I reproduced their phenomenon based on the GPIO sample project.
The sample project was edge-sensitive + Pullup pin setting.
I set the level-sensitive + Pull-down pin setting to get closer to the customer's case. And I input a signal from FunctionGenerator.
One shot of 3.3V (not 2V), 10µs signal. Look at the waveform.

In the Level-sensitive setting, the handler is executed twice, just like the customer.
In an edge-sensitive setting, the handler is a single run, just like a customer.
I didn't check with Hwi.addHookSet (), but probably Hwi_begin happened twice.
///////////////////////////////////////////////////////////////////
I input 3.3V signal. (Note: that picture is 2V Range)

Issue is that the handler is executed twice with the leve-lsensitive setting.

Would you tell me the solution.

Regards,
Rei

Rei,

>>They also verified the edge-sensitive setting, hwi Handler is executed once, but interrupt(Hwi_begin) has actually occurred twice.

>>Issue is that the handler is executed twice with the level-sensitive setting.

Is there any reason that they can't update to edge-sensitive which has been confirmed the hwi handler is executed only once?

Regards,

Garrett

Hi Garrette

My customers are concerned about missing an interrupt in the case of edge-trigger setting.
This is because the signal is logically ORed from the FPGA.
Therefore, they set level-sensitive.

Even in Rising-edge, Hwi_Begin has been confirmed twice.
In other words, useless time is generated.

*Additional Information
They thought it was slow to clear the interrupt flag and tried to call GPIO_clearInt () in the interrupt handler.

Results

It turned out that it becomes a normal operation when clearing the flag in the handler after setting to Rising edge. However, Rising-sensitive is not recommended in customer cases.

Level/rising-sensitive, in both cases, the interrupt is executed twice.
Would you tell me the solution?

Regards,
Rei

Rei,

So the requirement is to have the use case of level-sensitive with one Task_begin call only even though the callback function is executed only once after GPIO_clearInt() is added? And we need resolve the following, correct?

Regards,
Garrett

That is almost right. We think GPIO_clearInt () don’t need to be called in the handler.

C:/ti/pdk_am57xx_1_0_11/packages/ti/drv/gpio/docs/doxygen/html/_g_p_i_o_8h.html#a3653b24f2fa808ad1f35d12f7cbbaecf

void GPIO_clearInt()
Note :It is not necessary to call this API within a callback assigned to a pin.

It is best to solve it without calling GPIO_clearInt ().

(If we need to call clearInt, please let me know)

Regards,

Rei

Rei,

Either GPIO_clearInt() or GPIOIntrClearMask() need call in hwiFxn, please refer to GPIO_v1_hwiFxn(uintptr_t portIdx) in PDK ti\drv\gpio\src\v1\GPIO_v1.c.

Instead of the Hwi.addHookSet(), can they just call Hwi_create() to register the interrupt as in the PDK GPIO driver? What is included in their Hwi_begin function? hookSet.beginFxn can be undefined/NULL. Or can they provide us the test project with the Hwi.addHookSet() and hookSet.beginFxn to reproduce the issue?

Regards,
Garrett

Hi Garrett,

I confirmed GPIO_v1.c.
C:\ti\pdk_am57xx_1_0_11\packages\ti\drv\gpio\src\v1\GPIO_v1.c

GPIO_v1_hwiFxn (uintptr_t portIdx) have GPIOIntrClearMask(gpioBase, intrLineNum, gpioPins).
Therefore, we think it isn't necessary to call GPIO_clearInt() by the user.

What we really want to solve is that the interrupt handler(Hwi_begin) is executed twice with high-level-sensing.

Please investigate this issue.

Regards,

Rei

Rei,

>>Therefore, we think it isn't necessary to call GPIO_clearInt() by the user.

Does the customer use the GPIO driver from Processor SDK? If yes, why "It turned out that it becomes a normal operation when clearing the flag in the handler after setting to Rising edge" and the following use cases make difference?

From the interrupt.pdf in the first post - "They used Hwi.addHookSet to check Hwi's time", are we debugging the addHookSet function for checking Hwi's time or the "interrupt handler(Hwi_begin)" for GPIO?

GPIO interrupt is registered in PDK driver so addHookSet is really not needed as shown in PDK GPIO LED blinking example.

The beginFxn is invoked just prior to calling the ISR function. And as I commented in previous post - hookSet.beginFxn can be undefined/NULL.

Again, please try to get the test project from your customer so we can better understand the use case.

Regards,

Garrett

Can I mark this as resolved?

Hi Todd,

Thank you for always helping us.

We are still investigating this issue, so please be patient.

Regards,

Rei

Hi Todd,

We reproduced this issue.
Please check the uploaded pdf and project.

Document
GPIO_issue_Overview.pdf
Project
gpio_issue.zip

Regards,
Rei