Здравейте, следя темите на колегите тук във форумът и сега стигнах до момент в който и аз имам нужда от малко помощ.
Проблемът с които се сблъсках през последните няколко дни е с опит за зареждане на моя лична програма в Keil uVision и опит за дебъг в съответната среда. Първо проектът съм го изчистил от грешки и warrning-и, стигам до стартиране на самият дебъгер, и от тук на сетне започват нещата които се опитвам да дооправя. Поведението е следното - когато съм в дебъг мод, и стопирам изпълнението на програмата , след което ресетирам CPU-то, изпълнението на апликешънът незапочва от main - a. Знам че проблемът е свързан с конфигурационни настроики, но незнам точно кои. Понеже използвам контролер на Fujitsu - S6E2CCAJ0A, а версията на Keil ми е Keil uVision5, за този контролер Fujitsu са дали и примерни темплейти. Аз съответно изполвам един от тяхните темплейти, без да променям съответно сетингите на теплейтът. И въпреки това в дебъг, немога да вкарам изпълнението на програмата ми да влезе в main-а. Някой може ли да даде съвет как бих могъл да оправя сетингите на проектът, понеже гледах в memory map-a на контролерът, в startup файлът в регистрите на CPU-то - R15(PC) по конкретно, проверих дали са задали същият контролер в сетингите на проектът в Keil и неможах да подкарам нито едно от приложенията им.
Към постът прикачам и проектът си, ако може някой да ме насочи откъде идва проблемът.

Не знам с какви настройки е обвързан проблема ти, но принципно има стартъп код, който се изпълнява преди main функцията. В твоя проект конкретно е "/StartUP/startup_s6e2cc.s".
За да го прескочиш лесно - сложи си breakpoint в main функцията. Вероятно има бутон "Run to main" или нещо подобно, но някой по - запознат колега нека каже.

Предполагам тва е някакъв куртекс... За да тръгне правилно единия вариант е преди тръгването някой да избичи ресет, другия вариант е да се симулира ресет, т.е. да се заредят SP(r13) и PC(r15).
Тук вече зависи от дебъгера (кейла не го познавам) и от jtag емулатор (не знам какъв се ползва). Но принципно няма стандарт и вариациите са много. При gdb и някои други се разчита на скрипт, който потребителя може да настрои. Други дебъгери пък си имат диалог за настройки и там може да се указва дали да ресетва, как да ресетва, какво да прави след ресет и т.н. Предполагам е втория вариант, така че търси из настройките какво има. По възможност го сложи да ресетва и да спира веднага, след което провери дали наистина е върху първата инструкция от стартъпа и дали стек поинтера е ОК. Ако нещо не е наред дотук едва ли ще стигне далеко. Ако пък е наред то може след това стартъп кода ти да се омазва и пак да не стига докъде искаш, но това може да го дебъгнеш и да го видиш

Вече се чудя от какво може да е, понеже ми се изчерпват идеите. Само искам да допълня нещо към твоето исказване - " По възможност го сложи да ресетва и да спира веднага, "- в сетингите съм сложил опцията която ми гарантира при влизане в Debug че ми се рисетва и уж че ми спира. Но реалните резултати са че при влизане в дебъг то не спира в началото на main-а (както всъщност трябва нормално да се държи), а си върви някакъв run. Като спра програмата чак тогава виждам че се е отвяло на м....ната си, към адрес който няма нищо общо в действителността.
Слагах и брекпоинти в startup-а и там неможах да го хвана.

Под "веднага" имах предвид ВЕДНАГА!

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

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

....да именно ....

Гледам, че кейл има нещо като конзола (command window)... Има командички за ресет, за изпълнение на една инструкция и т.н.
Ресетваш и почваш стъпка по стъпка да гледаш какво изпълнява и къде се омазва. Надявам се да имаш поне повърхностна представа за асемблер, колкото да различаваш аритметични инструкции от такива за преходи.