Трябва ми да разбера дали изпълнението на програмата е било прекъсвано ( при спиране на брейкпоинт примерно).

Имам едни вътрешен RTC и външен такъв, закачен на I2C бъс. Вътрешния переодично се досверява и калибрира по външния и клочат с еднаква честота едно и също време. Трябва ми начин как да разбера кога процесора е спирал на брейкпоинт примерно, за принудително да сверя вътрешния часовник по външния.

Вътрешния RTC спира да се клочи ако процесора е спрян.

Има ли функционалност в дебъг системата на ядрото от която да може да се разбере, че процесора е спирал?

Търся начин да се разбере имало ли е спиране на процесора, без да се използват допълнителни процесорни периферии (като таймери продължаващи да се клочат по време на халтнат процесор).

мисля че, нямаш достъп до тези фунции, ( програмно )
разлика в часовниците...

Има достъп до някои ITM регистри, ама не знам дали ще стане това, което искаш...

Но ако ползваш gdb просто си правиш .gdbinit файл и в него си прехващаш каквото пожелаеш.

Благодаря за бързите отговори.

Надявах се да има прост начин.

Ще пробвам с условна компилация в дебъг версията да разреша WDT без Stall_On_Halt, с опция да генерира прекъсване, вместо HW ресет. Идеята е в това прекъсване да си сетна флаг, който да проверявам в таска за времето и така да се предизвика сверяване на вътрешния RTC по външния, когато програмата се стартира след брейк поинт.

Ограничението ще е, че ще спирането на програмата ще трябва да е за повече време от периода на WDT, но това почти винаги е така.

Можеш ли да трейсваш разликата в двата клока при всяка синхронизация? Предполагам външният е free running (т.е. не спира) и тази синхронизация е там само за да компенсира офсета на кристала. Т.е. всяка по-голяма разлика означава, че вътрешния е спирал.

Мога, но не е добра идея.
Външния RTC е закачен през I2C и генерира алармен евент точно през 15 секунди.
Този алармен евент тригерира хардуерно кепчване на вътрешния RTC и по този начин е възможна точната калибровка (+/- 30uS - т.е. 1 клок) на осцилатора на вътрешния RTC. По времето на този евент се прочита времето на външния RTC през бавния (400кХз) I2C бъс, което не става бързо.
Всички тайминги процесора ги базира на времето на вътрешния RTC.

Та ако процесора спре на бреикпоинт, при стартирането си след това той продължава с времето от вътрешния си RTC до момента на алармения евент от външния RTC.
Искам да избегна ненужно четене на външния часовник и да го направя възможно най-рядко (на 15 секунди примерно)

При спрян процесор и пуснал watchdog можеш да предизвикаш reset и да детектираш че процесора се е ресетирал по watchdog
Така или иначе след breakpoint не ти остава нищо друго

Е, аз не искам да се ресетирам след всяко спиране на брейкпоинт, а да продължа да дебъгвам до следващия брейкпоинт.

Извинявай , не разбрах че става въпрос за debug режим.
Мисля , че най-лесно е да реализираш софтуерен RTC който да го свериш с външният и след breakpoint да видиш каква е разликата.
Софтуерният RTC няма да работи при breakpoint.
Ако обаче искаш само да провериш дали е влизало в breakpoint аз бих направил следното:

Въпроса е как да разбера, че съм спирал на брейкпоинт.

Идеята с писането и четенето на DCRDR дали би работила във всички случаи надеждно?

Ако правилно съм разбрал - този регистър съдържа последно четените/записвани данни от/в регистрите на ядрото. Та е възнобно при влизане в дебъг и след излизане от дебъг - този регистър да съдържа стойността, която съм записал като маркер в него и да не разбера, че проца е спирал...

Има ли друга опция за "спиране" (например Sleed Mode) ?
DCRDR ще хване че е спрян от debuger-a но не и че процесорът е спирал

Има приспиване на процесора, но там проблема с часовниците е решен от RTOS-a.

Проблема е само когато програмата е спирала и тръгвала след бреикпоинт.

Не разбирам кода

Няма ли опастност с това писане в този регистър и след това проверка дали съдържа записаната от мен стойност да НЕ разбера, че процесора е спирал на брейкпоинт?
( например ако последно записаната/прочетена стойност от регистрите на ядрото при спиране на брейкпоинт съвпада с тази, която аз съм записал и използвам като маркер?)

Трябва ми надеждно решение работещо на 100%.

Одавна беше, позабравил съм нещата, но:
- Всички дебъг регистри които достигаш през JTAG/SWD, можеш да ги достигаш и софтуерно.
- Провери в документацията или в сорса на ОпенОЦД, как се слага, хард/софт брейкпоинт и как се резюмва таргета след като е хитнал такъв.
- Анализирайки регистрите (например нова стойност в някой брекпоинт регистър, или някой старт бит вдигнат) предполагам с голяма сигурност може да хванеш че си спирал.
- Обикновено дебъг състемата е направена да може да работи в Halt (JTAG) или в Monitor (debug agent) режим. Във втория таргета вместо да халтва, влиза в дебуг прекъсване. Възможно е да има някъде по регистрите статус на този интеръпт, дори да не е извикан защото е в Халт мод, все пак да е вдигнат.
- 100% има статус битове по които да се види таргета защо е влязал в дебуг, но дебъгера със сигурност ги нулира...

Благодаря на всички за коментарите.

Проблема го реших с WDT като го описах в по-преден пост.

И все пак ако има по-читаво решение с проверка на HW регистър или флаг би било полеьно да се знае за друг подобен случай.