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] - для короткого!!!

[Ant_m]

Импульсы в этот момент не поступают (слежу на осцилле).

А на GPIO 0 port B, С, D что происходит?
У меня все нормально работает, только у меня нет работы с TIM6 и приоритеты стоят не 0x0f, а 3...

[Plexus]

А на GPIO 0 port B, С, D что происходит?

Ничего. Я использую STM32VLDiscovery. Единственное, я удалил из вышепреведенного кода настройку таймера и настройку светодиодов на PC8 и PC9.
Срабатывание происходит само по себе, когда плата лежит и ее никто не касается.

Порт был настроен так:

Код

RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
GPIO_Init(GPIOC, &GPIO_InitStructure);
GPIO_WriteBit(GPIOC, GPIO_Pin_8 | GPIO_Pin_9, Bit_SET);

Это же не значит, что ошибка в том, что я указал GPIO_Pin_8 | GPIO_Pin_9 вместо GPIO_Pin_All?

[Golikov A.]

это ваще может значить черти что, куча народу нарывалось на то что эти дурные функции делали что хотели а не что надо.

там через раз срабатывает вот это GPIO_Pin_8 | GPIO_Pin_9;

иногда биты настройки одного пина и второго находятся в разных регистрах и в этом случае такое вызывает ваще непредсказуемые результаты. надо проверить состояние регистров, как они настроились. А лучше настроить их ручками

[Plexus]

Т.е. достаточно настроить все GPIO и проблема пропадет?

Кто еще сталкивался с этой проблемой? Если есть ссылки на топики - поделитесь, пожалуйста.

[Golikov A.]

где то краем ухо я слышал про ложные срабатывания прерываний, этим грешили процы от ST,


вот типа
http://electronix.ru/forum/index.php?showt...%E2%E0%ED%E8%E5
и в других контекстах слышал.

эта тема про UART, про пины вроде тоже проходило где то...

Другое дело что надо сначала все верно настроить, чтобы в регистрах было то что надо, а не дергая странные индуские функции. Многие из них очень плохо написаны. И только потом уже верить в ложное срабатывание.

[adnega]

где то краем ухо я слышал про ложные срабатывания прерываний, этим грешили процы от ST,

Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST.

[Plexus]

Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST.

Хорошо. А этого можно как-то избежать? Это лечится? Как другие разработчики решали подобные проблемы?

[adnega]

Хорошо. А этого можно как-то избежать? Это лечится? Как другие разработчики решали подобные проблемы?

Это не ваш случай.
Попробуйте ногу посадить железно на 3.3В. Попробуйте настроить EXTI на другой вывод. Если и в этом случае будут вызовы, то ищем в одном месте, если пропадут, то в другом, например, в ES

A low-amplitude voltage glitch may be generated (on ADC input 0) on the PA0 pin, when the
ADC is converting with injection trigger. It is generated by internal coupling and
synchronized to the beginning and the end of the injection sequence, whatever the
channel(s) to be converted.

Кста, уSTM32VLDiscovery на PA0 сидит кнопка. Если вы имеете дребезг по нажатию/отпусканию кнопки, то это третий случай.

[Plexus]

Это не ваш случай.
Попробуйте ногу посадить железно на 3.3В. Попробуйте настроить EXTI на другой вывод. Если и в этом случае будут вызовы, то ищем в одном месте, если пропадут, то в другом, например, в ES

Кста, уSTM32VLDiscovery на PA0 сидит кнопка. Если вы имеете дребезг по нажатию/отпусканию кнопки, то это третий случай.

Зачем сажать на 3.3В? У меня и так подтяжка железно через резистор на 3.3В, а не программно. Что вы имеете в виду?

Буду на другом выводе юзать, но я должен быть уверен, что все работает как часы. А ждать самопроизвольного срабатывания - очень долго. Не всегда ж срабатывает.

Дребезг исключен 100%. Проверка и на осцилле была и физически дребезг исключен. Подключение через транзистор на землю.

[Golikov A.]

самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание. Если это правда беда кортекса-М, но что-то тьфу тьфу тьфу на лпц не замечал такого....

[AHTOXA]

Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST.

Не, spurious - это как раз "ложные". Они не обязательно повторные, просто прерывание без причины.

самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание.

Вот именно.

но что-то тьфу тьфу тьфу на лпц не замечал такого....

Гы. AN10414 Handling of spurious interrupts in the LPC2000

[Golikov A.]

ну он же не кортекс-м...

Можно в 2 словах откуда они рождаются? Я как то не искушен в этом вопросе, думал это чисто СТ косяк, а выходит все же нет, че почитать?

UPD. А нашел, в приведенном же документе есть причина их возникновения. Но что-то получается что это не для любой периферии возможно и причина в конвейере, то есть фактически на самом деле прерывание было, просто пока конвейер чистился оно исчезло. Но такое не возможно для GPIO прерываний, или возможно?

Как оно все рождается то?

[adnega]

ну он же не кортекс-м...

Согласен. У кортексов и контроллер прерываний совсем другой. Про ложные срабатывания (даже на STM32) ничего не слышал за более чем 4 года использования в серийном производстве (~ 100 изделий в месяц) на STM32F100/103/107/407.

[Plexus]

самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание. Если это правда беда кортекса-М, но что-то тьфу тьфу тьфу на лпц не замечал такого....

А какой именно флаг проверять? Разве в моем коде обработчик не полный?

[AHTOXA]

ну он же не кортекс-м...

Ну так spurious interrupt - это не кортексо-специфическая штука. Откуда рождается - вопрос сложный, покрытый мраком Возможно, что очень сложный контроллер прерываний, и не всегда всё успевает сбрасываться. Возможно ещё что-то. Главное, что жить это не мешает.

