Форум разработчиков электроники ELECTRONIX.ru > Сломал мозг! STM32F107VCT6, прерывание, USART2

Sergey Abaev

Dec 15 2017, 09:46

Есть программка для выявления проблемы.

Простое usart эхо, принимает байты - срабатывает прерывание и отправляет hello назад.

Сам код может быть странный, но суть не в этом. Выдернули из большого.

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

и срабатывает строка "if(HAL_UART_Receive_IT(&huart1, &rcv, 1)!=HAL_OK)"

Как быть? В чем проблема?

Сразу для ответов "гугли", "читай RM" и прочих ... проходим мимо!

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

Код

....
UART_HandleTypeDef huart1;
....
char rcv;
volatile int rcvd;
....
....
int main(void)
{
...
  MX_USART1_UART_Init();
...
  while (1)
  {
        if(rcvd)
        {
            HAL_GPIO_WritePin(Led_GPIO_Port, Led_Pin, GPIO_PIN_SET);
            rcvd = 0;
            HAL_UART_Transmit(&huart1, "Hello!\r\n", 8, 0xFFFF);
            HAL_GPIO_WritePin(Led_GPIO_Port, Led_Pin, GPIO_PIN_RESET);
        }
  }
}

....
....
....
void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart)
{
    if(huart == &huart1)
    {
        if(rcv == '\n') rcvd = 1;

        if(HAL_UART_Receive_IT(&huart1, &rcv, 1)!=HAL_OK)
        {
            HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_0);
        }
    }
}
...
...
...

ViKo

Dec 15 2017, 10:09

Цитата(Sergey Abaev @ Dec 15 2017, 12:46)

Как быть? Может, что-то не хватает?

Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого".

Sergey Abaev

Dec 15 2017, 10:12

Цитата(ViKo @ Dec 15 2017, 13:09)

Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого".

Ну такие ответы от умников я тоже ожидал. Проходите мимо!

x893

Dec 15 2017, 11:42

Нет понимания работы.
Надо смотреть, что происходит при вызовах HAL_...

Переставьте выше
HAL_GPIO_TogglePin(GPIOE, GPIO_PIN_0);
на прием каждого байта и убедитесь, что PE0 дергается при приеме каждого байта.
Ну а дальше нужно логически промоделировать работу процессора и прерываний.

HAL содержит больше бессмысленных операций, поэтому это один путь.
SPL содержит меньше ненужного кода, но нужно больше мозга для использования.
CMSIS минимальное кол-во кода, но мозга ещё больше надо + умение читать RM

adnega

Dec 15 2017, 17:47

Цитата(Sergey Abaev @ Dec 15 2017, 12:46)

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

Поможет обработка переполнения приемника. Если произойдет переполнение приемника, а соответствующих флаг вы не сбросите,
то будете постоянно находится в прерывании приемника. Подробности в RM.

x893

Dec 15 2017, 18:04

Можно добавить HAL_UART_ErrorCallback и там отслеживать ошибки мастерства программирования.

sadat

Dec 15 2017, 18:27

Ну и кто за вас будет сбрасывать всякие ошибки приёма?
Полностью уверен в том, что устанавливается бит ошибки приёмника (а их там несколько) - вот всё и "тухнет".

x893

Dec 15 2017, 18:48

HAL их сбрасывает за меня (и за остальных тоже).
Полностью можно быть уверенным после просмотра кода.

pvman

Dec 15 2017, 19:11

когда "виснет", смотреть состояние флагов usart.
в обработке прерывания проще убрать обработку через HAL, это будет значительно читабельнее и в сотни раз короче и быстрее.
в даташите на пальцах всё расписано, сделать несколько обязательных строчек и всё.

x893

Dec 15 2017, 19:16

Так написал же Sergey Abaev, что он не читает RM.
Пусть код индусский изучает.
Видимо и примеры ему тоже смотреть лень.
Сразу в бой с HAL_... - как Чапаев на белом коне.

vlad_new

Dec 17 2017, 09:36

Можно попробовать в прерывании, перед выходом, поставить что то типа сброса всех флагов и ошибок напрямую в регистрах уарта. Скорее всего, как уже было замечено, какой то флаг вам не дает выйти из прерывания ( вернее вы туда тут же влетаете ). Ну или анализируйте, на сколько корректно HAL всё это делает за вас

leocat

Dec 17 2017, 19:31

Это с какой же частотой UART "бомбить" нужно, чтобы "заклинило". Не знаю, не знаю... У меня 1 мбит/сек на прерываниях ничего не теряет.
Ну и правильно написали: HAL - в топку. Это индусское изделие еще тот гемор.
Ну и если прерывание уже в обработке (для UART например), то повторно его не вызовете. Флаг сбрасывать нужно, ручками. Мало того, если по выходу из прерывания его (флаг) не сбросить ( USART_ClearITPendingBit( USART1, USART_IT_RXNE ); ), то повторно и не сработает.
( пример из SPL )

juvf

Dec 18 2017, 07:20

Цитата(Sergey Abaev @ Dec 15 2017, 14:46)

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

