[MiklPolikov 0]

Помогите понять, что означает  этот prvTaskExiterror    в  Call Stack ?
Почему адрес 0x00000000 ?
Если поставить точку останову, в функцию prvTaskExiterror  программа не попадает.

Настройки freeRTOS:
#define configKERNEL_INTERRUPT_PRIORITY         0xFF
#define configMAX_SYSCALL_INTERRUPT_PRIORITY     0xb0 
#define configLIBRARY_KERNEL_INTERRUPT_PRIORITY    15

Отключаю субприоритеты: 
NVIC_SetPriorityGrouping( 3 );   // после этого  SCB->AIRCR = 0xFA050300  

[Arlleex 131]

Означает, что задача попыталась где-то сделать return.

[MiklPolikov 0]

On 6/30/2022 at 8:23 PM, Arlleex said:

Означает, что задача попыталась где-то сделать return.

Имеется в виду, что в основном цикле задачи, из которого выходить нельзя,  команда
return; 
?

Точно нет.
Я смотрел, с какого момента в Call Stack появляется этот prvTaskExiterror.
Даже если задача всего одна, и я поставил точку останова в самом начале, то prvTaskExiterror уже есть.

[Arlleex 131]

А, она первая в вызовах, не обратил внимание.

Скорее всего, механизм смены контекста в RTOS ломает взаимосвязи в отладочной информации, которую среда себе генерирует.

Проверить это можно, наблюдая при заходе в main() и до запуска планировщика нормальный callstack с main() в корне вызовов, а после запуска шедулера - callstack, указанный Вами.

[jcxz 184]

В 30.06.2022 в 18:55, MiklPolikov сказал:

Помогите понять, что означает  этот prvTaskExiterror    в  Call Stack ?
Почему адрес 0x00000000 ?

Сразу скажу - с FreeRTOS не работал. Могу только предположить, что в программе prvTaskExiterror отсутствует (или не используется и выкинут компоновщиком). Поэтому "Location/Value=0" для него.

Также в том месте, где Вы остановили выполнение, в CallStack есть значение 0, которое Ваш отладчик почему-то считает адресом возврата. Так как символьное имя prvTaskExiterror=0, то соответственно отладчик и считает этот 0 в CallStack - это есть адрес == prvTaskExiterror.

 

В 01.07.2022 в 10:14, Arlleex сказал:

Скорее всего, механизм смены контекста в RTOS ломает взаимосвязи в отладочной информации, которую среда себе генерирует.

В стеке нет отладочной информации (по-крайней мере компиляторы на МК не настолько жирные пока, чтобы создавать её (на ПК - возможно уже пишут в стек вызовов такую инфу)).

А значит - как именно трактовать некое значение X, лежащее в стеке, отладчик может только глядя на информацию о фрейме стека, формируемом данной функцией. Если фрейм стека формируется функцией например командой PUSH {R4-R6,LR}, то отладчик считает, что внутри функции значение лежащее по адресу SP+12 - это адрес возврата. Он читает это значение и ищет его в списке символических имён программы (этот список - в отладочной инфе программы). Получается, что если из SP+12 он прочитал 0, то он может взять любое символическое имя из списка, имеющее значение =0 и выдать его как адрес возврата из этой функции. По-крайней мере IAR так и поступает.

 

PS: Таким образом - на месте prvTaskExiterror могло быть любое другое символическое имя из *.map, имеющее значение =0. Не нужно обращать внимание на само это имя. Нужно обратить внимание на его значение = 0. Почему в стеке 0 на месте адреса возврата?

 

В 01.07.2022 в 10:14, Arlleex сказал:

А, она первая в вызовах, не обратил внимание.

PPS: И кстати - у меня подозрение, что вершина стека - не в самом низу списка, а вершина стека - это функция SIM800_USART_Transmit_Byte. А значит со стеком всё в порядке. Просто в самом низу стека есть лишнее неиспользуемое слово =0.

Где именно вершина стека списка - может знать только ТС. Только он знает каким отладчиком пользуется.

[Arlleex 131]