Согласен. У кортексов и контроллер прерываний совсем другой. Про ложные срабатывания (даже на STM32) ничего не слышал за более чем 4 года использования в серийном производстве (~ 100 изделий в месяц) на STM32F100/103/107/407.

Погуглите "spurious interrupt stm32", найдёте изрядно примеров. К тому же, если у вас в процедурах обработчиков прерывания есть проверка флага прерывания на входе, то вы это ложное прерывание никак и не заметите. Особенно в производстве

А какой именно флаг проверять? Разве в моем коде обработчик не полный?

У вас всё правильно, так и надо.

[adnega]

Погуглите "spurious interrupt stm32", найдёте изрядно примеров. К тому же, если у вас в процедурах обработчиков прерывания есть проверка флага прерывания на входе, то вы это ложное прерывание никак и не заметите.

Флаги на входе конечно же обрабатываю. Я знаю как минимум два источника "ложных" прерываний:
1. Не сброшены флаги отложенных прерываний в NVIC и/или периферийного модуля при разрешении прерывания от этого модуля;
2. Очистка бита запроса прерывания от периферийного модуля в самом конце обработчика прерывания от этого модуля.
ST в этих случаях совершенно ни при чем, и косяк целиком программиста.

В то, что прерывание может само по себе возникнуть - не верю. Ибо для всех неиспользуемых прерываний у меня заглушка, и я ни разу в нее не влетал.
Или речь идет только о разрешенных прерываниях?

[Golikov A.]

о разрешенных конечно, иначе это была бы мощная бага.

Я так понял их описания есть такой расклад, на примере UART идут данные, возникает прерывание что пришел байт, но сразу мы в прерывание не попадаем, сначала конвейер должен доработать, и если в конвейере будут команды запрета прерывания то будет флаг, когда его быть не может. Или если будут какие то ошибки за такты конвейера то возникнет другое прерывание, но первое возникшее все равно убдет отработано.

Вообще как то мутно написано%(... хорошо бы чтобы кто на пальцах объяснил...

[AHTOXA]

Флаги на входе конечно же обрабатываю.

Тогда вы ничего не можете утверждать наверняка
Поставьте в каждом прерывании по два счётчика, один увеличивайте при входе в прерывание, второй - после успешной проверки флага. И через пару месяцев прогона на сотнях своих устройств снимите показания. Это будет хоть что-то. Хотя даже в этом случае отсутствие ложных прерываний не будет говорить о том, что их не бывает

Я знаю как минимум два источника "ложных" прерываний:

Да, эти два вида конечно наиболее распространены. Но есть и другие.
Лично сталкивался с возникновением прерывания от DMA при отключении канала в F4. Вот аналогичный случай. Наверняка есть ещё (не зря же во всех примерах от ST во всех обработчиках прерываний стоят проверки флагов, даже когда источник прерывания гарантированно один-единственный). Смысла копать глубже не вижу, проверка флагов решает проблему.

ЗЫ. Речь конечно только о разрешённых прерываниях.

[Plexus]

У вас всё правильно, так и надо.

Так дело в том, что эта проверка в прерывании и проходит.

Код

if (EXTI_GetITStatus(EXTI_Line0) != RESET)

Самопроизвольно выполняется это условие.
Если цеплять купюроприемник и в обработчике прерывания инкрементировать каждый импульс (сумму денег), то через некоторое время самопроизвольно отработает обработчик прерывания, и приплюсуется лишняя сумма денег. Как быть?

[Golikov A.]

а полингом проверить состояние пина нельзя? Кстати а сумму откуда узнаете или этот девайс сумму импульсами сообщает? Может правильнее этот импульс повесить на таймер, счетчиком, пусть в железе само считается чего на прерывания то реагировать?


кстати про сброс прерывания в самом конце,насколько в конце? Прям последняя команда? Я так понимаю это вариант когда флаг не успевает сброситься до выхода? Сколько команд сбрасывается флаг?

[Plexus]

а полингом проверить состояние пина нельзя? Кстати а сумму откуда узнаете или этот девайс сумму импульсами сообщает? Может правильнее этот импульс повесить на таймер, счетчиком, пусть в железе само считается чего на прерывания то реагировать?

Закидываешь 50 руб - 5 импульсов, 100 руб - 10 импульсов, и т.д.
Ширина импульса 50 мс. В обычном состоянии логическая "1". Поэтому настроил прерывание на спад.
Я так понял, можно эти импульсы как-то таймерам продвинутыми считать? Я не смог пример найти.

[adnega]

Если цеплять купюроприемник и в обработчике прерывания инкрементировать каждый импульс (сумму денег), то через некоторое время самопроизвольно отработает обработчик прерывания, и приплюсуется лишняя сумма денег. Как быть?

Либо опросом с защитой от дребезга, либо выбрать купюроприемник с управлением по RS232.
Я импульсы от купюро/монетоприемников делал опросом - там скорость импульсов совсем никакая.
Потом перешли на управление по RS232, ибо 5000 купюра очень на долго парализует аппарат.

кстати про сброс прерывания в самом конце,насколько в конце? Прям последняя команда? Я так понимаю это вариант когда флаг не успевает сброситься до выхода? Сколько команд сбрасывается флаг?

Флаг в периферийном модуле сбрасывается мгновенно, но пока реакция дойдет до NVIC... может не успеть до выхода из прерывания, и NVIC после выхода тут же попадает в прерывание снова.

[Plexus]

Либо опросом с защитой от дребезга, либо выбрать купюроприемник с управлением по RS232.
Я импульсы от купюро/монетоприемников делал опросом - там скорость импульсов совсем никакая.
Потом перешли на управление по RS232, ибо 5000 купюра очень на долго парализует аппарат.

Дребезг исключен - проверяли на осциллографе. А с 5000 купюрой действительно долго )