Вставал на подобную граблю. Не знаю, может вам это поможет.... St сделали ~~багу~~ закладку, чтоб не всё так сладко было, и оформили её как фичу, имхо. Суть в том, что прерывание RXNEIE срабатывает не только когда RXNE==1, но и ИЛИ когда ORE==1. У меня было так, что один раз когда нибудь встанет флаг ORE, и я зависал навечно в прерывании RXNEIE. Вы в одном обработчике должны проверять оба флага и делать соответствующее ветвление, ну и соответственно сбрасывать флаг ORE.

rakpavel

Dec 18 2017, 10:15

да, флаг USART_FLAG_ORE -указывает на ошибку переполнения, как раз похоже на случай ТС.

Sergey Abaev

Dec 18 2017, 17:31

Народ!!!! спасибо всем, кто подсказал. Проблему понял и решил.

Наверно это одна из тупейших тем, но сорри. На то он и форум. Еще раз спасибо за помощь и советы!

Тема закрыта.

Цитата(x893 @ Dec 15 2017, 22:16)

Так написал же Sergey Abaev, что он не читает RM.
Пусть код индусский изучает.
Видимо и примеры ему тоже смотреть лень.
Сразу в бой с HAL_... - как Чапаев на белом коне.

Это вы зря! Примеров перелопатил много! Просто не понятно, почему так просто можно "подвесить" МК.

Я уже разобрался конечно.

Цитата(adnega @ Dec 15 2017, 20:47)

Поможет обработка переполнения приемника. Если произойдет переполнение приемника, а соответствующих флаг вы не сбросите,
то будете постоянно находится в прерывании приемника. Подробности в RM.

СПАСИБО!!! Посмотрю RM

Цитата(x893 @ Dec 15 2017, 21:04)

Можно добавить HAL_UART_ErrorCallback и там отслеживать ошибки мастерства программирования.

Вот это не знал!!!! Что-то не подумал над этим, а действительно!

Спасибо!!

Цитата(sadat @ Dec 15 2017, 21:27)

Ну и кто за вас будет сбрасывать всякие ошибки приёма?
Полностью уверен в том, что устанавливается бит ошибки приёмника (а их там несколько) - вот всё и "тухнет".

Виноват - я болван

Цитата(ViKo @ Dec 15 2017, 13:09)

Не хватает воли плюнуть на HAL, изучить Reference Manual и написать простую программу самостоятельно, не выдергивая из "большого".

Частично конечно согласен, но форум и знающие люди быстрее направят, а иначе зачем форум. Это конечно не говорит, что я вылез из пещеры и сразу в бой. Но и книги + форум = лучше

Цитата(x893 @ Dec 15 2017, 21:48)

HAL их сбрасывает за меня (и за остальных тоже).
Полностью можно быть уверенным после просмотра кода.

Да я делал проект через куб, и добавил только, что выше. Просто удивляет, почему так просто можно "подвесить" МК. Но уже все понял! Спасибо!

Цитата(pvman @ Dec 15 2017, 22:11)

когда "виснет", смотреть состояние флагов usart.
в обработке прерывания проще убрать обработку через HAL, это будет значительно читабельнее и в сотни раз короче и быстрее.
в даташите на пальцах всё расписано, сделать несколько обязательных строчек и всё.

Век живи, век учись! Спасибо, учтем!

Цитата(vlad_new @ Dec 17 2017, 12:36)

Можно попробовать в прерывании, перед выходом, поставить что то типа сброса всех флагов и ошибок напрямую в регистрах уарта. Скорее всего, как уже было замечено, какой то флаг вам не дает выйти из прерывания ( вернее вы туда тут же влетаете ). Ну или анализируйте, на сколько корректно HAL всё это делает за вас

СПАСИБО!!!!!

Цитата(leocat @ Dec 17 2017, 22:31)

Это с какой же частотой UART "бомбить" нужно, чтобы "заклинило". Не знаю, не знаю... У меня 1 мбит/сек на прерываниях ничего не теряет.
Ну и правильно написали: HAL - в топку. Это индусское изделие еще тот гемор.
Ну и если прерывание уже в обработке (для UART например), то повторно его не вызовете. Флаг сбрасывать нужно, ручками. Мало того, если по выходу из прерывания его (флаг) не сбросить ( USART_ClearITPendingBit( USART1, USART_IT_RXNE ); ), то повторно и не сработает.
( пример из SPL )

115200, где-то получалось около 720 байт в сек. Наверно это немного.

Но как я понял, принимает он без проблем, всё успевает. А вот назад, в сторону компа - затыкается. И видимо я не ждал окончания отправки. И как-то все висло!

Цитата(juvf @ Dec 18 2017, 10:20)

Вставал на подобную граблю. Не знаю, может вам это поможет.... St сделали ~~багу~~ закладку, чтоб не всё так сладко было, и оформили её как фичу, имхо. Суть в том, что прерывание RXNEIE срабатывает не только когда RXNE==1, но и ИЛИ когда ORE==1. У меня было так, что один раз когда нибудь встанет флаг ORE, и я зависал навечно в прерывании RXNEIE. Вы в одном обработчике должны проверять оба флага и делать соответствующее ветвление, ну и соответственно сбрасывать флаг ORE.

Спасибо, проверю!!!

Цитата(rakpavel @ Dec 18 2017, 13:15)

да, флаг USART_FLAG_ORE -указывает на ошибку переполнения, как раз похоже на случай ТС.

Спасибо! Спасибо!

ViKo

Dec 18 2017, 18:41

Так в чем ошибка была?