Jump to content

    

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

15 hours ago, amaora said:

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
46 минут назад, x893 сказал:

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

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

Share this post


Link to post
Share on other sites
Just now, Arlleex said:

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, haker_fox сказал:

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

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

Share this post


Link to post
Share on other sites
3 minutes ago, Arlleex said:

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

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

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

Share this post


Link to post
Share on other sites
1 минуту назад, haker_fox сказал:

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

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

Share this post


Link to post
Share on other sites

Да, согласен, посмотреть стек повисшей задачи интересно. Но пока с этим есть проблемы, отладчик отказывается работать с имеющимся экземпляром устройства. Есть еще трудности с тем чтобы безопасно остановить всю систему (просто так сделать 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 )). И другие проблемы есть, из-за которых я правлю асм-вставки.

 

Edited by amaora

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
15 minutes ago, amaora said:

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

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

18 minutes ago, amaora said:

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

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

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

Share this post


Link to post
Share on other sites
3 hours ago, haker_fox said:

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

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

 

Share this post


Link to post
Share on other sites
Just now, amaora said:

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

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

Share this post


Link to post
Share on other sites
9 minutes ago, haker_fox said:

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

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

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

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

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

Edited by amaora

Share this post


Link to post
Share on other sites
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

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

Edited by Neo_Matrix

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now