jcxz, отладочная информация не в стеке, а в специальных файлах на компе. Обычно прямо в .elf или как его там. К слову, main() вполне можно увидеть с нулевым адресом в стеке вызовов как раз после мазохинаций со стеком в контексте использования RTOS.

[jcxz 184]

В 01.07.2022 в 19:09, Arlleex сказал:

jcxz, отладочная информация не в стеке, а в специальных файлах на компе.

Я это прекрасно знаю. Зачем вы это мне объясняете?

Я пишу что отладчик неверно интерпретирует 0 как prvTaskExiterror, так как это имя видимо имеет значение ==0.

И это:

В 30.06.2022 в 20:23, Arlleex сказал:

Означает, что задача попыталась где-то сделать return.

тоже не понятно - на каком основании сделан такой вывод?

 

Имхо - то место, где отладчик определил prvTaskExiterror - просто уже находится за пределами стека. Нет там валидных данных вызовов.

[Arlleex 131]

1 час назад, jcxz сказал:

Я это прекрасно знаю. Зачем вы это мне объясняете?

Я писал с телефона, цитировать не стал ибо не удобно. А оно (сообщение) предполагалось ответом на

7 часов назад, jcxz сказал:

10 часов назад, Arlleex сказал:

Скорее всего, механизм смены контекста в RTOS ломает взаимосвязи в отладочной информации, которую среда себе генерирует.

В стеке нет отладочной информации (по-крайней мере компиляторы на МК не настолько жирные...)

 

Цитата

И это ... тоже не понятно - на каком основании сделан такой вывод?

Потому что в описании этой функции черным по белому это написано.
А я изначально не обратил внимание на месторасположение prvTaskExitError в стеке вызовов и дал ошибочный комментарий, о чем позже и написал.

[jcxz 184]

В 01.07.2022 в 20:20, Arlleex сказал:

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

Из исходного поста не понятно: где вершина стека - сверху или снизу? Но, исходя из названий функций (...Control, ...Init, ...AT, ...TransmitByte) можно предположить, что вершина - сверху.

(вершина - самые последние записанные в стек данные)

[Arlleex 131]

Да, вершина сверху в отладчике Keil-а.

P.S. Я бы хотел взглянуть на файл конфига FreeRTOS у автора топика, а также узнать каков уровень оптимизации в настройках среды.

[MiklPolikov 0]

On 7/1/2022 at 8:32 PM, Arlleex said:

 

P.S. Я бы хотел взглянуть на файл конфига FreeRTOS у автора топика, а также узнать каков уровень оптимизации в настройках среды.

 Уровень оптимизации пробую 0 и 3.
 Первое, что делаю, проверяю не меняется ли поведении в зависимости от оптимизации.

Файл  FreeRTOSConfig
https://disk.yandex.ru/d/bqcWrxBnfGbVaQ

 

[jcxz 184]

А проблема то в чём именно?

[Arlleex 131]

1 час назад, MiklPolikov сказал:

Файл  FreeRTOSConfig...

Ну все, configTASK_RETURN_ADDRESS не задан, значит, в стекфрейме любого таска в корне будет адрес возврата на prvTaskExitError(). Все в порядке. Почему он светится нулем в Keil сказать трудно, нужно детальнее разбираться, почему так. Предположение свое я выдвинул выше. Я бы глянул дамп памяти по месторасположению LR в стеке, когда отладчик там рисует 0 в стеке вызовов. Реально ли там 0... не должно быть. А можно и сам LR глянуть в месте входа в функцию-реализацию таска. Он должен быть равен адресу prvTaskExitError().

[jcxz 184]

В 06.07.2022 в 16:50, Arlleex сказал:

Реально ли там 0... не должно быть.

А какая разница что там, коли:

В 30.06.2022 в 20:59, MiklPolikov сказал:

в основном цикле задачи, из которого выходить нельзя,  команда
return; 
?

Точно нет.

?

[Arlleex 131]

14 минут назад, jcxz сказал:

А какая разница что там, коли...

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

И тем не менее, интересно узнать, почему Keil рисует там 0.