[adnega]

Дребезг исключен - проверяли на осциллографе. А с 5000 купюрой действительно долго )

Смотря что считать дребезгом...
Если вместо 50мс импульса придет 30 мс?!

Мы в свое время решили так: если контроль ослабить, то будут лишние импульсы - пользователь получает лишние услуги и, естественно, не будет об этом сообщать и тем более оплачивать. Если контроль за импульсами усилить, то некоторые импульсы пропадут - пользователь это заметит и сообщит администратору - администратор решит вопрос. Правда, у нас особенность - музыкальные аппараты в барах и т.п. - т.е. администратор есть, услуга в виде проигрывания песни, т.е. убыток не настоящий. Другое дело платежные терминалы.

[AHTOXA]

Так дело в том, что эта проверка в прерывании и проходит.

Код

if (EXTI_GetITStatus(EXTI_Line0) != RESET)

Самопроизвольно выполняется это условие.

А, вон оно что... Тогда это не spurious. Если дребезг точно исключён, то, скорее всего, не успевает сброситься флаг прерывания до выхода из обработчика.
Вставьте строчку

Код

        __DSB();

после очистки флага прерывания, всё должно пройти.

[adnega]

А мне очень не нравится эта строчка

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

Зачем дергать NVIC (причем не правильно), когда лучше разрешать/запрещать прерывание в периферийном модуле (в данном случае TIM6 или DAC)?
Причем, обязательно сбросить флаг запроса прерывания, если он взведен, иначе тут же улетим в обработчик.

[Golikov A.]

Флаг в периферийном модуле сбрасывается мгновенно, но пока реакция дойдет до NVIC... может не успеть до выхода из прерывания, и NVIC после выхода тут же попадает в прерывание снова.

ну это сено-солома Сколько тактов, нет таких данных? насколько от конца функции надо отодвигать сброс флага?

А если функция как заглушка только и сбрасывает флаг, надо нопов напихать или барьер какой что ли, типа __DSB();?

Закидываешь 50 руб - 5 импульсов, 100 руб - 10 импульсов, и т.д

ну так импульсы надо считать не прерыванием, а таймером. Берете таймер, и эти импулсы заводите как его клок (там есть много режимов, можно выбрать). Делаете счетчик вперед. Если появляются импульсы, таймер считает. Время от времени проверяете что он насчитал, что насчитал запоминаете, таймер сбрасываете. как то так

[adnega]

ну это сено-солома Сколько тактов, нет таких данных? насколько от конца функции надо отодвигать сброс флага?
А если функция как заглушка только и сбрасывает флаг, надо нопов напихать или барьер какой что ли, типа __DSB();?

Ага, барьера хватает.

ну так импульсы надо считать не прерыванием, а таймером. Берете таймер, и эти импулсы заводите как его клок (там есть много режимов, можно выбрать). Делаете счетчик вперед. Если появляются импульсы, таймер считает. Время от времени проверяете что он насчитал, что насчитал запоминаете, таймер сбрасываете. как то так

Вообще не гуд. Лучше уж EXTI. В момент сброса таймера может появиться импульс от купюрника. Проверять нужно периодически -- еще один таймер.
И опять же, это решение, не учитывающее форму импульса и его тайминги. Импульсная помеха легко может добавить сотню-другую денег на счет.

[Plexus]

А, вон оно что... Тогда это не spurious. Если дребезг точно исключён, то, скорее всего, не успевает сброситься флаг прерывания до выхода из обработчика.
Вставьте строчку

Код

        __DSB();

после очистки флага прерывания, всё должно пройти.

Та функция вызывается непроизвольно не сразу после ее правильного вызова, т.е. проходит минут 5 и только после этого вызывается непроизвольно. Неужели флаг не успевает сброситься за 5 минут? )

[Golikov A.]

мне кажется у вас все таки проходит какая - то помеха. Может не нога дергается, а земля к примеру прыгает. Или что-то типа того. В общем думаю если оно стоит стоит и вдруг опа прерывание, то это скорее всего на ноге что-то было, нежели какой-то могучий глюк проца...

Вообще не гуд. Лучше уж EXTI. В момент сброса таймера может появиться импульс от купюрника. Проверять нужно периодически -- еще один таймер.
И опять же, это решение, не учитывающее форму импульса и его тайминги. Импульсная помеха легко может добавить сотню-другую денег на счет.

из существенных только последний аргумент про форму и тайминги. Я бы конечно в таком щекотливом месте CPLD поставил бы, и импульсы уже отдавал в цифровом виде, чтобы быть уверенным что ничего внутри проца не прервало процесс. Хотя вроде как говорилось есть уже приемники с цифровым выходом.

[adnega]

мне кажется у вас все таки проходит какая - то помеха. Может не нога дергается, а земля к примеру прыгает.

Согласен более чем полностью. Землю осциллографа тоже ведь по разному подключить можно...
Насколько я понимаю конструкцию, это (купюроприемник) некий блок, в котором находятся несколько двигателей, несколько излучающих диодов, видеодетекторов, могучий DSP для обработки, а на выходе импульсный сигнал по проводу на несколько десятков сантиметров в окружении другого электрооборудования. Как правило, провод не экранирован и возвратная земля проходит "черт знает где". А если есть GSM-модем внутри, то при обмене
с базовой станцией он может наводить в этот контур приличную помеху. Сюжетов можно придумать много. Я советовал железно замкнуть PA0 на 3.3В и, убедившись, что прерываний не возникает, искать проблемы в схемотехнике.

