ReAl

Щось останнім часом я практично лише про помилки і пишу. Але тут поруч з поганою новиною є і хороша.

Ще десь перед новим роком виявив біду — у найсвіжішому на той час OpenOCD команда stm32f1x unlock захист зчитування наче знімає, але по тому записати у мікроконтролер нічого не вдається.

На щастя, у мене десь лежала перевірена версія, зібрав її, встановив і все пішло. Вже десь у січні підключився до OpenOCD через telnet, потикався різними командами і з’ясував, що в усі option bytes (окрім readout protection) записані випадкові значення, тобто на довільні сектори flash-пам’яті було встановлено захист від запису, а також попсовано опції SW/HW WDT і інші.

І оце лише на минулому тижні розібрався. Драйвер stm32f1x використовується для роботи з stm32f10x, stm32f0xx, stm32f3xx, але біда лише з stm32f10x. З’ясувалося, що в них захист від зчитування поширюється і на область флеш-пам’яті для блоку опцій. Для двох інших згаданих лінійок цього нема, у документації в табличках окремо відзначено можливість такого зчитування (при захисті з рівнем L1). Можливо, саме тому в коді зчитування опцій з регістрів FLASH_OBR і FLASH_WRPR замінили зчитуванням безпосередньо з адрес 0x1ffff800..0x1ffff80f.

Процедура unlock перед стиранням опцій зчитує їхні значення, щоб під час запису коду дозволу зчитування відновити те, що було. Але ж доступу нема, OpenOCD доповідав, що прочитати не може і йшов далі. Тобто записував випадкові значення, які на той час були у неініціалізованій структурі.

Відповідно, ремонт простий — повернутися до зчитування з регістрів. Зараз патч лежить на узгодженні в їхньому gerrit-і, а я вже користуюся виправленим 🙂

Тему так і не закінчено. Доводиться тримати на столі обидва адаптери — і саморобний на FT2232H, і китайський ST-Link.

Мікроконтролери STM32L011, на відміну від інших STM32L0, мають одну особливість. Якщо флеш стерта (точніше, якщо стерте перше слово флеша, у якому початкова адреса стеку сидить), то незалежно від ніжки BOOT0 мікроконтролер стартує у boot-loader. Зроблено це з метою «полегшити початкове прошивання», але мені лише поважчало.

Біди не було б, якби OpenOCD у комбінації з адаптером на FT2232 з цією ситуацією міг упоратися. Але він чомусь не може прошити флеш. Під’єднується по SWD до ядра, показує вміст вказівника команд десь у діапазоні системної пам’яті, каже, який мікроконтролер побачив і обсяг флеш-пам’яті, а от шити відмовляється. Цей же OpenOCD з адаптерами ST-Link, що з «чесним» з плати STM32F3DISCOVERY, що з китайським, — перешиває.

Іноді потрібно стерти геть усе, через що влетіти у бут-лоадер, а плату DISCOVERY, у якої є reset, використовувати як програматор мені трохи незручно.
От тому лежать на столі два адаптери.

p.s. Про всяк випадок повторю: якщо не зупиняти основний генератор (не піднімати біт SLEEPDEEP у регістрі SCB->SCR) і не перепрограмовувати ніжки, потрібні для SWDIO/SWDCLK, то цілком можна обійтися китайським ST-Link-ом. Інакше — доведеться шукати/робити інший програматор або додавати кнопку reset і вчитися її відпускати у потрібний момент 🙂

Щоб вже закінчити вчорашню тему.

Витягнув із шухлядки плату STM32F3-Diіcovery — на ній є вбудований ST-Link, який можна відключити від процесора на платі і використовувати для програмування інших плат. На штирі виведено всі сигнали, включно з RESET і SWO. До речі, перемички розривають лише лінії SWCLK і SWDIO, тому свою плату можна скидати, натиснувши кнопку на платі Discovery.

Ну що — все працює, RESET піднімає мікроконтролер зі Stop-у і перепрошиває. Тобто проблема в тому, що клон ST-Link з Ali-Express-у не вміє виконувати відповідні команди.

Коли вже знову сів за макетку з STM32L051, то перевірив і роботу команд stm32lx lock / stm32lx unlock і швидкість програмування. У клонованого ST-Link тут теж щось в генотипі порушене, бо набагато повільніший. Хоча в ньому стоїть STM32F101, тобто USB зроблене програмно, тому швидким він і не може бути, але ж одиниці кілобайт на секунду не така вже й велика швидкість.

Результати тестування на швидкість (файли для прошивки 2-12kB).
Команда “reset init” перемикає STM32L0x з внутрішнього MSI 2 MHz на HSI 16 MHz і піднімає частоту обміну.

Платку з FT2232D діставати було ліньки, на цих швидкостях має бути не набагато повільніша за FT2232H, хіба ото не зможе виставити 2.5 MHz частоти SWCLK, буде 2.

Точніше, «Stop і не-Reset».
І не STM32L011F4, бо у Імраді їх нема. Граюся на а STM32L051C8T, поки дрібніші кристали їдуть.

Cortex-M, зокрема STM32F10x і трохи раніше LPC176x, я вже трохи помацав у невеликих «одноразових» проектах. У виробах досі йшли ATmega48PA, хоча не все влаштовувало і поглядав на нові можливості нових ATtiny (можна погортати назад, я писав, що мене цікавить). Запитуючи про ціни-доступність цих кристалів, мимоволі роззирався навкруги, як на старіші MSP430 та 8-бітні PIC-и, так і на STM8L, які теж мають цікаві можливості. Та останнім заважає біда — вибір між 16-мегагерцовим RC (забагато, навіть якщо для ядра поділити частоту — багато їсть сам генератор) і низькочастотним low consumption, якого малувато і який має доволі великі початковий розкид і нестабільність частоти.

