Freescale Kinetis KE - запис у спалах

Я використовую різні мікроконтролери та мікропроцесори вже багато, багато років, але мені здається, що вона була пригнічена серією Kinetis KE (зокрема, S9KEAZN64AMLC).

17 січня 2015 р. TL; DR:

Freescale підтверджує, що v2.0.0 програмного забезпечення Kinetis Design Studio не працює з цим пристроєм (включаючи власну плату TRK-KEA64 eval). Наразі вони рекомендують використовувати CodeWarrior MCU V10.6.

Segger випустив v4.96a (важливо "a", я використовував v4.96), який виправляє проблему та дозволяє використовувати плату налагодження Segger J-Link Lite CortexM з KDS та мати повну можливість програми / налагодження.

Перед тим, як Segger випустив v4.96a, мені вдалося прошивати мікросхема, перепрограмувавши відладчик OpenSDA на недорогій (15 доларах) FRDM-KL25Z плат eval шляхом перепрошивки програмного забезпечення OpenSDA, що поставляється разом з USBDM (використовуючи v4.10.6.240). Потім я використовував автономне програмне забезпечення "ARM Programmer" USBDM. Я не витрачав багато часу на те, щоб налагодити роботу, оскільки я достатньо досвідчений у налагодженні "oldschool", щоб цього не потребувати. Будь ласка, переконайтеся, що ви встромлюєте "доброякісну" програму в бортову ціль KL25 або це може заважати програмуванню, оскільки бортова лінія скидання KL25 все ще підключена до налагоджувача OpenSDA навіть з відсіканням J11 (див. Повідомлення в блозі Keith Wakeham , пов’язані нижче).

Велике спасибі Еріху Стайгеру за те, що дуже милостиво допомагає мені вирішити проблему та підтвердити свої висновки електронною поштою.

Тепер повернемось до нашого регулярно запланованого питання:

Я побудував тупо-просту плату розриву 3,3 В. У PTA є кілька світлодіодів, підключення UART на PTC, а лінії SWD - на виділені лінії. У цій дошці буквально нічого фантазійного або смішного.