А резистор подтяжки линии с open drain где установлен? На стороне ключа или на стороне приемника?

[AHTOXA]

Та функция вызывается непроизвольно не сразу после ее правильного вызова, т.е. проходит минут 5 и только после этого вызывается непроизвольно. Неужели флаг не успевает сброситься за 5 минут? )

Не, тогда я согласен с предыдущими ораторами, это стопудово помеха.

[Plexus]

А резистор подтяжки линии с open drain где установлен? На стороне ключа или на стороне приемника?

Резистор со стороны приемника.
Тестирую, как вы и сказали - без купюроприемника, с подтяжкой на выводе PA0 для исключения помех/дребезга со стороны купюроприемника.

[Golikov A.]

1. Есть еще образец платы, вдруг именно на этой какой не пропай в резюке, к примеру. Или у него тепловой шум такой...

2. Проверьте и напишите значения регистров конфигурации, не то что вы функциями делаете, а прям реальное значение этих регистров

3. Уберите все переключения в программе после окончания конфигурации, вы спокойно можете какими-то функциями горе библиотеки от СТМ чего то еще подключать по ходу дела, то есть вызываете для включения 6 таймера, а ставиться может любой бит

4. if (EXTI_GetITStatus(EXTI_Line0) != RESET) - вот это замените пожалуйста на temp_reg = Значение регистра флагов.
if((temp_reg & НУЖНЫЙ_ПИН) != 0)
Потому что внешние прерывание принимает прерывание от 18 источников, 16 из них ноги, а 2 источника это будильник и PVD (че такое кстати ?). Ваша проверка смотрит только на то что было внешние прерывание, но она не смотрит на то какой пин или что его вызывало. Да и вообще полезно для отладки попечатать состояние флагов, мало ли что там как... Кроме прерываний есть же еще и еванты

В общем общие рекомендации при поиски магии, устраните все ее источники в виде дурных библиотек. Работайте напрямую с регистрами проца. Это часто более быстро, и всегда более безопасно и определено!

[KnightIgor]

4. if (EXTI_GetITStatus(EXTI_Line0) != RESET) - вот это замените пожалуйста на temp_reg = Значение регистра флагов.
Потому что внешние прерывание принимает прерывание от 18 источников, 16 из них ноги, а 2 источника это будильник и PVD (че такое кстати ?). Ваша проверка смотрит только на то что было внешние прерывание, но она не смотрит на то какой пин или что его вызывало.

Вот эту тему тоже высказать хотел. Присоединяюсь и настоятельно рекомендую разобраться со всеми ногами, которые обрабатываются _Line0. Это же вроде все типа PA0, PB0, и т.д.? Достаточно какой-то ноге из этой гвардии быть высокоомным входом (что именно и имеет место быть при рестарте процессора), как помехи гарантированы. Посему, влетая в прерывание, читайте еще состояние именно той ножки порта, которая прерывание вызвать должна была.

P.S. не могу удержаться: заголовок темы уж очень медицинские термины напоминает, особенно слово "непроизвольное" и "прерывание". Фантазия пустилась в пляс...

Сообщение отредактировал KnightIgor - Sep 1 2014, 07:19

[AHTOXA]

4. if (EXTI_GetITStatus(EXTI_Line0) != RESET) - вот это замените пожалуйста на temp_reg = Значение регистра флагов.
if((temp_reg & НУЖНЫЙ_ПИН) != 0)
Потому что внешние прерывание принимает прерывание от 18 источников, 16 из них ноги, а 2 источника это будильник и PVD (че такое кстати ?). Ваша проверка смотрит только на то что было внешние прерывание, но она не смотрит на то какой пин или что его вызывало.

Вообще-то смотрит, видите параметр EXTI_Line0 - это как раз оно.

Присоединяюсь и настоятельно рекомендую разобраться со всеми ногами, которые обрабатываются _Line0. Это же вроде все типа PA0, PB0, и т.д.?

Нет. Там в конфигурации задаётся порт для данной ножки. (GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0))

ЗЫ. Эх вы, библиотекофобы Я тоже не пользую SPL, но хоть примерно знаю, как она работает. (Врага надо знать в лицо! )

[adnega]

Таймеры в STM32 очень функциональные. Я бы сделал на таймере:
- по спаду запускаю счет;
- по фронту делаю захват таймера (длительность отрицательного импульса) в CCR1;
- по совпадению с CCR2 (50 мс + например, 5 мс) вызываю прерывание, где анализирую содержимое CCR1.
Если в диапазоне, то прибавляю единичку в счетчике импульсов. Иначе игнорирую.
- останавливаю таймер.

Итого: одно прерывание на импульс, а в регистре длительность этого импульса. Пачка коротких импульсов не вешает систему, т.к. таймер будет пересбрасываться и в окончании пачки сгенерит одно прерывание с некорректной длиной импульса.

[Golikov A.]

мне лень было лезть и смотреть именно эти функции. А по старым моим исканиям, пока не посмотришь что точно функция внутри делает, утверждать что она работает как видится нельзя . Но в целом я не настаиваю, это же не у меня левые прерывания выпрыгивают)

[Plexus]

P.S. не могу удержаться: заголовок темы уж очень медицинские термины напоминает, особенно слово "непроизвольное" и "прерывание". Фантазия пустилась в пляс...

Если честно, я подумывал об этом же, когда писал. Но, спасибо что заметили, поржал на работе в голос... Хорошо, рядом никого не было (:

[KnightIgor]

Нет. Там в конфигурации задаётся порт для данной ножки. (GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0))

