Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Реализация программированияя Cortex-M0 по SWD
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > ARM
mempfis_
Всем добрый день.

Выясняю возможность программирования одного процессора Cortex-M0 (Freescale, Kinetis) с помощью другого процессора посредством интерфейса SWD.
В документации на свой процессор в разделе Debug ничего как об протоколе SWD, так и о том как с помощью него можно программировать процессор не нашёл.
По самому интерфейсу SWD нашёл несколько диаграмм www.lpcware.com/content/image/diagrams и небольшое описание протокола Introduction to Cortex Serial Wire Debugging, Part One http://www.lpcware.com/content/blog/introd...ugging-part-one.
Также изучаю эту ссылку http://sourceforge.net/apps/mediawiki/stm3...title=Main_Page.

Как всегда разобраться нужно быстро, а времени на всё не хватает. Поэтому хочу спросить у форумчан - может кто реализовывал подобное и может поделиться информацией о самом интерфейсе SWD, протоколе общения с процессорами и инфой о том, как программировать процессор с помощью SWD.
Заранее спасибо.
Golikov A.
Если быстро надо может с другого конца?
Почему именно SWD? может в программируемом проце сделать загрузчик на какой либо другой удобный интерфейс?
SWD - это все же средство отладки, если бы все было просто и открыто, то жетаги делали все кому не лень, а их не особенно много... ИМХО
mempfis_
Цитата(Golikov A. @ Aug 15 2013, 12:44) *
Если быстро надо может с другого конца?
Почему именно SWD? может в программируемом проце сделать загрузчик на какой либо другой удобный интерфейс?
SWD - это все же средство отладки, если бы все было просто и открыто, то жетаги делали все кому не лень, а их не особенно много... ИМХО


У меня есть и загрузчик и полностью рабочий проект.
Задача в том, чтобы вставить в стенд для программирования/тестирования плату вообще без прошивки, а стенд сам её прошил, проверил и выдал результат - рабочая плата или не рабочая. К сожалению в процессоре нет встроенного загрузчика, а есть только SWD. Если заливать свой загрузчик, то придётся изначально все платы прошивать вручную и потом ставить в стенд на прогон. Вот эту операцию я и хочу исключить.
Подобный стенд был сделан у нас для прошивки процессоров LPC. Как показала практика подобное решение значительно сокращает время выхода годной продукции и минимизирует человеческий труд (ошибки).
vetal
20 секунд на arm + google = http://www.pjrc.com/arm/pdf/doc/ARM_debug.pdf
Aner
QUOTE (Golikov A. @ Aug 15 2013, 12:44) *
Если быстро надо может с другого конца?
Почему именно SWD? может в программируемом проце сделать загрузчик на какой либо другой удобный интерфейс?
SWD - это все же средство отладки, если бы все было просто и открыто, то жетаги делали все кому не лень, а их не особенно много... ИМХО

А вот удобнее с SWD и с загрузчиком не нужно мучиться. И если что, то удаленно и отладиться есть возможность.
mempfis_
Нашел ещё такую ссылку http://forum.energymicro.com/topic/692-pro...ebug-interface/
В ней говориться что доступ к регистрам процессорам можно получить с помощью AHB-AP
The AHB-AP is an optional debug access port into the Cortex-M3 system, and provides access to all memory and registers in the system, including processor registers through the SCS.
Думаю если разобраться как это сделать с помощью SWD, то можно получить доступ к Flash Memory Module моего процессора и прошить всю флэш (или зашить только требуемый загрузчик). Думаю стоит копать в этом направлении.
scifi
Цитата(mempfis_ @ Aug 15 2013, 13:54) *
К сожалению в процессоре нет встроенного загрузчика, а есть только SWD.

У Kinetis имеется EzPort. Он сделан как раз для первичного программирования.
demiurg_spb
Я думаю, вам стоит ознакомится с проектом blackmagic (он и по SWD шить умеет...).
В этом проекте вы найдёте массу полезных для вашей задачи исходников.

http://www.blacksphere.co.nz/main/blackmagic
https://github.com/gsmcmullin/blackmagic