Так потихеньку доповз і до STM32L0. Аналоговий компаратор, хоч і повільніший, ніж в AVR, але ж пару мікроампер, а не 70, LPTIM1, який може слухати компаратор при зупиненому ядрі і маршевому RC, і, головне, MSI-генератор, який зменшує споживання при зменшенні частоти (привіт, MSP430, я вас ціную, та так до вас і не дійшов). Все, «беру».

Ті «товстіші» Cortex-M я програмував через OpenOCD/JTAG і платки на FT2232D/FT2232H, яких у мене вистачає. Тут же потрібен SWD. Ну що, «досить самому ліпити адаптери», Ali-express, копійчаний клон ST-Link v2, побігли.

І тут вилізла проблема. Якщо програма використовує ніжки SWCLK/SWDIO для себе, або якщо ядро йде у Stop, зупиняючи генератор, то для перепрошивки необхідно смикнути кристал за Reset і потримати на ньому під час з’єднання, параметр connect_assert_srst для OpenOCD. І от чи то всі ці китайські клони, з якими взагалі йдуть 4 дротики (SWDIO, GND, SWCLK, VCC для STM32 і RESET, GND, SWIM, VCC для STM8), не вміють смикати за Reset, чи ще що, але з моїм ST-Link v2 для перепрошивки в потрібний момент необхідно тицяти у кнопку скидання вручну.
Не діло.

Згадав, що опис OpenOCD згадував resistor hack, який дозволяє для FTDI-них адаптерів працювати з SWD. Дописав потрібні рядки у конфіг для своєї плати на FT2232H, спробував — все чудово працює. Ото недаремно мені такі адаптери завжди подобалися 😉

Десь у мене лежить кілька незапаяних FT2232D і ще 2-4 штуки можна зняти із зоопарку платок, який зібрався за минулі роки. Накидаю я luminary-icdi-подібну плату і притулю її до чергового замовлення експериментальних зразків.

Доповнення: оскільки через «справжній» ST-LINK v2 на платі STM32F3DISCOVERY все працює, це точно генетичний дефект клона. Кажуть, його можна перепрошити на інший, кращий програматор, але зараз не до того.

Зрідка щось пробуючи на LPC1766, вже доволі тривалий час не зазирав у новини OpenOCD. Як зібрав колись 6-тої версії, так і працював. Ще раніше, коли робив собі плату на FT2232H, трохи промахнувся і керування драйверами зробив несумісним з жодним з підтримуваних OpenOCD 6.x адаптерів. Тому для роботи з кортексами діставав напівмакетку (плата з FT2232D та шинником, перерізана на сумісність з Amontec JTAGkey).

А оце підтягнув git-ом свіжий стан, а там вже 8.0. А з 7.0 вже для FTDI/MPSSE підтримується довільне призначення службових виводів (reset, керування драйверами). Навіть краще, ніж в avreal, бо можна задати довільне своє ім’я сигналу, прив’язати його до ніжки і керувати ним командами OpenOCD — інтерактивно або з командного рядка. Додав у makefile в частині формування командного рядка вмикання червоного світлодіода на початку програмування і вимикання в кінці. Все чудово запрацювало, через FT2232H програма зашивається у півтора-два рази швидше, ніж через FT2232D, веріфікується у три-чотири рази швидше. І таке враження, що і через FT2232D свіжа версія OpenOCD працює відчутно швидше, ніж 6.x, але вже ніде перевірити, а спеціально збирати ліньки.

І дуже вчасно я сьогодні (хм… вже вчора) за це взявся — через хвилин двадцять після того, як зберіг на флешку конфігураційний файл та приклад makefile, подзвонив колега і сказав, що на роботі полетів J-Link. А там у мене точно така ж плата з FT2232H лежить.

Інформація, яку видає OpenOCD при звичайному завантаженні програми у flash-пам’ять мікроконтролера, деколи може допомогти так, як наче це був запущений зневаджувач.

Переписую на свій смак шматки, які вже працювали зі стандартною бібліотекою від NXP. При чергових змінах програми вона начисто перестає працювати. Знаходжу дрібну помилку (замість змінної часу повертається константа періоду), виправляю, перешиваю…

Знову висить.

»»» І тут помічаю, що OpenOCD сповістив мене…

Boot-loader в мікроконтролерах LPC17xx очікує 32-бітну контрольну суму перших семи слів прошивки (вміст вказівника стеку, та перших шести векторів) на місці не використовуваного вектора по адресі 0x1C. В це слово записується мінус-сума перших семи слів. Схожим чином перевіряє наявність програми і бутлоадер LPC2000.
OpenOCD вміє «на льоту» генерувати таку контрольну суму при програмуванні мікроконтролера, потрібно лишень в команді flash вказати аргумент calc_checksum (ця команда є у файлі target/lpc17xx.cfg пакету).
Але чомусь він не генерує її для звірки вмісту (верифікації). Причому сам він знає, що мені буде незручно, раніше навіть писав щось таке:

Тобто якщо йому дати для верифікації той же файл, що йому було дано для прошивки, то він видасть помилку в тих чотирьох байтах. Ось нещодавно я в черговий раз підятягнув з репозиторію оновлення, зібрав та встановив свіжісіньку версію, однак маю:
»»» Подивитися повідомлення про помилку верифікації та боротьбу з нею