ReAl

Зрідка щось пробуючи на 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 лежить.

Так чи інакше, а ця задачка вилазить.

В моєму випадкові потреба виникла тому, що Altera FPGA при завантаженні по SPI вимагає потік молодшим бітом вперед, а порт SSP мікроконтролерів LPC17 працює лише старшим бітом вперед. Якраз нещодавно на форумі хтось обурювався, що у STM8 USART в режимі SPI працює лише молодшим бітом вперед: «і кому такий SPI потрібен?». Та от, мені…

Як я вже писав у публікації Двійкові дані та програма мікроконтролера (це що, я так довго не повертався до цієї роботи?), можна було б зробити власну програму обробки конфігураційного масиву FPGA, в якій врахувати також і порядок бітів. Але пристрій може отримувати прошивки програмованої логіки ззовні, тому хотілося б приймати файли в такому вигляді, в якому їх видає Quartus. Менше буде плутанини.

На щастя, Cortex-M3 має спеціальну команду розвороту бітів. Ця команда … » » »

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

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

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

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

Продовжую набігами знайомитися з мікроконтролерами LPC17xx.
При цьому продовжую лізти на кактус: «щоби швидше», підключаю файли зі стандартної периферійної бібліотеки від NXP. І в черговий раз отримую помилку компіляції. На цей раз — з глибин <sys /reent.h>, який включається до <stdio .h>, якого, своєю чергою, потягнув debug_frmwrk.c з LPC1700 Peripheral Driver Library:

Причому що в збірці arm-kgp-eabi від Klen, що в CodeSourcery — те саме (the same, як сказали б англомовні). Тільки номери рядків відрізняються та CodeSourcery, на відміну від Klen-ового пакету, зібрано без підтримки локалізацій і він каже #if with no expression а не #if без виразу.

Лізу дивитися sys/reent.h »»» І що ж я бачу? …

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

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

4 квітня (2012.04.04) нарешті вийшла «офіційна» версія 4.0 операційної системи scmRTOS.

Попередню версію по виправленні відомих помилок збережено в гілці scmrtos/tags/3.11.

Нова версія зафіксована в scmrtos/tags/4.00 та продовжує розвиватися в scmrtos/trunk.

Дізнатися, що нового в з’явилося в scmRTOS 4.0 » » »

Взяв я трохи поколупати платку з мікроконтролером LPC1768.
Спробував використати стандартну бібліотеку lpc17xx cmsis driver library, щоб трохи менше думати. Звісно, документацію на мікроконтролер все одно читати треба. Але здалося простіше викликати функцію для налаштування потрібної периферії, передавши їй кілька парметрів, ніж самому уважно комбінувати ті параметри в кілька регістрів. Та ще й, можливо, про порядок запису треба буде думати.

З часів інтелівського ApBUILDER-а — програми для генерації коду ініціалізації для MCS-51, MCS-196, … — я всю роботу з периферією завжди робив вручну. Тобто, я і до цього робив вручну, а тим ApBUILDER-ом спробував і відмовився. І знову лише вручну. Читаєш собі документацію на потрібний модуль та й потихеньку пишеш всі ці маски/зсуви. Константи для них у файлах від компілятора чи виробника мікроконтролерів є — і то добре.
А тут — на тобі… Вирішив полінуватися…

Читати про покарання за лінощі » » »