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

Та значи, гледам че имат 3 нива на защита, доколкото разбирам ниво 2 като се сложи нищо не може после да го отключи, така ли е?
За ниво 1 доколкото разбирам, ако се сложи после може да се вкара в буутстрапа с BOOT пиновете и от там да се изтрие чипа. Не виждам вариант от JTAG/SWD да се изтрие/отключи? Всъщност май може сам да се изтрие, ако вътре има оставен код... Тук малко не ми е ясно дали от JTAG може да се извика такава една процедура, щото казват че не може да се чете, ама не става ясно дали може да се екзекютва,,,

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

Сигурно ще изкочат и други въпроси, па ако знаете някакви изненади казвайте

Ми да си призная, не съм го чел задълбочено, опита ми е от проба - грешка.

Начи аз в повечето устройства си имам собствен бутлоадер. Него го натоварвам или през JTAG (J-Flash) или през вградения бутлоадер (с техния си софтуер от ST сайта). Съответно през j-FLASH-а имам някаква опция Secure Chip, а ако съм през серииния порт, техния софт също има опция Read protect. По мои наблюдения двете се държат аналогично. След програмиране ги активирам и после моя бутлоадер няма проблем да си ъпдейтва апликацията, начи явно не съм активирал Write Protect. А то пише, че се вдигал автоматично, може би защитения регион е върху моя бутлоадер, а не ми захапва апликацията... това не съм го изследвал, както и да е.

Веднъж като гъм го защитил, през вградения бутлоадер не мога да го изчета, тоест мога, ама се замозатрива. Същото е и с JTAG-а, конектва се, ама ни мога да чета, ни мога да запиша нищо вътре, не мога да дебъгвам докато не му кажа unsecure. Това което е различно е, че при JTAG-a след като го "отключа" трябва и да му дръпна и включа пак щепсела, за да получа достъп. Докато през вградения бутлоадер, отключването и последващото нови писане не се нуждаят от гасене на захранване. Двете са взаимнозаменяеми - демек ако го заключа с техния бутлоадер, мога да го отключа през JTAG и обратно, като отключването винаги минава през изтриване.

Та така... документацията съм я прехвърлил отгоре, отгоре за 103, за 40X даже не съм я поглеждал, мислех, че е същата, щото на държание съвпада. Но нямам спомени 103 да е имал няколко нива на защита от четене - имаше просто Read Protect байт, ако вътре има меджик байт начи е достъпен, всичко друго го заключва. Май така беше...

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

уф ядовете с тоя STM нямат край да не отварям нова тема...

Значи ползвам трейс през SWO и всичко си бачка, но досега не бях откачал дебъгера и..... и като го откачих забива на трейса.

Днес си загубих няколко часа да ровя из документациите на тия ST и нищо не открих мамка му

При кортексите на Атмел и на Луминари трейса се пуска през стандартните ITM и TPIU и толкоз. Има - няма дебъгер, си работи!
При SТ допълнително се разрешава и това:
DBGMCU->DBGMCU_CR = DBGMCU_CR_TRACE_IOEN;

От страна на дебъгера съм махнал всякакви намеси, демек не би трябвало да прави нищо повече от превключване на JTAG->SWD плюс дебъг сесия.
Рових из нета... и единственото дето видях е, че някои проверяват дали е пуснат трейса и само тогава трейсват. Естествено и аз мога да го направя така, но е тъпо. В смисъл аз не искам да има разлика в кода и времето на изпълнение. Пък и ме гложди как така няма да работи ?! Това са си стандартни АРМ-овски периферии. Те са си конфигурирани и не зависят от наличието на дебъгер. Единствено ако тия гамени от ST са решили да спират клока, но не мога да го намеря документирано...

некви идеи?

Миро,
не съм имал проблеми с трейса на стм-а. Специялно при пееди (който ползвам и аз) Тихомир пипа разни регстри без да са описани в .ини файла. Трябва да си прегледам хисторито с него (е има вероятност да е на скапания ми диск) кои точно бяха.
Аз ползвам следната функция да детекна дебъгера:

unsigned IsDebuggerPresent(void)
{
return (CoreDebug->DHCSR&1);
}

абе знам как да проверя дали има закачен дебъгер, ама нещо не ме кефи такова решение...

Ще ми се да разбера къде точно е проблемът, нищо чудно и аз нещо да бъркам макар че какво да бъркам... По един и същ начин го правя на всички куртекси, а само на ST грипира без дебъгер. Не вярвам да е от Пидито щото и то един и същ сорс търкаля навсякъде. Най-логичното обяснение е ST да спират клока, ама за какъв дявол да го правят? Пък и да не го документират, не знам...

По спомени пидито при инициализация пишеше по недокументирани регистри....

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

Всъщност ще потвърди ли някой че без проверка умира?


Иначе стандартно проверката е необходима, ако не се знае дали е инициализиран ITM-a.
Тъй като инициализацията зависи от това какъв дебъгер ползваш има логика той да си я прави както си знае. В тоя случай обаче, ако няма дебъгер ITM-а остава неициализиран и естествено при опит за трейс фирмуера ще грипира.
В моя случай поради ред причини съм вкарал всички инициализации във фърмуера и би трябвало да не завися от това дали има или няма дебъгер. Поне до вчера се надявах че е така... Проблемът ми всъщност е, че тия инициализации са ми в ОС-а и сега каквото пипна може да се отрази на един куп други проекти. Та затова ми се щеше да го подкарам това ST без да пипам стандартните инициализации и трейс функции... Ма явно няма да стане

абе какво приложение се ползва за буутлоадерите на тия ST?


Аз видях някакво опън сорсче stm32flash и някакъв техен flash loader demonstrator... обаче като гледам нито едното не поддържа USB?

Не всички имат имплементиран USB боотлоадер в чипа. Само по късните деривати.

http://www.st.com/st-web-ui/static/acti ... 167594.pdf

стр. 13 - 14

Аз съм ползвал вторично наливаем през DFU и се ъпдейтва с един тул от тук:

http://www.st.com/web/en/catalog/tools/PF257916

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

хич не ми върви с тия ST-та

Серийния така и не ми върза, щото се оказа че се разминаваме с пиновете...

DFU-то го имам... обаче как работи не е истина. Четенето е наред. Ако пише това което е прочело няма проблем. Но ако аз генерирам DFU файл само лъже, че пише, даже и verify минава уж, обаче в паметта на проца няма никакво писане...

Може би аз не генерирам DFU файла правилно, не знам... Ама то какво има да му се генерира - пиша му същите версии като тия дето детектва, таргета е 00 демек вътрешен файл, адрес 0ь000000 и някакво бинче... Между другото ако го накрам да конвертира моя DFU обратно до бин изглежда наред...

а... и още един въпрос, че не помня документацията. Ако процесорът е девствен тръгва ли буутстрапа им? Или пак си трябва да се клатят BOOT1/0 ?

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

Иначе за DFU-то... аз навремето съм ползвал за F103 ама там няма вграден и ползвах тяхната имплементация от библиотеките. И там нещата работеха. Обаче с вграден никога не съм пробвал... а и беше преди 3 години, бледнее ми.