Да, да, это я перепутал. Нельзя одновременно использовать в качестве входов для внешних прерываний ножки разных портов того же номера. То есть, PA0 и PB0 не получится использовать одновременно, что накладывает существенные ограничения схемотехнику: если надо несколько внешних прерываний, надо раскидывать их на разные индексы.
И снова автору топика: как говорил один наш доцент, вся дрянь от - источников питания. Где-то шумит масса, видать. Может повесить кондерчик с ноги на массу?

[AHTOXA]

мне лень было лезть и смотреть именно эти функции.

Если вам лень, то зачем отвечать? Вы же вроде помочь хотите, а получается, что запутываете человека.

[Golikov A.]

Да я вроде предложил ему привести что получилось в регистрах после всего сделанного. Даже если оставить функции в покое вроде бы проверить это имеет смысл. Функции функциями, а состояние регистров определяет работу схемы.

Если человек посмотрит в регистрах будет не то что он хотел то значит виноваты функции и их надо изучить
Если человек посмотрит и в регистрах все будет как надо, а прерывание будет, значит виновато железо.

Какой смысл сразу ковырять код, если не понятно где искать?

Думаю хорошим тестом будет как он поймает прерывание которое не видит осциллограф, а он как то умеет это детектировать. Списать состояние всех регистров в этот момент. Состояние флагов, потому я предлагал ему их сохранить, а также все настроечные регистры. Также при входе в прерывание состояние ножки оценивать и сохранять тоже будет не лишним.

И мне до сих пор кажется что я помогаю...

[AHTOXA]

Да я вроде предложил ему привести что получилось в регистрах после всего сделанного. Даже если оставить функции в покое вроде бы проверить это имеет смысл. Функции функциями, а состояние регистров определяет работу схемы.

Вы всерьёз думаете, что ошибка в библиотечных функциях? Причём в функциях конфигурирования, которыми пользуется огромное количество народа?

И мне до сих пор кажется что я помогаю...

Почитайте тред сначала, посчитайте, сколько пурги вы нагнали и окститесь.
Даже если среди ваших предложений и есть здравое зерно, то отыскать его практически невозможно.

[Plexus]

Господа, да вы что в самом то деле?
Для меня любая помощь в радость.
На то и нужен мозговой - кто в какой области силен - железо, прошивка.

Пока сделал костыль - таймером опрашиваю ножку каждые 10 мс. Но выяснить нужно где непорядок. Сегодня начал смотреть регистры.

[ViKo]

А осциллограф-то хороший был? Он может словить короткий всплеск на ножке? А очень короткий?

[Golikov A.]

Вы всерьёз думаете, что ошибка в библиотечных функциях? Причём в функциях конфигурирования, которыми пользуется огромное количество народа?

А вы видели весь код ТС, чтобы быть уверенным что нигде неправильно не вызвана функция?


В целом все свои мысли по этому вопросу сказал, полезны или без покажет время...

[ISF]

Столкнулся с похожей проблемой что и автор топика. Контроллер STM32F100RB на плате STM32VLDISCOVERY.

На плате имеется штатная кнопка USER при нажатии на которую на ножку PA0 подаётся высокий уровень (2.9V - питание контроллера). Ножка PA0 изначально подтянута внешним резистором к общему проводу (к земле). Мне хочется чтобы при нажатии срабатывало прерывание EXTI и светодиод LD3 менял своё состояние на противоположное. Пример как можно видеть простейший и всё работает как и задумано, но есть БОЛЬШАЯ проблема с устойчивостью всей этой системы. При любом касании ножки PA0 металлическим пинцетом или щупом мультиметра происходит прерывание. Ничего подобного на других МК мною раньше не наблюдалось.

Как пробовал бороться:

1. Проверил подтяжку ножки осцилогафом - при касании уровень не меняется (или осцилографф не успевает это зафиксировать). Попробовал подтянуть через резистор меньшего номинала (вплоть до 100 Ом) - НЕ ПОМОГАЕТ
2. Пробовал ставить RC фильтр на ножку (100 Ом 100 нФ) - НЕ ПОМОГАЕТ.
3. Пробовал менять процедуру инициализации ножки и внешнего прерывания. Вместо SPL пробовал инициализацию через прямую запись в регистры - НЕ ПОМОГАЕТ. Также пробовались разные варианты инициализации из разных примеров/форумов/руководств - НЕ ПОМОГАЕТ.
4. Пробовал другие линии EXTI и другие ножки МК - НЕ ПОМОГАЕТ.

Устойчивость достигается только в одном случае - при прямой (без резистора) подтяжке ноги к питанию или земле. Тогда реакции на касания пинцетом нет. Сомнений в качестве разводки платы быть не может. Всё-таки это фирменная плата от STM. Поведение МК абсолютно не поддаётся логике и если честно уже начинают опускаться руки. В процессе поиска решения натыкался на темы форумов где описывались похожие глюки этих МК судя по всему авторам так и не смогли помочь с этим. Вообще какая-то засада...

Схема платы



Код проекта. IDE CooCox 1.7.8

CODE

#include "stm32f10x.h"
#include "stm32f10x_rcc.h"
#include "stm32f10x_gpio.h"
#include "stm32f10x_exti.h"
#include "misc.h"


void EXTI_USER_Button_init()
{
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE);

// Set pin PA0 as input
GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0;
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING;
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOA, &GPIO_InitStructure);

// Tell system that you will use PA0 for EXTI_Line0
GPIO_EXTILineConfig(GPIO_PortSourceGPIOA, GPIO_PinSource0);