Также, думаю будет не бесполезен проект openocd.
mempfis_
Цитата(demiurg_spb @ Aug 15 2013, 14:40) *
Я думаю, вам стоит ознакомится с проектом blackmagic (он и по SWD шить умеет...).
В этом проекте вы найдёте массу полезных для вашей задачи исходников.

http://www.blacksphere.co.nz/main/blackmagic
https://github.com/gsmcmullin/blackmagic

Также, думаю будет не бесполезен проект openocd.


Спасибо за ссылки. Исходники blackmagic написаны понятно. Буду подробно изучать их.

Есть ещё такая ссылка https://github.com/GerhardPaulus/SWD-LINK/blob/master
В файле read.me есть обнадёживающая фраза:
SWD needs only 2 wires (clock and data) and gives you full read/write access to all registers and memories and peripherals of an ARM Cortex M microcontroller.

Как изучу все ссылки - приму решение использовать SWD или прошивать свой загрузчик вручную внешним программатором.


KRS
даташит на SWD протокол есть на сайте ARM.
Реализовать его просто!
Относительно недавно появился CMSIS-DAP, я про него писал!
http://electronix.ru/forum/index.php?showtopic=106268
там фактически есть реализация SWD для Cortex-M3

Писать, читать память у Cortex-M3 ( ЕМНИП у M0 также) довольно просто. Если шить флешь можно обращаясь к регистрам, не как у LPC вызывая функции, а например как у атмела - то можно прошить флешь просто подцепившись к контроллеру. Я так реализовал недавно прошивку SAM3S (питон + FTDI syncro bitbang)
Если по SWD вопросы - спрашивайте, я просто давно реализовывал, когда еще клонов Jlinka не было умеющих по SWD работать, как первые STM Cortex-M3 появились и их надо было шить по SWD.

Еще стоит обратить внимание на исходники OpenOCD - там есть все необходимые функции для работы с DEBUG PORT и т.д.
mempfis_
KRS спасибо за ссылки. Обязательно всё изучу. У меня есть цмсис дап и опеносд. Но я ещё не освоил достаточно информации чтобы веделить необходимый мне код. Думаю покорение свд дело только времени.
skripach
Не знаю как в других кинетисах, в К20 есть EzPort который позволяет записывать и считывать внутреннюю флеш процессора как обычную SPI флешку.
KRS
mempfis_,
из OpenOCD для Вас будут интересны файлы:
arm_adi_v5.*
и
adi_v5_swd.c


я то еще старый OpenOCD модифицировал, он тогда про SWD еще ничего не знал, я просто влез в файл cortex_swjdp.c - теперь вся логика в arm_adi_v5

Так же понадобятся доки - IHI0031 ARM debug interface v5
DDI0419 arm architecture v6m reference manual


и прикладываю коротенькое описание SWD, очень полезное!
mempfis_
Цитата(KRS @ Aug 16 2013, 12:12) *
mempfis_,
из OpenOCD для Вас будут интересны файлы:
arm_adi_v5.* и adi_v5_swd.c

и прикладываю коротенькое описание SWD, очень полезное!


a14.gif
Спасибо за весьма полезную информацию.
mempfis_
Продолжаю заниматься SWD.
Выбрал libSWD-0.5. В принципе смог всё прикрутить к иару, но до результата пока рано т.к. ещё не разобрался каким образом выполнять операции на уровне управления ногами SWD.
Как я понял, для этого необходимо найти файлы, в которых описан jtag_interface

Код
/** OpenOCD as for now use global pointer to driver structure. */
extern struct jtag_interface *jtag_interface;


Оттуда мне необходимы методы
transfer(NULL, bits, mosidata, misodata, 0);
bitbang(NULL, "RnW", 0, &val);


