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

Миро, сигурен съм, че съм се докарвал до там, но не съм сигурен защо

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

Има и нещо друго, което преди време ми се стори странно, но не съм имал време да проверя, дали не се заблуждавам. Ако вдигнеш лок бита, не можеш да изтриеш чипа с J-Flash. Трябва първо да го ънлокнеш (той се самоизтрива), да му спреш захранването, да го пуснеш и чак след това можеш пак да мажеш. За мен логичното беше Erase да забърсва и лок бита. А то излиза (ако съм прав де), че лок бита е на друго по-горно ниво.

Мейдън - незнам точно какво си направил, затова ти давам малко вятърничеви съвети, съдейки от моя опит. Може при теб да е различна ситуацията. Освен това аз това аз с 3 серия опит нямам, само с 1 и 4.

мда... пак четох и пак не съм сигурен Май не трябваше да се хващам с тая фирма, смотани чипове а документацията направо отвратителна... Разни безумни апп нотове като това и това , други пък по 150 страници глупости и накрая те препращат да прочетеш още 5 подобни. Ужас!
Интересно ми защо като може да е просто правят такива глупости. Е при атмел - заключва се с един бит и като се заключи няма jtag няма четене няма нищо. Отключването или от вътре викаш чип ерайз или от вън вдигаш ERASE pin. Просто и ясно. И при луминари е подобно, само дето няма ерайз пин, а през jtag и проблемите идват единствено от бъгавия им jtag. Но пак е просто - като е защитен е защитен, като не е - не е.
При ST различни защити и не е ясно коя бачка, коя не. Що за малоумна история да оставиш jtag, а да се опитваш да защитаваш флаша... Не е ясно ако включа всички защити пък дали няма да си скапя ъпдейта на фърмера щото и това намекват.

Аз лично го четох 20 пъти и не го разбрах еднозначно.

ех майка му стара три дена вече ме мъчи този процесор. Не става и не става. Утре ще пробвам през бутлоъдъра да го препрограмирам белким затрие тези option байтове. Уж му пуснах екзампъла на IAR за стм32ф373, какво толкова се омаза не знам... Сега влиза в някакъв дебъг режим на адрес 0xaaaaaaaa и пищи че е невалиден stack pointer alignment. Като му пиша ръчно адреса на някоя функция си скача на нея. Но пък стъпка по стъпка не може да дебъгва. Уж дебъга е разрешен, като гледам по битовете...

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

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

На дебъг като гледам регистрите, флаша е заключен. Има последователност от два байта в дейта шийта, пиша ги и виждам, че се отключва. След резет пак същата история

Това е ясно... стандартно решение - отделен ресет на дебъг частта и отделен ресет на останалата част от системата. Така дебъгера може да ресетва системата и още докато е в ресет да си сложи брейкпоинт преди първата инструкция и като пусне системния ресет проца спира на брейкпоинта без да е мазал никъде.
Обратното е кошмар, Луминари примерно имаха една бъглива серия дето дебъгера като се опита да направи системен ресет се ресетва и дебъг частта, ресетват се брейкпоинти абе всичко се ресетва и проца тръгва и няма кой да го споре. Естествено дебъгера пак може да се конектне и да се опита да го спре, ама проца веднъж като тръгне може да изключи пинове, да пипне клока и в крайна сметка дебъгера да не успее да се върже...

Проблемът обаче е, че стандартната процедура е дефинирана при незаключен процесор. Не е ясно какво и как заключват STM. Обикновено се заключва и jtag-а, за да няма никакъв шанс, но при ST оставам с впечатление че jtag-а не се заключва. Това е леко притеснително, щото като имаш достъп до проца трудно ще защитят флаша. Предполагам и заради това не го документират много-много... Най-вероятно ако усетят дебъг сесисия откачат флаша докато не ресетнеш. Потенциалните дупки обаче са твърде много. Първо дебъг сесията е разтегливо понятие, не могат всичко да прихванат. Второ с тоя проц дето може да бутва от рам може да му се налее нещо в рам-а да се мине през ресет колкото да се изчисти дебъг сесията и т.н. и т.н. С две думи много ме съмнява че заключването е надеждно.
Засега обаче мен ме вълнува повече отключването. Надявам се да става само през jtag, но за всеки случай вързах и UART1 и достъп до буут пиновете. Ще видим...


