GPIO unexpected interruption and processing

Gen_X

GPIO unexpected interruption and processing [Copy link]

 

Chip: STM32G030, GPIO: PA12, Function: LCD menu selection after interruption

Phenomenon: 1-3 interruptions occur every 10 seconds or so, and at least one is not fixed.

Reason: GPIO external interrupt input mode, pull-up, the button connects this PIN to ground, generating a FALLING interrupt.

It is speculated that the pull-up resistor (internal 10k) is large and the pin is not connected to a capacitor for noise reduction, resulting in instability when floating.

Processing: 10mS anti-jitter confirmation was added after the interruption (failed to eliminate false operation), and then a delayed button release confirmation was added. As a result, the "interruption" was very accurate.

Unfortunately, it was only handled by the emergency software, but the reason is unknown. The lead length is only 25mm, and it is surrounded by GND for 4 weeks, with no external interference source.

The power supply is 5VDC-3.3V, 47uF+0.1+0.1, there shouldn't be any problem, but I can't figure it out. Hope someone can give me some advice.

damiaa

It is best to use timer interrupts for key processing. Set the timer to interrupt once every 10ms, scan the key each time, and do it N times in a row. For example, if it is 0 8 times, it is definitely 0

If it is 1 for N consecutive times, it is definitely 1. In this way, the jitter is naturally eliminated. And it is very stable.

tagetage

The above method is one way. Your problem is most likely a software problem. If it is hardware, it is a switch problem.

For software, you should also carefully check the IO configuration, because the IO configuration may change during the program running.

freebsder

1-3 interruptions every 10 seconds or so?

Is there noise or interference introduced somewhere?

Gen_X

damiaa posted on 2024-7-18 12:26 It is best to use timer interrupt for key processing. Set the timer to interrupt once every 10ms, scan the key each time, for N consecutive times, for example, 8 times is 0, then it is definitely 0...

Thank you very much! This method is OK.

But the actual fastest key operation is 8-12ms, which means a 3ms interrupt to read the GPIO, and read it about 2-4 times. If the PCB area is not limited, I would rather choose a capacitor with a price of 0.01 and add simple anti-shake software.

In other words, for the interrupt input of the "switch", it is best to combine software and hardware, otherwise there will be too many accidents, and the key is to use more resources. If it is not a low-level trigger, I will definitely change it to a rising edge trigger interrupt, which should be more stable.

damiaa

Gen_X posted on 2024-7-18 16:08 Thank you very much! The method is OK. But the actual key operation is faster in 8-12ms, that is to say, a 3ms interrupt is made to read the GPIO, and it is read about 2-4 times, such as...

The keys are not usually pressed that fast. The fastest hand movement is a few tenths of a second, or a few hundred milliseconds. The fastest is 0.1 seconds.

Secondly, if the keystrokes are really fast and you are worried that you can't scan so many times at a time, you can set the timer interrupt to once every 1 millisecond or 2 milliseconds. You can also reduce the N used for the number of times to judge.

Anyway, in a word, it is enough to make it stable. Don't worry. There is no use for adding capacitors.

damiaa

There was another post before, see if it is useful https://en.eeworld.com/bbs/thread-501060-1-1.html

wangerxian

There are 1-3 interrupts every 10 seconds or so, and at least one is not fixed. Is it a software problem? You can use an oscilloscope to capture the interrupt pin and see the situation.

Gen_X

There are no changes to the hardware or software, only a sentence is added after the anti-shake delay:

__HAL_GPIO_EXTI_CLEAR_FALLING_IT(GPIO_Pin);

That's fine, I really don't know why.

I used to think that the HAL library executed "CLEAR" at the entrance of each interrupt (which is actually the case), so I usually don't add "CLEAR" in the interrupt CALLBACK. This is the advantage of the HAL library, but this time I changed my perception:

If time resources are not absolutely tight, it seems that "CLEAR" can be added. Don't be afraid of redundancy. At least it can prevent "accidental" residual interrupt triggering after the interruption. Of course, it must be admitted that false triggering exists, but it can be eliminated through anti-shake.

To summarize the reasons: it is a personal habit. The interrupt flag "CLEAR" is generally not added in CALLBACK, resulting in multiple unstable interrupt remnants (glitches) causing multiple interrupts.

Thanks to @wangerxian and other netizens for their patient answers and analysis.

Gen_X

Through this small "project", I learned that the small system made of STM32G030 can still be used in the 220VAC-3.3vDC circuit, and its stability exceeded my expectations. In the past, I used the transformer + linear voltage regulation measurement and control circuit made by PIC16 and 51, and suffered a lot. For a long time, I thought it was a bit scary to use microcontrollers in industrial control.

Maybe it is because of the previous devices that the CPU cannot be touched. At the least, it will freeze, and at the worst, the program will run away. Therefore, there is a rigid demand for both soft and hard WDT. The current 32ARM is as docile as a cat in operation and never loses its temper.

se7ens

I have learned a lot. Thanks for sharing. I have a deeper understanding of the application of software filtering.

lugl4313820

The power supply is 5VDC-3.3V, 47uF+0.1+0.1, there shouldn't be any problem, but I can't figure it out. Hope someone can give me some advice.

Use a logic analyzer or oscilloscope to capture the IO waveform.

御坂10032号

Is the problem solved? What caused it?

Gen_X

An unrelated PWM is one every 10 seconds, although the PCB is not on the same layer and there are no parallel segments.

However, due to the existence of a three-dimensional intersection, unwanted interruptions occur (this can be proven by the 10-second cycle, but the number of interruptions per cycle is uncertain, ranging from 1 to 3 times).

This "irrelevant" PWM will have an inductive interruption on the rising edge every time it is generated, and sometimes on the falling edge as well, so it feels like the number of interruptions is relatively large, and it can even go through the 10ms "de-bouncing", which I can't figure out!

Gen_X

damiaa posted on 2024-7-18 16:15 The keys are usually not that fast. The fastest hand movement is a few tenths of a second, that is, a few hundred milliseconds. The fastest is 0.1 seconds. This is one of the two. If the key is pressed...

This method is acceptable. If there are sufficient resources, it is definitely best to use software to achieve what the software can achieve.

I have measured that my fastest keystroke speed is 11ms, occasionally it can reach 9ms, and most people are above 16;

Generally, electronic micro switches are between 15-30 (fastest);

Intermediate relay electromechanical products are generally about 10-30ms;

Contactors and most mechanical switches are over 35~50ms, and some are over 150ms.

Therefore, the anti-shake time is generally selected within 8-23 according to the actual situation of the switch.

liangxinpaul

By adding delayed release, noise reduction is actually performed, which shows that there is no problem with the software. Try using an oscilloscope to display the waveform of GPIO:PA12.