Вот например описание функции libswd_drv_miso_8 в которой необходимо использовать jtag_interface->transfer():
Код
int libswd_drv_miso_8(libswd_ctx_t *libswdctx, libswd_cmd_t *cmd, char *data, int bits, int nLSBfirst){
if (data==NULL) return LIBSWD_ERROR_NULLPOINTER;
if (bits<0 && bits>8) return LIBSWD_ERROR_PARAM;
if (nLSBfirst!=0 && nLSBfirst!=1) return LIBSWD_ERROR_PARAM;

static int i;
static signed int res;
static char misodata[8], mosidata[8];

res=jtag_interface->transfer(NULL, bits, mosidata, misodata, LIBSWD_DIR_LSBFIRST);
if (res<0) return LIBSWD_ERROR_DRIVER;
/* Now we need to reconstruct the data byte from shifted in LSBfirst byte array. */
*data=0;
for (i=0;i<bits;i++) *data|=misodata[(nLSBfirst==LIBSWD_DIR_LSBFIRST)?(i):(bits-1-i)]?(1<<i):0;
LOG_DEBUG("OpenOCD's libswd_drv_miso_8(libswdctx=@%p, cmd=@%p, data=@%p, bits=%d, nLSBfirst=0x%02X) reads: 0x%02X", (void*)libswdctx, (void*)cmd, (void*)data, bits, nLSBfirst, *data);
return i;
}


Искал описание/реализацию jtag_interface в openOCD 0.7.0 и в интернете, но пока безуспешно.
Подскажите, кто занимался этим, где найти описание jtag_interface или примеры реализации.
Спасибо.



Возможно поторопился просить помощи....
Скачал архив openocd-libswd-master.zip в котором упоминается jtag_interface и есть примеры реализации.
Сейчас вечер, разбираться с архивом буду завтра.
Но если кто даст полезные ответы, то буду премного благодарен.
Budek
Здравствуйте всем!
Работаю с stm32Lxx. Обращаю на это внимание, т.к., например, в отличие от 100-й линейки в нем нет некоторых "нужных" регистров, например, flash_cr.
Запустил абсолютно все по SWD (правда долблю его имеюшейся железкой на atmege (с которых как раз и спрыгиваю): стираю, шью прошивку, устанавливаю защиту от чтения (Level 1).
Так вот как раз с последним засада... вернее, установить то защиту могу, а вот снять ее не получается. Еще вернее: снять защиту получается, но после установки RDP в 0xAA обязательно приходится пересбрасывать питание на чипе (по ресету во FLASH_OBR так и остается информация о защите... или ресет не производится). По пунктам (вкратце):
Установка защиты от чтения:
1. заливаю прошивку
2. разлочиваю Option Bytes
3. пишу (по адресу 0x1FF80000) 0xffff0000 - установка Level1 В отличие от StdLib пишу 0x00 а не 0xBB.
4. устанавливаю бит OBL_LAUNCH. сразу происходит сброс чипа.
5. для порядку устанавливаю lock на доступ к Option Bytes (хотя чип сбросился до этого).
Все нормально: наблюдаю мигание светодиода в только что залитой прошивке.
Снятие защиты от чтения:
1. устанавливаю связь с чипом по SWD
2. смотрим FLASH_OBR. да, стоит Level1.
1. разлочиваю Option Bytes
2. пишу (по адресу 0x1FF80000) 0xff5500aa - установка Level0
3. устанавливаю бит OBL_LAUNCH. думаю, происходит сброс чипа... светодиод уже не мигает... прошивку то загубили только что
4. для очистки совести устанавливаю lock на доступ к Option Bytes (хотя чип сбросился до этого... надеюсь).
5. делаю паузу... секунд 30. мало ли, что ему надо.
6. вновь устанавливаю связь с чипом по SWD
7. смотрим FLASH_OBR. Опа! До сих пор стоит Level1.
Возникает мысль: а может защита не снялась? Нет, снялась. Стоит передернуть питание, и при чтении FLASH_OBR вижу в его младших разрядах заветные 0xAA.
К слову: ST-LINKу пересброс питания таргета не требуется: после снятия защиты от чтения он продолжает работать с чипом (читает его очищенную память, льет прошивку и т.д.)
Почему я обратил внимание на отличие от 100-х: в них есть понятие "стереть Option Byte". В 32L я этого не нашел (хотя в мануалах именно на 32L такое понятие употребляют). В StdLib на 32L также нет ничего необычного: все уровни от 0 до 2 устанавливаются абсолютно одинаково.
Что же сделать, чтобы не приходилось пересбрасывать питание на таргете?
Заранее всем спасибо.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.