Перейти к содержанию
    

Неполадки с очередью в USART

15 hours ago, amaora said:

которые впрочем не затрагивали ничего важного, только удалял ненужное

А что в ней есть ненужное? Многие сервисы ОС отключаются легально с помощь FreeRTOSConfig.h.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Чего-то я не понимаю, почему здесь дискуссия в форме гадания на кофейной гуще: влетает в обработчик или не влетает определяем светодиодами:wink:

 

1. Другие задачи работают или устройство намертво зависает?

2. А можно отладчиком наконец подцепиться, запуститься и поймать эту ситуацию, если п. 1 подразумевает полное зависание всех задач и устройства в целом?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Отсутствие отладчика не освобождает от ответственности за ошибки в коде.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

46 минут назад, x893 сказал:

Отсутствие отладчика не освобождает от ответственности за ошибки в коде.

Это, разумеется, да, но с ним было бы быстрее эту ошибку локализовать. В конце концов окажется, что, например, редкое прерывание, будучи настроенным в недопустимый для сервисов RTOS приоритет, вызывает xSemaphoreGiveFromISR() и вешает все процессы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, Arlleex said:

недопустимый для сервисов RTOS приоритет, вызывает xSemaphoreGiveFromISR() и вешает все процессы

Нет, в этом случае будет вызван configASSERT в соответствующем файле. Там таже комментарий есть, почему система оказалась в этом месте. У меня такое много раз было. Вообще FreeRTOS довольно хорошо оснащена диагностическимы выводами. Их только включить нужно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, haker_fox сказал:

Нет, в этом случае будет вызван configASSERT в соответствующем файле. Там таже комментарий есть, почему система оказалась в этом месте. У меня такое много раз было. Вообще FreeRTOS довольно хорошо оснащена диагностическимы выводами. Их только включить нужно.

Ключевой момент "их только включить нужно":smile:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 minutes ago, Arlleex said:

"их только включить нужно"

Я написал "диагностические выводы". Имел в виду вывод в консоль. FreeRTOS же не может знать, как сделать вывод на конкретной системе. Через какой порт хотя бы. Может быть консоль на ethernet'е вообще висит))) Однако, если макрос configASSERT не определён, то работает макрос по-умолчанию, который просто стопорит систему. Тогда нужно остановиться отладчиком, и посмотреть, где зависло.

Однако в руководстве по запуску системы (где-то на сайте) написано, что все эти фишечки включить нужно. У меня, например, они включены всегда. Даже в релизных проектах. И пишут всё на диск в случае ошибки. Зато потом, просмотрев служебный журнал ошибок, можно отметить где и что сбойнуло.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 минуту назад, haker_fox сказал:

Я написал "диагностические выводы". Имел в виду вывод в консоль. FreeRTOS же не может знать, как сделать вывод на конкретной системе. Через какой порт хотя бы. Может быть консоль на ethernet'е вообще висит))) Однако, если макрос configASSERT не определён, то работает макрос по-умолчанию, который просто стопорит систему. Тогда нужно остановиться отладчиком, и посмотреть, где зависло.

Так я про то и говорю - отладчиком глянуть не мешало бы...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да, согласен, посмотреть стек повисшей задачи интересно. Но пока с этим есть проблемы, отладчик отказывается работать с имеющимся экземпляром устройства. Есть еще трудности с тем чтобы безопасно остановить всю систему (просто так сделать break нельзя), но они преодолимы. Сейчас известно что:

1) Задача которая интенсивно вызывает putc() и переполняет очередь, иногда повисает на вызове xQueueSendToBack;

2) Прерывание USART с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY после этого не вызывается;

3) Прерывание ADC с приоритетом выше configMAX_SYSCALL_INTERRUPT_PRIORITY работает независимо от этого происшествия;

4) Работают ли другие задачи после этого не знаю, не проверял;

5) Проявляется только с -O3 -flto;

6) В коде FreeRTOS v9.0.0 есть правки, выше говорил какие;

7) Обновление на v10.2.0 приводит к исчезновению проблемы (при аналогичных правках);

8) configASSERT задан и выводит сообщение в тот же USART только более примитивным методом с ожиданием в цикле;

9) Обработчики исключений тоже заданы, когда я в них попадал это было видно;

 