EXTI_InitTypeDef EXTI_InitStructure;
// PA0 is connected to EXTI_Line0
EXTI_InitStructure.EXTI_Line = EXTI_Line0;
// Interrupt mode
EXTI_InitStructure.EXTI_Mode = EXTI_Mode_Interrupt;
// Triggers on rising edge
EXTI_InitStructure.EXTI_Trigger = EXTI_Trigger_Rising;
// Enable interrupt
EXTI_InitStructure.EXTI_LineCmd = ENABLE;
// Add to EXTI
EXTI_Init(&EXTI_InitStructure);


// Add IRQ vector to NVIC
NVIC_InitTypeDef NVIC_InitStruct;
// PA0 is connected to EXTI_Line1, which has EXTI0_IRQn vector
NVIC_InitStruct.NVIC_IRQChannel = EXTI0_IRQn;
// Set priority
NVIC_InitStruct.NVIC_IRQChannelPreemptionPriority = 0x00;
// Set sub priority
NVIC_InitStruct.NVIC_IRQChannelSubPriority = 0x00;
// Enable interrupt
NVIC_InitStruct.NVIC_IRQChannelCmd = ENABLE;
// Add to NVIC
NVIC_Init(&NVIC_InitStruct);
}

int main(void)
{
// Инициализируем светодиоды LD3 и LD4
RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);

GPIO_InitTypeDef GPIO_InitStructure;
GPIO_InitStructure.GPIO_Pin = GPIO_Pin_8 | GPIO_Pin_9; // PC8 - LD4, PC9 - LD3
GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; // Set pin PC8 and PC9 as output
GPIO_InitStructure.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOC, &GPIO_InitStructure);

GPIO_SetBits(GPIOC,GPIO_Pin_9);
GPIO_SetBits(GPIOC,GPIO_Pin_8);

EXTI_USER_Button_init();

while(1)
{
//
}
}

void EXTI0_IRQHandler(void)
{
if(EXTI_GetITStatus(EXTI_Line0) != RESET) // Judge whether a line break
{
GPIOC->ODR ^= GPIO_Pin_9;
for(uint32_t i = 0; i < 500000; i++); // Simple delay
}
EXTI_ClearITPendingBit(EXTI_Line0); // Remove LINE interrupt flag bit
}

Сообщение отредактировал IgorKossak - May 9 2017, 10:07

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

[scifi]

Мне хочется чтобы при нажатии срабатывало прерывание EXTI и светодиод LD3 менял своё состояние на противоположное. Пример как можно видеть простейший и всё работает как и задумано, но есть БОЛЬШАЯ проблема с устойчивостью всей этой системы.

Вы в курсе, что есть такая штука, как дребезг металлического контакта? Самый простой способ бороться с ним - не опрашивать состояние кнопки после его изменения в течение 50-100 мс. Это автоматически реализуется, если состояние кнопки опрашивается с периодом 50-100 мс. Если вам так нравится прерывание, можно запрещать прерывание на это время, используя таймер и его прерывание, но это просто лишний геморрой.

[ISF]

Вы в курсе, что есть такая штука, как дребезг металлического контакта? Самый простой способ бороться с ним - не опрашивать состояние кнопки после его изменения в течение 50-100 мс. Это автоматически реализуется, если состояние кнопки опрашивается с периодом 50-100 мс. Если вам так нравится прерывание, можно запрещать прерывание на это время, используя таймер и его прерывание, но это просто лишний геморрой.

Про дребезг контактов и методы борьбы с ним мне известно, но то что я описываю это не дребезг. Прерывание срабатывает именно от касания (не замыкание на на что либо!) вывода МК любым металлическим предметом (палец такого эффекта не даёт). При этом не спасает даже подтяжка вывода к питанию или земле через резистор. Программно в обработчике прерывания удалось отследить что это всё-таки не случайность, а кратковременное изменение уровня на ножке при касании проводящим предметом. Удивляет поразительная чувствительность STM32 к такому. Тот же AVR на такое никогда не реагировал. И как в таком случае мерить потенциал на ножке если любое касание её даже щупом тестера вызывает подобные эффекты?

Сообщение отредактировал ISF - May 9 2017, 12:09

[Baser]

При любом касании ножки PA0 металлическим пинцетом или щупом мультиметра происходит прерывание. Ничего подобного на других МК мною раньше не наблюдалось.
....
Тот же AVR на такое никогда не реагировал. И как в таком случае мерить потенциал на ножке если любое касание её даже щупом тестера вызывает подобные эффекты?

Удивительные вещи вы пишете, в том плане, что такого раньше не наблюдали.
А я вот обратного никогда не наблюдал.

Если коснуться металлическим пинцетом (если он еще и не изолированный, и в руке, то еще похлеще будет) высокоомной ножки МК, там помеха будет в десятки вольт. Ограничена будет только входными защитными диодами МК. И на осциллографе это тоже прекрасно видно.

Тестером измерять можно, но помеху при касании никто не отменит и прерывание все равно произойдет.

Вы бы еще начали касаться контактов кварцевого генератора и удивляться, что программа улетает неизвестно куда...

[rudy_b]

Вы все про высокое, а причина может быть намного проще - и в SPL и в HAL до сих пор есть элементарная ошибка - при совместном использовании ног порта могут менятся "не свои" пины. Например функция установки бита может быть прописана как GPIOx->ODR |= 0b0001000... т.е. последовательность - чтение, модификация, запись. Если при этом будет прерывание и в нем будет изменен другой бит - произойдет ошибка - восстановится его старое значение. Для предотвращения этого нужно использовать либо запрет прерываний, либо специальный регистр BSRR, сделанный специально для того, чтобы сделать операции установки/сброса бит атомарными.