Ooo ако останеш с тоя проц още много пъти по 3 дена ще се мъчиш... Няма по калпаво проектирани и по-зле документирани арм-чета от тия на ST, или поне аз не съм срещал такива

Конкретно още не съм пробвал отключване и не мога да дам акъл. Обаче за ръчно писане по регистри и т.н. в никакъв случай не бих ползвал IAR или друг дебъгер. Единствено gcc ти дава достъп до jtag емулатора но най си е добре без посредници. Инсталирай си OpenOCD то би трябвало да поддържа твоя jlink, настройваш го да конектне и след това си отваряш конзола и си четеш/пишеш регистри, памети, всичко. Първо проверяваш с RAM дали наистина четеш и пишеш правилно, после периферии и каквото ти трябва...
Знам че конзолите не са ви любими но само така може да разбереш дали имаш проблем с комуникацията, дали с писане и т.н. Иначе приложенията с мишка също са готини, един клик с мишката и готово... Ако работят ОК, обаче ако не работят много трудно ще разбереш защо не работи.

Не, JTAG-а не се заключва. Но през него работи само отключването, всички други команди пропадат. Включително erase ... което поне на мен ми е странно.

А при отключване се активира автоматично ERASE процедурата. И трябва да дропнеш захранването, за да тръгнат другите функции на JTAG-a.
Бая мътна каша. Ама така си е от STR сериите още. Знам, че в ценоразписите на китайците държат доста висока цена за разбиване, та явно няма лесни начини.

Дебъг юнита е стандартен от ARM и не може да се бара заради лицензи и т.н. Той няма команди, само регистри и чрез тях се откача проца от шините. Няма дебъг вътре в проца, няма навън. Ако искаш примерно да видиш регистър му пъхаш инструкция която да изкара стойността на шината и от там дебъгера си я взема. Просто и евтино решение...
За всичко се ползва проца. През дебъга му пъхаш инструкции и така достъпваш памети, регистри, периферии. Освен че е просто това има и предимството, че е едно и също и при дебъг и нормален код. И в двата случая все проца върши нещата, съответно сигнали, времена, всичко е еднакво и перифериите няма как да познаят режима. Освен ако не се изкара сигнал, ама едвали ST са барали. То няма как защото идва готов рутиран за силиция. Всяко бърникане рискува да наруши времена и глупусти и АРМ ще искат пари за проверка или ще откажат гаранцията...
Може както луминари без да се бара, сигналите от jtag-a още от корпуса се прихващат и се слухтят. И при определена и много специална комбинация се изтрива флаша и се отключва.

Ами вероятно, защото прекалено много са "нестандартните решения" около заключването и изтриването. Освен това тези "решения" са си така поне от 6-7 години, навремето бъзиках STR9-ки и там имаше същите странности.

Абе като цяло контролера си има "особенности", не отричам. Аз обаче се чувствам комфортно с него. Просто ми пасва, незнам защо, но нито с NXP, нито с Атмел успях да се сработя, а с Луминари даже и не опитах. Докато с това ми е удобно. Въпрос на вкус, казало кучето и....

време мина откакто разреших проблема, но все пак да споделя, нали трябва да се казва развръзката... както беше споменал Цецо през уарт буутлодъра наистина се изтри с тула на ST. Още като се свърза изписа "цпу-то е заключено, искате ли да изтриете чипа наистина...". Изтрих го и се оправи. В този тул има опции и да си бараш опционалните байтове. През jflash явно изтриването не може да реши този проблем.

Дано само докато разработвам софтуера да не се заключва е така за щяло и за нещяло. Тук е и до въпрос на опит, а аз нямам такъв с кортексите на st...

Не съм сигурен дали проблема не е в Jlink. Имаше нещо гнило там с ресета. Нещо ме гложди съмнението, че по неясна причина не може да държи процесора в ресет. И го изтърва, той тръгва и се самопомазва, преди да успее да се конектне. Гадая, но имам чувството, че същия филм го гледах и с едни стари LPC-та.

Може би с друг дебъгер, ще може да се изтрие/отключи и през JTAG-а без ядове.