Кстати, мне не очень понятно, почему сборку с LTO не исправляют в новых версиях. Почему я сам это все правлю. Увидел вот там одно изменение в port.c,

@@ -388,7 +381,10 @@
        /* Should never get here as the tasks will now be executing!  Call the task
        exit error function to prevent compiler warnings about a static function
        not being called in the case that the application writer overrides this
-       functionality by defining configTASK_RETURN_ADDRESS. */
+       functionality by defining configTASK_RETURN_ADDRESS.  Call
+       vTaskSwitchContext() so link time optimisation does not remove the
+       symbol. */
+       vTaskSwitchContext();
        prvTaskExitError();

Но это не помогает, и я вынужден добавлять __attribute__ (( used )). И другие проблемы есть, из-за которых я правлю асм-вставки.

 

Изменено пользователем amaora

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

А для вывода использовать RTT, который в 100500 раз быстрее USART

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

15 minutes ago, amaora said:

Прерывание USART с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY после этого не вызывается;

Все обработчики, использующие сервисы ОС должны иметь приоритет выше или равный configMAX_SYSCALL_INTERRUPT_PRIORITY. При обращении к сервисам они используют функции, оканчивающиеся на FromISR. Те обработчики, которые не используют сервисы ОС, могут иметь любые приоритеты. Я надеюсь у вас так?)))

18 minutes ago, amaora said:

Обработчики исключений тоже заданы, когда я в них попадал это было видно;

Ну тогда нужно только отладчик каким-то образом дружить с вашей системой.

А стеки у вас достаточной глубины? Может быть увеличить принудительно раза в два...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, haker_fox said:

А что в ней есть ненужное? Многие сервисы ОС отключаются легально с помощь FreeRTOSConfig.h. 

Если оно вынесено в отдельные файлы и не нужно, то удаляю весь файл (croutine, event_groups, deprecated_definitions, message_buffer, mpu_prototypes, stream_buffer, timers).

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Just now, amaora said:

Если оно вынесено в отдельные файлы и не нужно, то удаляю весь файл

Ну так-то можно, конечно. Я и сам не включаю в компиляции то, что не используется.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

9 minutes ago, haker_fox said:

Все обработчики, использующие сервисы ОС должны иметь приоритет выше или равный configMAX_SYSCALL_INTERRUPT_PRIORITY. При обращении к сервисам они используют функции, оканчивающиеся на FromISR. Те обработчики, которые не используют сервисы ОС, могут иметь любые приоритеты. Я надеюсь у вас так?))) 

Ну тогда нужно только отладчик каким-то образом дружить с вашей системой.

А стеки у вас достаточной глубины? Может быть увеличить принудительно раза в два... 

Да так, только с выше-ниже путаница. Другие задачи сейчас обходятся одним vTakDelay() из всех сервисов ОС (ой нет забыл, есть мьютексы). В "быстрых" прерываниях которые более приоритетны чем вся ОС со всеми задачами, никаких функций ОС не вызывается, обмен только wait-free / lock-free методами.

На стеке свободного места много, особенно у той задачи, используется ~100 байт из 512.

Изменено пользователем amaora

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 часов назад, amaora сказал:

Правки это например убрал include string.h и заменил на свои объявления mem* функций. Удалил файлы croutine, timers, и другие что не планирую использовать никогда. Добавил аттрибут used одной функции и одной переменной. Исправил инлайн асм вставки в port.c, заменив загрузку адреса через ldr на две movw/movt. Последнюю часть делал из необходимости а не по желанию, лучшего решения не нашел. В остальном стараюсь ничего не править.

А не так, чтобы решил убрать вот здесь критическую сеецию для ускорения.

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

Не вижу смысла удалять неиспользуемые функции, все что не используется нормально выпиливается встроенными макросами ОСи. Относительно атрибута used для LTO есть более правильное решение с точки зрения "красивости кода" оно описано в тикете под номером 90. А вот изменяя файлы порта есть большой шанс что то сломать.

5 часов назад, amaora сказал:

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

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

BusFault_Handler\
                PROC
                EXPORT  BusFault_Handler           [WEAK]
                B       .
                ENDP

ПС: Перед написанием комментария не обновил страницу.... Потому несколько устаревший

Изменено пользователем Neo_Matrix

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...