Я використовую J-Link Lite для Cortex-M (J-Link LITE CortexM-9, див. Https://www.segger.com/jlink-lite-cortexm.html ), і під OSX та Windows я отримую той же результат: утиліта J-Link Commander може ідентифікувати мікросхему, я можу читати та писати в SRAM та грати з периферійними пристроями з ручним читанням і записом на правильну адресу, вказується на вхід / вивід. Коли я намагаюся спалахнути пристрій, він не вдається.

$ JLinkExe
SEGGER J-Link Commander V4.94c ('?' for help)
Compiled Oct 31 2014 20:08:55
DLL version V4.94c, compiled Oct 31 2014 20:08:48
Firmware: J-Link Lite-Cortex-M V8 compiled Jul 17 2014 11:40:12
Hardware: V8.00
S/N: 518107921
Feature(s): GDB
VTarget = 3.332V
Info: Could not measure total IR len. TDO is constant high.
Info: Could not measure total IR len. TDO is constant high.
No devices found on JTAG chain. Trying to find device on SWD.
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots
Cortex-M0 identified.
Target interface speed: 100 kHz

J-Link>device skeazn64xxx2
Info: Device "SKEAZN64XXX2" selected (64 KB flash, 4 KB RAM).
Reconnecting to target...
Info: Found SWD-DP with ID 0x0BC11477
Info: Found SWD-DP with ID 0x0BC11477
Info: Found Cortex-M0 r0p0, Little endian.
Info: FPUnit: 2 code (BP) slots and 0 literal slots

J-Link>r
Reset delay: 0 ms
Reset type NORMAL: Resets core & peripherals via SYSRESETREQ & VECTRESET bit.

J-Link>erase
Erasing device (SKEAZN64xxx2)...

(...several second pause while it communicates with the MCU...)



****** Error: PC of target system has unexpected value after erasing sector. (PC = 0xFFFFFFFE)!
---------------------------------------------------------------------- Registers -------------------------------------------------------------------------------------
    PC   = FFFFFFFE
Current: R0   = 00F3E3BE, R1   = 00000001, R2   = 4004801C, R3   = 00000001
    R4   = 00000000, R5   = 00000000, R6   = 000000F4, R7   = 1FFFFD61
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------


Info: J-Link: Flash download: Total time needed: 2.174s (Prepare: 0.894s, Compare: 0.000s, Erase: 0.736s, Program: 0.000s, Verify: 0.000s, Restore: 0.542s)
ERROR: Erase returned with error code -5.

J-Link Lite ідеально підходить (я можу читати і записувати в nRF58122 SoC, інший процесор Cortex-M0, з ним), і пристрій, здається, інакше працює. Я знаю, що Kinetis розблокована, оскільки вони продають свіжі запаси від DigiKey, але навіть тоді команда "розблокування кінети" в JLinkExe вимикається без помилок чи корисної інформації.

У цей час я впевнений, що роблю щось дурне, але я втрачаю те, що це може бути.

Хтось раніше працював з цими пристроями? Як ви їх програмуєте?

редагувати, щоб додати детальну інформацію:

Ще трохи інформації:

Я прочитав, що штифт NMI # увімкнено без скидання (і підтвердив це, читаючи SIM_SOPT), але також, що він має внутрішнє підтягування при включенні. На цій конкретній частині PTB4 знаходиться на штифті 10, який в моїй конструкції не підключається. Відключення штифта NMI не має ніякої різниці. RST # схожий; Він підключений до кнопки, яка спричиняє штифт, а також переходить до J-Link Lite, але зовнішнього підключення немає. Це не має значення, тому що, як і NMI #, штифт RST # має внутрішнє підключення, яке ввімкнено, коли PTA5 налаштовано для скидання.

Дивлячись на синхронізацію зараз ... Без скидання ICS є джерелом тактового сигналу для FLL, а BDIV в ICS_C2 встановлено на 001 (за замовчуванням скидання). Якщо я правильно розумію, це означає, що внутрішній осцилятор 32 кГц множиться на 1024 на FLL, а потім ділиться на 2, роблячи ICSOUTCLK 32 кГц * 1024/2 або 16,8 МГц. Я можу через J-Link CLI перевірити, що FLL заблоковано, прочитавши ICS_S:

J-Link>mem8 40064004 1
40064004 = 50

(Встановлено LOCK і IREFST, це правильно.)

Потім я переходжу до того, щоб переконатися, що на SIM-картці включений годинник флеш-контролера, прочитавши SIM_SCGC. Я також можу швидко перевірити, щоб переконатися, що для BUSDIV в SIM_BUSDIV встановлено нуль, що означає, що BUSCLK є тією ж частотою, що і ICSOUTCLK (тобто вона не поділяється):

J-Link>mem32 4004800c 1
4004800C = 00003000
J-Link>mem32 40048018 1
40048018 = 00000000

Поки все виглядає нормально. BUSCLK - це 16,8 МГц, а тактовий годинник флеш-контролера не встановлений.

Тепер перейдемо до флеш-контролеру. У випадку скидання FCLKDIV дорівнює нулю, і нам потрібна тактова частота 1 МГц. З таблиці 18-2 у KEA64RM видно, що FDIV слід встановити на 0x10.

Невстановлено:

J-Link>mem8 40020000 1
40020000 = 00

Налаштування дільника та перевірка речей:

J-Link>w1 40020000 10
Writing 10 -> 40020000
J-Link>mem8 40020000 1
40020000 = 90

Встановлено FDIVLD і відображається правильне значення в FDIV.

Перш ніж зайти занадто далеко вперед, давайте переконайтеся, що спалах не захищений:

J-Link>mem8 40020001 1
40020001 = FE

KEYEN = 11 (відключений) та SEC = 10 (незахищений). Гаразд. Спробуємо перевірити, чи пристрій порожній:

J-Link>mem8 40020006 1
40020006 = 80
J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>mem8 40020006
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 83

Тут ми бачимо, що біти MGSTAT у FSTAT вказують на те, що пуста перевірка виявилася невдалою, а також, що були знайдені непоправні помилки. Незвичайно. Спробуємо стерти його самостійно:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 8
Writing 08 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

Команда стерти все вдалося. Тепер спробуємо пусту чек:

J-Link>w1 40020002 0
Writing 00 -> 40020002
J-Link>w1 4002000a 1
Writing 01 -> 4002000A
J-Link>w1 40020006 80
Writing 80 -> 40020006
J-Link>mem8 40020006 1
40020006 = 80

Тепер бланк чека в порядку?

На даний момент я вже готовий відмовитись, з'їсти втрати на цих прототипах і піти з процесором від ST, де я ніколи раніше не мав подібних проблем. Документація Kinetis досить ґрунтовна, але вона дуже щільна, і мені дуже важко почати роботу. Я можу перемикати введення-виведення через зчитування пам'яті та доступ до інших периферійних пристроїв, але я не можу за все життя зрозуміти, що не так з флеш-контролером. Я працюю з мікрофоном вже більше 20 років, і подібні труднощі - це те, з чим я ніколи раніше не стикався.

20150102 редагувати:

Тому досі сюди нікуди не йти. Я фактично купив плату eval FRDM-KL25Z (15 доларів від DigiKey) і змінив її, поставивши загальне програмне забезпечення CMSIS-DAP на відладчик OpenSDA і скоротивши J11 відповідно до блогу Keith Wakeham . У мене є бортова ціль (KL25Z), яка виконує просту програму, тому вона не заважає лінії скидання, і я бачу свій SKEAZN64 з OpenOCD і граю з ним, але, на жаль, він також не може його програмувати. Програмне забезпечення Kinetis Design Studio (KDS) не буде спалахувати мій Kinetis, оскільки він говорить, що він захищений, і мені потрібно зробити масове стирання, але OpenOCD (як частина KDS), схоже, не знає, як це зробити. Основна версія git OpenOCD, яку я створила на своєму Mac, розуміє Kinetis, але не конкретну серію KEA, тому я повернувся до квадратної.

Повернення до J-Link ...

@AdamHaun мав справжню гадку, і якщо я встановив тип скидання J-Link (команда rsettype) на тип "6" (Kinetis), J-Link повинен відключити сторожову собаку після скидання ядра. Переглядаючи реєстр WDOG_CS1 (0x40052000), здається, що це так, але все-таки немає кісток. Операція стирання, схоже, виходить з рейок з ПК за адресою 0xfffffffe та кодом помилки -5, а команда "розблокувати кінетику" працює лише в тому випадку, якщо я відключую контактний код скидання за допомогою SIM_SOPT (записавши 32-бітове значення 0x00000008 до 0x40048004). На жаль, якщо я це зробив, процесор не може бути зупинений знову, імовірно, через те, що інтерфейс SWD не може використовувати лінію скидання, щоб примусити SWD DAP перейти в відомий стан.

20150103 редагувати:

У мене блимає світлодіод

ПОВТОРИТИ

У мене блимає світлодіод

Версія TL; DR: розмістіть зображення USBDM на платі FRDM-KL25Z (історія все самостійно), використовуйте окремий додаток ARM Programmer для надсилання тесту .elf на плату. Цикл живлення і вуаля.

Довга версія з'явиться пізніше. Зараз у мене менше 48 годин, щоб написати та відладкувати програмне забезпечення для цієї плати KEAZN64, закінчити модифікацію / тестування іншого програмного забезпечення, яке йде разом із цим, та працювати над деякою документацією для іншого клієнта. Обіцяю , що оновлю це питання детальною відповіддю. Я просто хотів поділитися своїм успіхом. Дякую ВСЯКОМУ за допомогу. Мені, можливо, доведеться поговорити з модниками, тому що я дуже хотів би дати нагороду пару з вас, зокрема.

Я фактично не можу знайти жодних логічних помилок у вашій процедурі, але ось кілька пропозицій:

• також є регістр FTMRH_FERSTAT (в 4002_0007h). Він повинен сказати вам, що пішло не так ... але лише у випадку паритету (або помилок подвійного паритету). Я не впевнений, що це записуватиме щось у випадку помилок або стирань, але, мабуть, варто перевірити.

• У документації KEA також зазначається, що переривання може бути викликане помилками спалаху (розділ "18.3.5 Flash та EEPROM перериває"). Я не знаю, якщо це відбувається, коли SEGGER видаляє його, але це правдоподібне пояснення того, чому ПК теж змінюється, оскільки ви побачили помилки, позначені в реєстрі FSTAT. На жаль, розділ документації KEA для контролера переривання ("3.3.2 конфігурація вкладеного векторованого контролера переривання (NVIC)" досить невиразно вказує у напрямку веб-сайту ARM для отримання повної документації. Я не зміг зрозуміти, чи встановлено обробник перерв за замовчуванням (під час завантаження) для помилок спалаху.

• Ви стираєте стирання лише на рівні сектору вручну, тому спробуйте вручну (як, записавши відповідний реєстр самостійно), видати повну команду стерти спалах; єдиним способом зробити це в одній команді, здається, є "Небезпечна команда спалаху", задокументована в розділі 18.3.9.10 (стор. 246) цього посібника. Це одночасно "незахищено" пристрій, а також виконає повний спалах та стирання EEPROM. Ви можете опитувати біт FSTAT (CCIF), щоб побачити, коли він нібито завершений, і знову перевірити прапори помилок. EDIT: у посібнику також є розділ "18.3.9.7 Команда" Стерти всі блоки ".

• спробуйте нижчу тактову частоту шини. Все, що перевищує 0,8 МГц, працює відповідно до документації. Я пропоную це, тому що на форумі Freescale був один потік, де зовнішній спалах спрацював нормально, але не вище певної частоти, яка все ще знаходилася в діапазоні документально підтвердженого порядку. Тому можливо, що контролер спалаху в мікросхемі є відшаровується і не може працювати на повному діапазоні зазначених частот.

• також, ваша інша фішка. Це немислимо, якщо врахувати, що ці кошти (близько 3 доларів) у вас погані. Я пам’ятаю, мав вбудований чіп x86, який працював чудово в більшості способів, але мав дивні помилки в певних інструкціях із захищеного режиму; моя проблема пішла з іншого пристрою тієї ж марки. Мені незрозуміло, чи Freescale має (публічно заявлене) кроки та помилки для цих пристроїв чи ні.

Це все, про що я можу придумати, з точки зору налагодження пропозицій, про які не говорили інші на цій сторінці.

20150103 редагування:

(Тут переміщені матеріали з моїх коментарів та розширені)

Здається, що не всі серії Kinetis (офіційно принаймні) проходять тестування з усіма мигалками. Досить нова серія EA, яку ви фактично використовуєте, здається, офіційно підтримується лише власним флешмером Freescale / OEM Cyclone MAX; це єдиний перелік на сторінці Freescale для серій EA . Зараз надано, для старих кінетиків, таких як KL0, список набагато довший, включаючи SEGGER . Я не знаю, чи це просто через відсутність тестування інших флешерів для серії EA або якщо насправді є якась химерність програмування, про яку в даний час знає лише їх Cyclone MAX. Я сподівався, що, можливо, це просто Freescale повільно перераховує інші флешмори, але після перевірки керівництва J-link (сподіваємось, правильний), там не вказані серії Kinetis E або EA (стор. 249), як перевірені, а лише пристрої Kinetis K10 до K60 (і деякі старіші MAC7).

Варто зазначити, що програмне забезпечення / програмне забезпечення PExDrv для Cyclone MAX має пакет обслуговування (v10.3) від 20.03.2014, який "додає підтримку похідних MKE04Z64, MKE04Z128, MKE06Z64, MKE06Z128, SKEAZ64 та SKEAZ128". Ще одна підказка полягає в тому, що власне завантажувальне / завантажувальне програмне забезпечення Freescale для Kinetis, незважаючи на те, що оновлено ще зовсім недавно в 12/2014, не вказано жодні пристрої серії E або EA [sub] як підтримувані. Тож я думаю, що щось блимає між E / EA-серією та іншими Kinetis, такими як K10, хоч щось досить інше, хоча я не маю поняття, у чому саме полягає ця різниця. Тому я думаю, що очікувати, що миготіння EA автоматично працюватиме з чим завгодно, окрім Cyclone MAX, ймовірно, на даний момент нереально. Зрештою, ви зможете зрозуміти, як це зробити на рівні "голого металу" (команди прямого реєстру) з документації серії EA, але я згоден, що документація досить тупа; йому, безумовно, не вистачає жодної покрокової інструкції, яка є лише довідковою інструкцією. Якби завантажувач / флеш-завантажувач Freescale підтримував серію E / EA,

Ваш експеримент із FRDM-KL25Z (який поставляється із серією Kinetis L) вказує в тому ж напрямку, тобто ви не можете поміняти L-серію на EA-серію та використовувати ту саму мигалку (OpenSDA у цьому випадку).

І якщо ти схожий на Кіта (блогера), який "вважає, що $ 100 доларів для програміста - це смішно", напевно, ти не будеш задоволений перспективою скинути $ 900 + на цей Циклон. Я не знаю, чи Freescale робить це навмисно, щоб тікати своїх автомобільних замовників чи що ... Це, безумовно, дивно, що інструмент для більшості серій Kinetis не працює з E / EA.

Також майте на увазі, що миготлива функція OpenSDA працює лише під MS Windows .

Якщо ви готові спробувати (зламати) більше дощок, одна з E-серій Kinetis може бути кращою ідеєю, наприклад, FRDM-KE02Z (13 доларів на Digi-Key); також використовує OpenSDA, щоб його можна було зламати. Наскільки я можу сказати, вони не роблять / продають дошки з серії EA. Однак, здається, ви не можете використовувати один процесор / плату OpenSDA для програмування іншого типу Kinetis, ніж той, що знаходиться на його власній платі , навіть якщо обидва процесори в одній і тій же серії (наприклад, L), але різної кількості. На жаль, "Open" у OpenSDA означає, що специфікація SDA є відкритою, а не те, що вони видають вихідний код як відкритий; тому я навіть не можу знайти вихідний код для програмування спалаху серії E. Мабуть, я лише напівправий з цього приводу. OpenSDA v1 не є відкритим кодом, але v2 є .

Тож ось низьке зниження OpenSDAv2 . Це в основному лише завантажувач і флешер CMSIS-DAP / mbed. Таким чином, він може не мати тих самих функцій або підтримувати ті ж мікросхеми, що і v1 ... і це насправді виявляється так, тому що flash_features.h не перераховує жодної MKE (серії Kinetis E), не кажучи вже про SKE (серія EA) пристрої. Підводячи підсумок, пропозиція Freescale для серії EA виглядає так: придбайте нашу Cyclone-флешерку на 900 доларів США або удачі, напишіть свій власний, із будь-яких неповних бітів з відкритим кодом, які ми випустили.

Однак виявляється, що існує проект з відкритим кодом, який може запрограмувати хоча б кінетику серії E, а саме USBDM . Відповідний біт із його журналу змін :

V4.1.6.140 (квітень 2014)

Додаткові пристрої Kinetis (MKE04, MKE06, MK64F)

• Виправлення пристроїв MKE (не вдалося програмувати, за винятком після Mass Erase)

І виходячи з цього запису журналу, очевидно, що серії E є химерними. Немає прямої підтримки для EA-серії (SKE), але ця база коду - це, мабуть, найкраща ставка, якщо ви хочете зламати власний флешер; або, можливо, ви можете переконати автора USBDM додати підтримку серії EA (SKE). Як апаратне забезпечення для USBDM виявляється, ви можете використовувати FRDM-KL25Z, який ви вже придбали; але вам все одно доведеться зламати програмне забезпечення USBDM для підтримки фішок SKE.

Конфігураційний файл майстер для USBDM виглядає досить складним. У USDBM для різних пристроїв серії MKE використовуються різні мигалки (бази коду): для MKE04 та MKE06 використовується те, що називається "FTMRE", але для MKE02 використовується "FTMRH". Коротко оглянувши дві бази коду, ви майже напевно хочете, щоб база коду FTRMH була не такою, як FTRME. Останній має іншу структуру FTMRH, ніж ваш пристрій SKEA64, наприклад, тактовий подільник - це не перше, а четверте поле. FTRME також встановлює FIDV шини на 0x17 = 24 МГц, що здається поза діапазоном для вашого чіпа (стор. 224 в посібнику з KEA64 пропонує максимум 20 МГц). FTMRH встановлює його на 0x0F = 16 МГц (як у вас), що здається нормальним.

На даний момент, (якщо ви не хочете придбати Cyclone MAX), найкраща ставка - зв’язатися з Podonoghue, щоб ваш чіп працював з його кодовою базою. Він здається активним і цілком готовим допомогти з новими пристроями (на форумі фреш-кали) .

Також із цього вихідного коду USDBM я можу пророкувати, що немає можливості, щоб ваш SEGGER правильно спалахнув ваш SKEA, якщо спочатку він не отримає власне оновлення програмного забезпечення. Чому я це кажу? Оскільки база коду FTMRH USDBM використовується саме одним пристроєм там, MKE02, про який, здається, ваш SEGGER нічого не знає (базуючись на його посібнику). Інші, більш поширені пристрої, такі як серії Kinetis L і K, використовують іншу флешку USDBM на основі кодової бази "FTFA". Якщо ви подивитесь на код FTFA , структура регістра флеш-контролера (також починаючи з 0x40020000) для них відрізняється; перше поле - це навіть не дільник годинника, але статичний реєстр тощо. "Чудовий" спосіб Freescale робити не сумісні пристрої ... але користь для розробників флешерів, без сумніву.

Ви спробували це: Розблокування та стирання FLASH за допомогою Segger J-Link

Нібито ви повинні:

Для того, щоб перепрограмувати захищені сектори FLASH за допомогою Segger J-Link, мені потрібно спочатку розблокувати та масово стерти пристрій. Для цього існує утиліта J-Link Commander, яка має інтерфейс командного рядка для захисту та стирання пристрою. Тільки для стирання J-Flash (і Lite) - дуже корисний інструмент, особливо для отримання «чистої» пам’яті пристроїв.

Що мені здалося цікавим, це те, що ви повинні розблокувати його та стерти на наступному кроці, якщо ви хочете, щоб розблокування було постійним:

Але здається, що мені потрібно зробити розблокування з подальшим стиранням, щоб зробити його постійним. Щоб стерти пристрій, я можу використовувати ту саму утиліту командного рядка. Але мені потрібно спочатку вказати ім’я пристрою, а потім його можна стерти (приклад для KL25Z):

EDIT1: додано неправильні дані.

EDIT2: чи можете ви прочитати реєстр Flash Security (FSEC)? Ви пробували?

EDIT3: з використання функцій захисту Kinetis та захисту від спалаху, Rev. 1, 6/2012

Масове видалення за допомогою налагоджувача / JTAG Налагоджувачі та інструменти JTAG мають дуже обмежений доступ до пристрою, коли захищений процесор. Єдині регістри, до яких можна отримати доступ через JTAG, - це регістри стану та керування MDM-AP. Для того щоб дозволити інструменти налагодження незахищених частин, біт 0 реєстру управління MDM-AP може бути встановлений для запиту масового стирання процесора. Щоб використовувати цей метод для відключення безпеки, для FSEC [MEEN] слід встановити значення, відмінне від 10, щоб забезпечити можливість масового стирання. Якщо масове стирання вимкнено, FSEC [MEEN] = 10, спалах проігнорує запит на масове видалення, і пристрій не може бути захищеним за допомогою цього методу. Багато налагоджувачів автоматично використовують біт 2 реєстру статусу MDM-AP, щоб визначити, чи захищено пристрій під час спроби встановити з'єднання. Спливаюче вікно налагодження може бути використане для сповіщення про захищеність пристрою та запитання, чи потрібно масове стирання для незахищеності пристрою. Після завершення та перевірки масового стирання безпека буде відключена. Деякі налагоджувачі можуть автоматично запрограмувати поле конфігурації спалаху, щоб перевести спалах у незахищений стан після завершення масового стирання, FSEC = 0xFE.

Крім того, я наткнувся на пости, в яких згадується, що різні кінетичні сім'ї вимагають різних маніпуляцій з RESET при спробі читання / запису регістра MDM-AP.

EDIT4: Ви спробували додати сильну підтяжку на SWD_DIO? Це постріл у темряві, але Фреска масштабує його.

Ви повинні спочатку зупинити процесор. Очевидно, що ви отримуєте симптом запущеного процесора. Я використовую openocd; перед миготінням пристрою я використовую команду "скинути зупинку". Це "зупинка" - це підкоманда "скидання" для зупинки відразу після скидання, в той час як є також окрема команда зупинки.

Тому шукайте команду "скидання зупинки", просто зупинки буде недостатньо, тому що ви, мабуть, повинні перейти до стану попередньої ініціалізації векторів.

Я ще не бачив цього згадуваного, тому я продовжую і гадаю, що проблема полягає в тому, що ця частина має кеш, який увімкнено під час скидання. Це узгоджується з "дивною" поведінкою, яку ви спостерігали за допомогою порожньої перевірки. Базовий Flash було оновлено, але кеш не був. Щоб виправити це, вимкніть кеш даних і інструкцій, записавши в MCM_PLACRat, F000_300Chа також очистіть кеш, як це робите. Це ж дивне поведінка, ймовірно, і збентежило Сеггера.

Оскільки повідомлення про помилку стосується значення ПК, це здається, що процесор кудись спускається з рейок. Це дальний постріл, але ви намагалися відключити сторожовий таймер?