В последних версиях SPL и HAL установка и сброс бита уже сделаны правильно (через BSRR), а вот операция toggle - по прежнему GPIOx->ODR ^= ...

Проверьте весь код на наличие работы с отдельными битами GPIO не через BSRR.

Понятно, что EXTI работает не с ODR, а с IDR, но точной реализации харда GPIO нет, так что стоит проверить, мало-ли что.

[ISF]

Удивительные вещи вы пишете, в том плане, что такого раньше не наблюдали.
А я вот обратного никогда не наблюдал.

Если коснуться металлическим пинцетом (если он еще и не изолированный, и в руке, то еще похлеще будет) высокоомной ножки МК, там помеха будет в десятки вольт. Ограничена будет только входными защитными диодами МК. И на осциллографе это тоже прекрасно видно.

Тестером измерять можно, но помеху при касании никто не отменит и прерывание все равно произойдет.

Вы бы еще начали касаться контактов кварцевого генератора и удивляться, что программа улетает неизвестно куда...

Почему же тогда на моей отладочной плате с ATmega16A подобных приколов с прерываниями нет и в помине. Касаюсь я щупом или пинцетом или нет всё работает устойчиво и чётко. К тому же я уже раз 5 повторил что ножка никакая не высокоомная - она ПОДЯТНУТА к питанию или земле через резистор. При поиске решения я испытывал даже 100 Ом в качестве подтягивающего резистора и эффект ничуть меньше не становился.

К тому же я уже писал что подобную проблему на STM32 наблюдали и раньше, но тогда всё списали на плохую разводку и на этом всё и заглохло

http://forum.easyelectronics.ru/viewtopic....76&start=50

Крутаните до 3 страницы (последнее сообщение) - там человек описывает ровно туже проблему

Вы все про высокое, а причина может быть намного проще - и в SPL и в HAL до сих пор есть элементарная ошибка - при совместном использовании ног порта могут менятся "не свои" пины. Например функция установки бита может быть прописана как GPIOx->ODR |= 0b0001000... т.е. последовательность - чтение, модификация, запись. Если при этом будет прерывание и в нем будет изменен другой бит - произойдет ошибка - восстановится его старое значение. Для предотвращения этого нужно использовать либо запрет прерываний, либо специальный регистр BSRR, сделанный специально для того, чтобы сделать операции установки/сброса бит атомарными.

В последних версиях SPL и HAL установка и сброс бита уже сделаны правильно (через BSRR), а вот операция toggle - по прежнему GPIOx->ODR ^= ...

Проверьте весь код на наличие работы с отдельными битами GPIO не через BSRR.

Понятно, что EXTI работает не с ODR, а с IDR, но точной реализации харда GPIO нет, так что стоит проверить, мало-ли что.

Спасибо за совет. Нужно будет внимательно проверить. Версия CooCox у меня далеко не новая. Возможно библиотеки действительно с багами. Хотя я пробовал инициализацию через прямой доступ к регистрам и это не дало положительного результата..

Сообщение отредактировал ISF - May 9 2017, 13:15

[amiller]

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

[ISF]

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

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

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

[Baser]

К тому же я уже писал что подобную проблему на STM32 наблюдали и раньше, но тогда всё списали на плохую разводку и на этом всё и заглохло
...
Крутаните до 3 страницы (последнее сообщение) - там человек описывает ровно туже проблему

Просмотрел по диагонали предыдущие страницы - не обнаружил той же проблемы. Человек жаловался на самопроизвольное возникновение прерываний. В его случае причин может быть много, о чем и была дельная дискуссия.

В вашем же случае, вы сами касаетесь пинцетом ножки и удивляетесь, почему возникает прерывание. Это же тест на электростатический разряд "Human Body Model" (HBM), там киловольты могут быть. Не выбивает ножку МК - и хорошо, производитель ничего больше и не обещал.

Почему же тогда на моей отладочной плате с ATmega16A подобных приколов с прерываниями нет и в помине. Касаюсь я щупом или пинцетом или нет всё работает устойчиво и чётко.

возможно:
- питание 5В
- частота низкая, аппаратная выборка ножки редкая + аппаратный фильтр
- была программная обработка дребезга в прерывании, когда в прерывание попадаете, но действия не происходит из-за фильтрации
- какие-нибудь еще нюансы забыли, как все делали...

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

"полностью обвязанный и прикрытый от всех случайностей вывод" - это когда вы касаетесь пинцетом перед защитой, где кнопка подключена.
Когда вы касаетесь прямо на ножку, защита тут не причем, получаете тест ESD

[amiller]

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

Почему то мне кажется, что во время экспериментов плата у Вас не заземлена, а на запястье нет браслета для снятия статики.
А значит в момент касания Вы подключаете к выводу микросхемы конденсатор на несколько десятков пикофарад, заряженный до нескольких киловольт.
Это эквивалент Вашего тела в достаточно сухом воздухе, если что.
А далее получается емкостной делитель, где ток разряда Вашей емкости заряжает емкость на входе. И вполне может быть, что эквивалентное напряжение на входе превысит логический уровень. А если бы это был просто висячий вход, то таким образом легко его убить.
Недаром всех монтажников заставляют браслеты одевать и работать заземленным инструментом.
Бывает, что у некоторых процессоров есть система внутренней синхронизации, которая не пропускает наносекундные (иногда и микросекундные) импульсы.
Видимо в STM такого нет. Это не значит, что процессоры плохие. Просто Вы использовать пытаетесь их не совсем правильно.

[ViKo]

