[Fox_Sanchez 1]

Добрый день!

Есть проект с на STM32F429 с FreeRTOS. Там несколько не сильно загруженных задач. Одна из них получает из очереди сообщения, парсит их и передает на ПК через UART всякие текстовые сообщения.

Помогите отловить странный глюк: при выводе наблюдается что-то типа "Отпра��лено с��общение". При том бьются символы на схожем интервале во всех посылках.

Пробовал передачу как блокирующую, так и по прерываниям и даже через DMA - везде оно присутствует в разной мере. Отладчиком проверял - из очереди данные поступают без повреждений. Функции УАРТ брал ХАЛовские стандартные, свои писать пока не пробовал. Если все остальные задачи заглушить - глюк пропадает (но и очередь не работает, просто делаю тестовый вывод в цикле единственной задачи).

Кстати насколько ХАЛ можно использовать в многопоточном приложении? (при условии что с УАРТом работает только одна задача)

[Fox_Sanchez 1]

Дописал свои функции вывода - не помогло.

void my_putchar(uint8_t ch)
{
	taskENTER_CRITICAL();
	while(!	(huart5.Instance->SR & UART_FLAG_TXE)	);
	huart5.Instance->DR = (ch);
	taskEXIT_CRITICAL();
}

void my_puts(uint8_t * str, uint32_t len)
{
	uint32_t i;
	for(i=0;i<len;i++)	my_putchar(*(str+i));

}

Строка на вход приходит нормальная (смотрю отладчиком, брякпоинт на вызов my_puts), на выходе - битая. Что еще это может быть?

Есть какая-нибудь возможность "отловить" обращение к памяти под массивом этой строки? В момент вызова my_puts она нормальная, а в процессе вывода данные портятся. При том далеко не каждый раз. Такое ощущение, что туда кто-то пишет эту дичь время от времени.

[x893 35]

1. Поставить BP на изменение памяти.

2. Подождать пока кто-то из участников форума пройдёт курсы телепатии.

[haker_fox 60]

Мой опыт подсказывает, что проблемы возникают часто по этим причинам:

1. Не хватает стэка задаче. Можно временно увеличить всем задачам при создании стэк до заведомо больших величин, например до 1024 слов (число в FreeRTOS при создании задачи указывает не количество байт, а количество слов).

2. Не хватает стэка MSP. Увеличить его размер в скрипте линкера. Тоже, допустим до 1 кБ. Задачи работают со стэком PSP.

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

[rkit 1]

Ошибка математики на стеке буферов, выход за границы буфера, или еще что-то такое.

[kolobok0 0]

12 hours ago, Fox_Sanchez said:

....Такое ощущение, что туда кто-то пишет эту дичь время от времени.

huart5.Instance->SR & UART_FLAG_TXE

Открою большую тайну - это тип совсем не буль... Далее думаю понятно...

 

(круглый)

ЗЫ

ВАНГУЮ: Но имхо - это не единственный ляп в коде.

Изменено 29 августа, 2020 пользователем kolobok0

[haker_fox 60]

2 hours ago, kolobok0 said:

Открою большую тайну - это тип совсем не буль... Далее думаю понятно...

Он и не должен быть булем. Главное, что он или ноль или не ноль. Так всегда циклы для поллинга флагов писали и пишут)

[juvf 10]

29.08.2020 в 18:01, kolobok0 сказал:

Открою большую тайну - это тип совсем не буль... Далее думаю понятно...

в си (а фриртос на си) нет булей. у тс нормальная строка.

2тс, попробуй так

while(! (huart5.Instance->SR & UART_FLAG_TС) );

 

[AVI-crak 0]

On 8/29/2020 at 4:46 AM, Fox_Sanchez said:

Есть проект с на STM32F429 с FreeRTOS. Там несколько не сильно загруженных задач.

Проверь в настройках FreeRTOS режим энергосбережения. Когда ядро уходит в сон с работающей периферией - иногда подобная фигня случается. 

[x893 35]

И уберите

taskENTER_CRITICAL();

taskEXIT_CRITICAL();