STM32F100 Непроизвольное срабатывание прерывания Опции

[Plexus]

Требуется помошь в поиске проблемы.

Непроизвольно срабатывает прерывание EXTI0_IRQHandler().
Нога подтянута к 3.3В резистором. И на нее подается импульс.
Прерывание должно срабатывать по спаду. И срабатывает. Но время от времени, в обработчик залетает и выполняется проверка на EXTI_GetITStatus(EXTI_Line0). Импульсы в этот момент не поступают (слежу на осцилле).
Что за магия такая?

CODE

void init_EXTI()
{
GPIO_InitTypeDef GPIO_InitStructure;
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA , ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2ENR_AFIOEN , ENABLE);
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO_Init(GPIOA, &GPIO_InitStructure);
GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0);

EXTI_InitTypeDef EXTI_InitStructure;

EXTI_InitStructure.EXTI_Line = EXTI_Line0;
EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Falling;
EXTI_InitStructure.EXTI_LineCmd = ENABLE;
EXTI_Init(&EXTI_InitStructure);
}

void init_NVIC()
{
NVIC_InitTypeDef NVIC_InitStructure;
NVIC_InitStructure.NVIC_IRQChannel = EXTI0_IRQn;
NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0x0F;
NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0x0F;
NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE;
NVIC_Init(&NVIC_InitStructure);
}

int main(void)
{
RCC_Configuration();
init_timer();

init_EXTI();
init_NVIC();

NVIC_EnableIRQ(EXTI0_IRQn);
NVIC_DisableIRQ(TIM6_DAC_IRQn);


while(1);
}

void EXTI0_IRQHandler(void)
{
if (EXTI_GetITStatus(EXTI_Line0) != RESET)
{

EXTI_ClearITPendingBit(EXTI_Line0);
TIM_ClearITPendingBit(TIM6, TIM_IT_Update);
TIM_SetCounter(TIM6, 0);

if (flag)
{
flag = 0;
NVIC_EnableIRQ(TIM6_DAC_IRQn);
}
}
}

Сообщение отредактировал IgorKossak - Aug 29 2014, 20:47

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[amiller]

По моему STM ведёт себя абсолютно правильно. Фронт есть - прерывание должно быть.
Вообще кнопки и прерывания по входу - вещи плохо сочетаемые. В реальных условиях (при наличии помех) гарантируются случайные срабатывания.
Правильно будет - опрашивать с определенной частотой. И если из 100 опросов больше 50 единиц, значит кнопка нажата.
И посмотрите на наличие на плате конденсатора C22. Похоже его нет. Если поставить примерно 100n, то в Вашем случае должно помочь.

[ISF]

По моему STM ведёт себя абсолютно правильно. Фронт есть - прерывание должно быть.
Вообще кнопки и прерывания по входу - вещи плохо сочетаемые. В реальных условиях (при наличии помех) гарантируются случайные срабатывания.
Правильно будет - опрашивать с определенной частотой. И если из 100 опросов больше 50 единиц, значит кнопка нажата.
И посмотрите на наличие на плате конденсатора C22. Похоже его нет. Если поставить примерно 100n, то в Вашем случае должно помочь.

Согласен что кнопка и прерывание = неудачное решение, но тут даже до нажатия кнопки дело не доходит. Достаточно просто коснуться вывода PA0 щупом тестера для замера напряжения и БАЦ!, получите прерывание. Я бы ещё понял если бы вывод болтался без подтяжки в воздухе и я его касался проводником - тут уж без вариантов будет многократное срабатывание прерывания от наводок, емкости щупов и т.п. Но почему себя так ведёт полностью обвязанный и прикрытый от всех случайностей вывод мне совершенно неясно (

Конденсатора C22 на плате нет, но я специально проверял на выводе PA1 схему с внешней подтяжкой и полной RC цепью - результат отрицательный, лучше не становиться. Вот проверенные мною варианты. Подтягивающий резистор менял от 100 Ом до 10к

[jcxz]

Но почему себя так ведёт полностью обвязанный и прикрытый от всех случайностей вывод мне совершенно неясно (

Потому что Вы цепляете к нему огромную антенну (из щупов, их проводов и ваших рук и прочего тела), на которую наводится много ВЧ грязи. Неужто это не очевидно???
А Ваш AVR мог не регистрировать их например из-за своей тормознутости - очевидно его GPIO работает на гораздо меньших частотах и не успевает зарегистрировать короткие помеховые импульсы. Плюс к тому же - он 5-вольтовый, что так же увеличивает его нечувствительность.

[Forger]

Подозреваю, что речь идет о неком хитроумном способе выбора МК для нового проекта - касаться руками работающего проца.
Возможно, это - проект для оборонки, нынче их ОТК очень требовательно ко всему.
Очевидно, что STM32 вообще не проходит этот тест, поэтому придется возвращаться на AVR. Другого пути я не вижу. Увы

[jcxz]

Очевидно, что STM32 вообще не проходит этот тест, поэтому придется возвращаться на AVR. Другого пути я не вижу. Увы

Вангую - начальство нагибает ТСа: "Осваивай мол ARM, нужно уже серьёзные задачи решать, пора слезать с этого детсада AVR" . И ТС ищет - как бы так начальству доказать что ARM-ы плохи? , чтобы не изучать их.
Вот он потыкал в лапку STM-а и.... о, радость! - ложные срабатывания!! Можно бежать к начальству и наглядно продемонстрировать "глюки" , чтобы оно отстало с этими ARM-ами...