А попробовать одной рукой взяться за плату, за цепь земли, а другой пинцетом в кнопку тыкать. Сработает?

[ISF]

А попробовать одной рукой взяться за плату, за цепь земли, а другой пинцетом в кнопку тыкать. Сработает?

Попробовал, всё равно срабатывает, но ощутимо реже чем раньше

Сообщение отредактировал ISF - May 9 2017, 19:38

[ViKo]

У вас там электромагнитная аномалия! А в другом месте если попробовать?

[Forger]

А в другом месте если попробовать?

Я бы еще посоветовал до кучи погасить свет в помещении. В данном случае и фотоны будут виноваты

[jcxz]

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

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

[Forger]

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

[jcxz]

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

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

[Forger]

Нынче существуют 5V армы. Они по-идее должны пройти подобный "тест на ложные прерывания", например, при касании правым мезинцем левой ноги

[ISF]

Был задан вполне конкретный вопрос - какого чёрта МК улетает в прерывания от любого чиха и как бороться с таким поведением. Вопрос не праздный. На любом промышленном изделии порой требуются ремонтные действия и будет мало приятного если при банальном замере напряжения у МК будет сносить крышу напрочь. Если есть что сказать по делу, то стоит это сделать, а шутки тут как-то не особо к месту. Всё-таки не КВН

[Forger]

Был задан вполне конкретный вопрос - какого чёрта МК улетает в прерывания от любого чиха и как бороться с таким поведением.

Сначала следует разобраться с "поведением" того, кто собраться сувать руки в работающее изделие
Во-вторых, изделие нужно засунуть в корпус и поставить плобму, чтобы кто-попало туда не лазил без ведома разработчика.
А, если сам разработчик допускает подобные копания в потрохах изделия с подключенным питанием, то виноват горе-разработчик,
а вовсе не контора, которая делает микросхемы, используемые в его чудо-устройстве.

Вопрос не праздный.

Вам уже тут ответили по существу, сославшись на выдержки из даташита на МК.
И про обработку нажатий кнопок по прерываниям (дикость какая) тоже подсказали, что это делается это совсем иначе - нужно бороться с дребезгом и слишком короткими "пысиками" программно.
А также рассказали почему в вашем любимом AVR это не происходит, а тут - это возможно.
Короче, вам "разжевали все по косточам". Доходчиво. Даже местами слишком.

На любом промышленном изделии порой требуются ремонтные действия и будет мало приятного если при банальном замере напряжения у МК будет сносить крышу напрочь.

На любом промышленном изделии перед копанием внутри сначала принято отключать питание и в обязательном порядке заземлять туловище любопытного электрика.
Хотя, лучше всего от таких электриков помогает корпус с гарантийной пломбой.

шутки тут как-то не особо к месту

Ну да действительно! Как же я не подумал об этом! Ведь у вас траур - STM32 вывел на чистую воду, все то, что AVR упорно скрывал. Искренне сочувствую

[adnega]

какого чёрта МК улетает в прерывания от любого чиха и как бороться с таким поведением. Вопрос не праздный.

Перед разработкой промышленного оборудования неплохо бы чуть-чуть подучиться.
Есть очень хорошая статья. Советую ознакомиться.
На STM32 нападения напрасны - если схемотехника в порядке, то оборудование может работать
в очень тяжелых условиях. У STM есть множество AN на данную тему, а у потребителей продукции STM
есть множество реализованных серийных надежных изделий.

Вам конкретно ответили: есть программные и есть аппаратные способы борьбы. Нужно использовать все.
Виноват не контроллер, а разработчик. Могу рассказать историю, как светодиодные табло зависали
намертво, когда рядом в сеть вставляли обычный нихромовый паяльник, при этом собраны они были на atmega128.

[jcxz]

На любом промышленном изделии порой требуются ремонтные действия и будет мало приятного если при банальном замере напряжения у МК будет сносить крышу напрочь.

А ещё подумайте что будет, когда при "банальном замере напряжения" на этих шаловливых ручках будет статический заряд в несколько кВ. Тоже будете винить микроконтроллер, что он "вдруг гад сдох"?

[ViKo]

Если топикстартер выложит hex-код программы, любой желающий сможет запрограммировать свою Дискавери и проверить. Мне тоже кажется это ненормальным поведением, особенно с подтяжками по 100 Ом.

[jcxz]

Если топикстартер выложит hex-код программы, любой желающий сможет запрограммировать свою Дискавери и проверить. Мне тоже кажется это ненормальным поведением, особенно с подтяжками по 100 Ом.

Ну да, и у этого "желающего" не проявится. И что?
А всё потому что пол в помещении не накапливает статику или нет люминесцентных ламп, дающих наводку на всё вокруг или ещё тысяча других причин.

[adnega]

Мне тоже кажется это ненормальным поведением, особенно с подтяжками по 100 Ом.

Вместо hex нужно выложить отмоделированную схему - будет виден фронт, на который EXTI должен отреагировать.
В сложных случаях может быть все что угодно. У меня макет одного устройства реагировал на касание острым(!)
предметом земляного полигона, а не пина.

[Сергей Борщ]

Мне тоже кажется это ненормальным поведением, особенно с подтяжками по 100 Ом.

ST-link v2 теряет связь при касании пинцетом соединенного с землей металлического корпуса устройства. Я уже привык.

[Forger]

ST-link v2 теряет связь при касании пинцетом соединенного с землей металлического корпуса устройства. Я уже привык.

А я заказал на пробу вот такую штуку для отвязки отладчика.

[ViKo]

Есть ST-Link/V2-Isol
http://www.st.com/content/st_com/en/produc...st-link-v2.html