Plexus 0 29 августа, 2014 Опубликовано 29 августа, 2014 (изменено) · Жалоба Требуется помошь в поиске проблемы. Непроизвольно срабатывает прерывание EXTI0_IRQHandler(). Нога подтянута к 3.3В резистором. И на нее подается импульс. Прерывание должно срабатывать по спаду. И срабатывает. Но время от времени, в обработчик залетает и выполняется проверка на EXTI_GetITStatus(EXTI_Line0). Импульсы в этот момент не поступают (слежу на осцилле). Что за магия такая? 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); } } } Изменено 29 августа, 2014 пользователем IgorKossak [codebox] для длинного кода, [code] - для короткого!!! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Ant_m 0 29 августа, 2014 Опубликовано 29 августа, 2014 · Жалоба Импульсы в этот момент не поступают (слежу на осцилле). А на GPIO 0 port B, С, D что происходит? У меня все нормально работает, только у меня нет работы с TIM6 и приоритеты стоят не 0x0f, а 3... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plexus 0 29 августа, 2014 Опубликовано 29 августа, 2014 · Жалоба А на 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 0 29 августа, 2014 Опубликовано 29 августа, 2014 · Жалоба это ваще может значить черти что, куча народу нарывалось на то что эти дурные функции делали что хотели а не что надо. там через раз срабатывает вот это GPIO_Pin_8 | GPIO_Pin_9; иногда биты настройки одного пина и второго находятся в разных регистрах и в этом случае такое вызывает ваще непредсказуемые результаты. надо проверить состояние регистров, как они настроились. А лучше настроить их ручками Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plexus 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба Т.е. достаточно настроить все GPIO и проблема пропадет? Кто еще сталкивался с этой проблемой? Если есть ссылки на топики - поделитесь, пожалуйста. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба где то краем ухо я слышал про ложные срабатывания прерываний, этим грешили процы от ST, вот типа http://electronix.ru/forum/index.php?showt...%E2%E0%ED%E8%E5 и в других контекстах слышал. эта тема про UART, про пины вроде тоже проходило где то... Другое дело что надо сначала все верно настроить, чтобы в регистрах было то что надо, а не дергая странные индуские функции. Многие из них очень плохо написаны. И только потом уже верить в ложное срабатывание. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба где то краем ухо я слышал про ложные срабатывания прерываний, этим грешили процы от ST, Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plexus 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST. Хорошо. А этого можно как-то избежать? Это лечится? Как другие разработчики решали подобные проблемы? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба Хорошо. А этого можно как-то избежать? Это лечится? Как другие разработчики решали подобные проблемы? Это не ваш случай. Попробуйте ногу посадить железно на 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 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба Это не ваш случай. Попробуйте ногу посадить железно на 3.3В. Попробуйте настроить EXTI на другой вывод. Если и в этом случае будут вызовы, то ищем в одном месте, если пропадут, то в другом, например, в ES Кста, уSTM32VLDiscovery на PA0 сидит кнопка. Если вы имеете дребезг по нажатию/отпусканию кнопки, то это третий случай. Зачем сажать на 3.3В? У меня и так подтяжка железно через резистор на 3.3В, а не программно. Что вы имеете в виду? Буду на другом выводе юзать, но я должен быть уверен, что все работает как часы. А ждать самопроизвольного срабатывания - очень долго. Не всегда ж срабатывает. Дребезг исключен 100%. Проверка и на осцилле была и физически дребезг исключен. Подключение через транзистор на землю. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание. Если это правда беда кортекса-М, но что-то тьфу тьфу тьфу на лпц не замечал такого.... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AHTOXA 14 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба Правильнее называть те прерывания "повторными". Это, скорее, грех Cortex-M, чем ST. Не, spurious - это как раз "ложные". Они не обязательно повторные, просто прерывание без причины. самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание. Вот именно. но что-то тьфу тьфу тьфу на лпц не замечал такого.... Гы. AN10414 Handling of spurious interrupts in the LPC2000 :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Golikov 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба ну он же не кортекс-м... Можно в 2 словах откуда они рождаются? Я как то не искушен в этом вопросе, думал это чисто СТ косяк, а выходит все же нет, че почитать? UPD. А нашел, в приведенном же документе есть причина их возникновения. Но что-то получается что это не для любой периферии возможно и причина в конвейере, то есть фактически на самом деле прерывание было, просто пока конвейер чистился оно исчезло. Но такое не возможно для GPIO прерываний, или возможно? Как оно все рождается то? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 10 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба ну он же не кортекс-м... Согласен. У кортексов и контроллер прерываний совсем другой. Про ложные срабатывания (даже на STM32) ничего не слышал за более чем 4 года использования в серийном производстве (~ 100 изделий в месяц) на STM32F100/103/107/407. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Plexus 0 30 августа, 2014 Опубликовано 30 августа, 2014 · Жалоба самое правильное, при прерывании проверять флаг, что именно от этой ноги все получилось, иначе игнорировать прерывание. Если это правда беда кортекса-М, но что-то тьфу тьфу тьфу на лпц не замечал такого.... А какой именно флаг проверять? Разве в моем коде обработчик не полный? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться