Първо да предупредя, че съм бивш пикоборец, така че може да се очаква всичко
Хванах един проект с STM32F103VD , не бях се занимавал с АРМ досега, само с пикове и 8051ци.Взех си MCBSTM32E
board с STM32F103ZE на него, разцъках го, няма проблеми.Днес обаче реших да оживявам реалния хардуер, на който именно е лепнат STM32F103VD.Двата контролера нямат разлика, освен в размера на паметта.Всичко много добре, сменям интерфейса на SWD, понеже пълен JTAG на платката не е направен, програмата се товари, обаче при дебъг не може да стигне и до main() , само подскача по някакви асемблерски инструкции в прозореца с disassembled code.Ако на uVision-a му цъкна при дебъг да качва наново програмата ми дава грешка, че не може да намери памет 0х8000000.Не мога и не мога да оживя платката.......Някой някакви идеи?[/img]

http://www.keil.com/forum/docs/thread14110.asp Проблемът ми е абсолютно същия, с тази разлика, че като махна отметките при мен не се оправя

Аз мога само да гадая... поне да беше казал какъв емулатор използваш

Възможни са и хардуерни и софтуерни проблеми или комбинация от двете. Това че си спестил от сигналите ме навежда на мисълта, че вероятно и ресета не ти е вързан и трябва да осигуриш читаво начално състояние по друг начин. А пък ако си спестил от масите в JTAG/SWD конектора може и сигналите да се омазват. То затова не е добра идея да правиш икономии от дебъг интерфейса, щото драйверите са бързи и са правени за 50-100МХц и дори да го клатиш на ниска скорост фронтовете са стръмни и може да имаш осцилации. Това е често срещан проблем при саморъчно правените емулаторчета и кабелчета...

В такива случаи е добре да имаш и втори емулатор с който да изключиш проблеми по връзката и проблеми с нестабилен таргет. За предпочитане е или купешки емулатор или поне нещо от сорта на OpenOCD. Силата на второто е самостоятелната работа, демек закачаш се и през конзолата тестваш четене/писане от паметта, изпълнение на инструкция по инструкция и така се убеждаваш че таргета е ОК, както и че имаш стабилна връзка с него.
Едва след това може да се мъчиш с дебъгер. Тук трябва да си настриш зареждането на твоя софтуер, както и подготовката за дебъгване. Проблемът е че за флашването има различни варианти, като най-често в таргета се качва агент, който пуска клоци е всичко необходимо. В зависимост от емулатора и настройките може да се вдига JTAG/SWD клока и/или таргет клока. И след като приключи флашването процесора остава в "някакво" състояние... Според настройките може да се ползва външен ресет за да върне ядрото в начално (ресет) състояние преди да се продължи с дебъгването. Ама ти ако не си вързал ресета няма как да стане. Другия вариант е софтуерно да се ресетне всичко. За целта се пишат т.н. "ресет скриптове", които може да са на емулатора или пък на средата която ползваш.
На мен uVision нищо не ми говори, така че не мога да помогна... Само ти казвам, че ако не са ти оправени тия неща има много варианти да се омаже. Примерно ако агента е дигнал клоковете при флашването и ти после в твоя софтуер като част от инициализацията си може да минеш през някакъв по-нисък клок на ядрото, което ще скапе JTAG комуникацията и после трябва включ-изключ...

Миро, много се отплесна от темата човеко!
За да работи всичко както трябва(в кеил-а ), е нужно да заредиш програмата в контролера. След което, да добавиш точка на прекъсване в първия ред от main функцията. След което да пуснеш дебъг режима. Натискаш бутона "Run" и се преместваш на листа със C кода защото той те прехвърля в началото на асемблерския листинг. От там вече си добавяш или премахваш по твой избор точки на прекъсване, освен това вече спокойно можеш да ползваш и по стъпково дебъгване. Ако правилно си конфигурирал кейла и проекта преди да започнеш работа не би трябвало да имаш проблеми с поместването на кода в адресното пространство както споменаваш( и в двата режима JTAG/SWD).

Мда... ако всичко работи, натискаш "бутона run" и е така, както казваш
Само, че кво праим ако не работи? А то с АРМ често не работи, щото за да "конфигурираш правилно" нещата обикновено се иска да знаеш поне малко как работят..

Просто при кейла си има особености, нищо повече. А за конфигурирането той се грижи за това - ако избереш този вариант.

http://www.keil.com/ulinkme/ Това ми е дебъгера, това дойде с евалуейшън борда.Ресет-а е вързан, платката е правена не от мен, а от професионалисти, както трябва е.Мога да постна схема ако е нужно.

Не знам... не познавам нито ULINK нито кейл

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

Тук ако има колеги дето познават въпросните инструменти могат да дадат по-точни указания. Иначе след като пуснеш дебъга аз бих търсил първо начин за четене и писане от паметта. Не знам дали има конзола с команди за memory read/write или пък имаш някакъв джам memory view, но все трябва да имаш нещо...
Първо гледаш дали RAM се чете и дали се чете правилно, щото ако при всяко чете или refresh на view-то се менят стойностите значи нещо не е наред...
Гледаш дали можеш да променяш RAM-а. То в някои емулатори си има мем тест команди дето тестват паметта.
Ако паметта се дъни значи имаш проблем с процесора или SWD-то, т.е. нещо на съвсем ниско (хардуерно) ниво.
После гледаш флаша - дали там наистина е записана твоята програма или не. Ако не е твоята програма някои дебъгери се държат наистина странно и се получава тоя ефект на "скачане". Това се получава когато дебъгера не чете реално флаша. Само взема РС-то (адреса) на който е спрял процесора и ти показва твоя код на тоя адрес. Ти виждаш някаква инструкция от твоя код, но като степнеш се изпълнява нещо съвсем различно (това което реално се намира като код във флаша). При GDB е така, при IAR доколкото си спомням четяха флаша и го няма това скачане... Не знам при кейл как е...

Както и да е - идеята е да видиш какво е записано и освен това да пробваш постъпково изпълнение на асемблерски инструлции. Ще е хубаво поне малко да имаш поглед върху асемблера, колкото да се ориентираш дали кода който се изпълнява е тоя който виждаш... Но все се надявам, че толкова ще се ориентираш - кои инструкции са за преход, кои местят регистри и т.н.
Ако процесорът изпълнява правилно инструкциите вече остава да видиш защо не стига до твоя main()... Демек просто да го дебъгнеш Първо се убеждаваш че дебъга започва от ресет вектора, там се зарежда правилно PC и SP и после се изпълнява твоя код за инициализация, доколкото имаш такъв - не знам

Проблема наистина се оказа тъп Имало boot pins процесора си търсеше кода на друго място