В момента работя с nRF51xxx от Nordic Semiconductor (SoC радио и Cortex M0) и имам проблем с подкарването на дебъгера. Постановката е следната:

- Eclipse
- ARM GCC
- J-Link Light (с драйвери JLink_V498a)
- nRF51xxxx (Cortex M0)

При стартиране на дебъг сесия мога да минавам през кода стъпка-по-стъпка и изглежда, че рабори коректно. Но, когато задам брейкпоинт някъде в кода и се стигне до тази част, дебъгера росто не спира, въпреки че кода се изпълнява. Не става въпрос за определено парче код, а за всеки сетнат брейкпоинт. Прдеполагам, че трябва да направя някакви допълнителни настройки в Eclipse-a, но съм малко нов с тази конфигурация... така че всякакви съвети и насоки са повече от добре дошли!
Благодаря предварително

Виж колко активни брейк поинта имаш, да не би да си заел всички хардуерни такива, виж и колко е броя на хардуерните бейкове за това ядро... Софтуерните са безброй ама за дебъгване в флаша трябва специален съпорт...

Току що пробвах - не е това. В моемета имам само един активен брейкпойт и пак се дърпа.
Мисля, че поне разбрах на къде да се насоча. Оплаква се за разтоянията в пътя към проекта. Някаква идея как се бори този проблем? Само не ми пепоръчвайте да ги махна Знам, че е добра практика, но ще е играчка да се направи имайки предвид структурата на проекта.

ползвайки командата SUBST ( от командния промпт ) можеш да сетнеш директорията на проекта да се вижда като виртуално дисково устройство с негова си буква, напр "v:" оттам нататък си работиш с v:, а не с реалния път към директорията.

Благодаря за насоките!
SUBST е интересно, но не мисля, че би ми помогнало в дадената ситуация (или поне аз не виждам как).

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

Когато стартирам дебъг сесия, в конзолата се появява червено съобщение (за части от секундата) гласящо: "No source file named ....(тук е пътят до файла)".
Т.е. май се опитва от проекта да си намери сорс файловете, но не му се получава. Друго странно нещо е, че "/" е заменено на места от "?", а на други места просто липсва.
Всякакви идей и напътсвия са добре дошли

Проектът ти очевидно не е организиран добре и колкото и да не ти иска да го бараш е по-добре да го оправиш. Иначе постоянно ще ти изкачат "проблемчета" от всякакъв характер.

По отношение на интервалите в пътищата, наистина е желателно да ги няма. Просто мейк работи със списъци и за разделител между елементите в списъка се използва интервал. Единият вариант е навсякъде в мейкфайла да оправяш работата със списъци, но е тъпо и не е добра идея. Действително на някои windows инсталации make.exe се справя въпреки интервалите и работи, но не може да разчиташ на това защото ще попаднеш на компютри на които няма да работи.

Другият проблем е с наклонените... Пак зависеше от боз инсталацията,щото на места работи, на места не работи ако се смесват / и \... При лайнукса поне е ясно, има само една наклонена, няма интервали. Може би лайнукс няма да ползваш, но пак е добре да се пази съвместист, защото така или иначе повечето GNU интрументи идват от лайнукса...

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

Пак да се обадя ...
Проблемът с интервалите същи се решава ( някак ). Всеки файл и всяка директория имат 2 имена: едното е дълго име, в което може да има и интервали, другото е стандартно ( 8.3 ). Второто е образувано от първото, като накрая е добавено ~1, ~2 и т.н.
За да видиш съответствието между двете представяния на името на файла, в команд промпт напиши DIR -x.
Естествено, най-добре е да нямап такива екзотични имена в проекта си.

dir /X

Maj da

Бате, решава се така ама само "някак"...

Не винаги ти задаваш файла, примерно за изграждането на разните dependancy и debug информации то си търси само файловете и им изгражда пътища. Нямаш контрол в тоя процес и ако нещо се обози гориш...

Проектът ти managed или make е? Ако е managed можеш да пробваш да смениш между internal builder и external builder. Кой компилатор (toolchain) точно ползваш?
Качи някъде проекта или ако е на база на нещо примерно дай линк да видим какво може да се направи.

Проекта се билдва на базата на вече съшествуващ мейкфайл или по-тчоно на няколко файла. Компилатора е GCC ARM.
Относно организацията на проекта може да видите как е организиран тук ->http://developer.nordicsemi.com/nRF51_SDK/nRF51_SDK_v8.x.x/. Практически, проектите се намират в екзампъл папката и от там нагоре в папките се намират библиотеките. Дали е добре структурирано - вие ще кажете.

Относно дебъгера - тръгна, след като в настойките за дебъгера вЕклипс добавих "Path Relative to Source Folder" да е абсолютният път на проекта. Как това помага... предолагам, че това оказва на GDB-то къде да търси за сорсове. Поправете ме ако греша. Как стигнах до това решение - намерих коментар в нета по-моя проблем, пробвах, и взе че тръгна

По-вероятно е друго, свързано със съседната тема за мишките и визуалните средства...

Еклипса и какъвто там плъгин ползваш, обикновено позволяват да поставяш брейкпоинт по всяко време ако си в дебъг перспектива. Ако дебъгерът не е пуснат, брейкпоинтите само се запомнят къде трябва да са и се поставят едва след пускане на GDB и зареждането на elf-a. Проблемът в тоя случай е, че Еклипса не знае дали на дадено място може да се постави брейкпоинт или не, или пък както е в твоя случай пътят може да се указва по различни начини и в крайна сметка GDB да не може да постави брейкпоинта. Но всичко това се разбира едва след като графичната среда подаде командичката на GDB за поставяне на брейкпоинт. За съжаление често тая информация не стига да потребителя, защото или той не гледа правилната конзола или плъгина я спестява или нещо друго. И така ти си мислиш, че си поставил брейкпойнт, но реално не си и има да чакаш да спре....

В такива случаи правилният подход е да забравиш за мишките и графичните глезотии, да си отвориш GDB конзолата и да проиграеш всичко там. Не забравяй, че GDB, GCC, както и повечето GNU инструменти са конзолни приложения. Даваш им една след друга командички и на всяка стъпка гледаш кое минава и дали изобщо минава. Ако не минава то ще те напсува и ще видиш.
А пък вече като подкараш всичко пак може да си ползваш графиките, ако така ти е по-удобно... Но при проблем пак казвам най-чисто и сигурно си е да разкараш "посредниците".

Така е, но то в еклипса си я има gdb конзолата (gdb traces) и можеш и ръчни команди да си вмъкваш.
Понякога при билд-а пътя до сорсовете, който се вписва в елф файла, може да е проблема - релативен спрямо локацията на билда (дето е елф-а накрая) или абсолютен. Това води до съобщения че сорс файла не е намерен. Може би такъв проблем е имало при колегата.