добрый день

подскажите кто пользуется эклипсом возможно ли нормально отлаживать задачку с scmrtos

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

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

Так проблема в поддержке клипсой плюсов при отладке или в оси?

Полагаю, проблема в оптимизации. Ось компилируется с достаточно высокой степенью оптимизации и связь между исходником и ассемблерным кодом становится далеко не однозначной. Сишный же код наверняка компилится вообще без оптимизации, поэтому никаких неоднозначностей не возникает. Остается выбрать: если мы хотим писать большие медленные программы, то надо отключить оптимизацию и при компиляции C++. Если же мы хотим писать маленькие быстрые программы, то надо открывать рядом окно дизассемблера и отлаживаться в нем. Вариант "отключать оптимизацию на время отладки" - это вообще не вариант, ибо
а) будет отлаживаться фактически другая программа
б) не факт что она вообще соберется (без оптимизациии отключается встраивание)
в) после включения оптимизации в якобы отлаженной программе она может перестать работать и горе-программист окажется в той же ситуации, что и в начале - программа не работает, а отлаживать оптимизированный код он не умеет.

проблема не в оси а в системе отладки еклипса плюсов похоже

никто не знает в кокосе дело точно так же обстоит?

Не вижу у себя таких проблем с отладкой. Да, он скачет по сишным/плюсплюсным строкам, но только лишь потому, что благодаря объединению одинаковых участков кода один и тот же код ассемблера соответствует нескольким разным строкам исходника. Поставьте оптимизацию -O1 и увидите прекрасную отладку.

да я посмотрел код дизасемблера, там все перемешано из-за оптимизации, потому видимо так все скачет

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



вот в таком вот коде



что я не так делаю?

кажется разобрался...

init_stack_frame(); вызывается самой ос
а stack_slack(); следует вызывать таким образом Proc4.stack_slack();
верно? то есть в итоге делать так



Сообщение отредактировал сарматъ - Sep 22 2013, 07:03

продолжаю тему начатую тут

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

в одной из задач есть мигание светодиодом, эта задачка никого не ждет никаких ресурсов, вот ее код


но светодиодик моргать перестает

подскажите какие места в ос посмотреть отладчиком какие переменные чтобы понять отчего перестали переключаться задачки?

Сообщение отредактировал сарматъ - Oct 18 2013, 10:50

Здесь я вижу только три возможные проблемы:
1) Перестают генериться прерывания системного таймера. Это можно проверить, останавливая и запуская программу и смотря на переменную Kernel.SysTickCount. Если она меняется - значит прерывания генерятся и обработчик вызывается.
2) Из-за переполнения стека в переменную Timeout этого процесса заносится ноль и ожидание этого процесса становится бесконечным, либо заносится какое-то огромное число и вы просто не дожидаетесь окончания задержки sleep(). Опять же отлавливается отладчиком наблюдая за этой переменной - тикает ли и дотикивает ли до нуля.
3) Какой-то из более высокоприоритетных процессов крутится в цикле не отдавая управление (не впадая в ожидание в каком-либо из системных сервисов). Или же более высокоприоритетные процессы не успевают выполнить свою работу и до низкоприоритетных очередь просто не доходит. Это отлавливается наблюдая за тем, где крутится программа - если в IdleTask, то все нормально, если в каком-то из процессов - разбираться, почему он не отдает управление.

Есть еще одна возможная причина -
4) во время выполнения этой задачи происходит перепланировка, которая по какой-то неведомой причине удаляет эту задачу из карты активных задач. Это можно проверить, поставив точку останова в IdleTask и посмотрев на переменную Timeout этого процесса и на карту активных процессов Kernel.ReadyProcessMap. Либо ReadyProcessMap должен содержать единичку в бите этого процесса, либо Timeout должен быть ненулевым.
Ни вторая, ни четвертая не объясняют, почему останавливаются и другие задачи тоже. Ну разве что кто-то обнуляет ReadyProcessMap, останавливая все процессы.

да в этом месте
точки останова не срабатывают, Kernel.SysTickCount не увеличивается, но я не понимаю изза чего, подскажите куда копать дальше?

в задачке есть прерывания - они работают, в том смысле что прерывания разрешены... в TIdleProc::exec() тоже ос попадает

Сообщение отредактировал сарматъ - Oct 18 2013, 16:06

Смотреть, тикает ли таймер. Если тикает - то почему не вызываются прерывания - может кто-то их запретил. А может таймер кто-то остановил.

наехал телнетом на опеносд посмотрел значения регистров связанных с таймером систик

0xE000E010 - 0х00010007 - прерывания разрешены (не понял пока назначение 16-го бита пробовал его сбрасывать с помощью mww команды, этот бит все равно устанавливается в единицу)
0хЕ000Е014 - 0х0002903f - значение регистра перезагрузки
0хЕ000Е018 - все время разные значения - таймер тикает

это прерывание не вызывается


нашел разницу между работающей и нерабочей системой

в работающей системе регистр 0xe000ed04 равен 0
когда система залипла то значение 1400e84d выходит что pendsv, равно как и систик отложены поэтому прерывание систик больше не генерируется, так? и что с этим делать?

Сообщение отредактировал сарматъ - Oct 19 2013, 17:11

Вот честно - совершенно не хочется лопатить документацию ST чтобы найти, что за регистр живет по адресу 0xe000ed04.

да,я погорячился, это ICSR, таблица 8.6 из книжки джозефа

Тогда, если я ничего не путаю, 4D в младших битах указывает, что ваша программа осталась в прерывании OTG_FS. Вероятно, вы вызвали из этого прерывания какой-то сервис, который выполнил перепланировку.