[MihailS 0]

Разбираюсь с новым для себя зверьком и по ходу возникли вопросы.

Прошу прокомментировать знатоков, правильно ли я понимаю некоторые вопросы.

 

1. После сброса проца запускается бутлоадер и в зависимости от состояния гпио84-87 проц берет команды из флеш/SCI/...

 

2. Не могу понять как производится стирание/чтение/запись данных во флеш из программы. Такое впечатление что только с помощю API от TI. Что за варварский способ, я такого не встречал. В любом случае у поца должны быть команды для работы с флеш.

Я пробовал модифицировать экземпл: разместил переменную в секции по адресу 0х30000, в дебугере гляжу, там она. Далее идет команда присвоения значения - а Хрен вам, как были ff`ы так и остались. Из дебугера могу озушке присваивать данные, а в области флеш дебугер пишет что memory protected, какой-то флаг защиты стоит......

 

 

Пожалуйста поясните концепцию, а то после C51, AVR, MSP430 я пока в идеологию не могу въехать.

[Sauris 0]

1. Да.

 

2. Да, только API от TI. Ну или тулзы - CCS Flash programming plugin, SDFlash, SAUFlash, BHFlashBurn. У проца конечно есть периферийный модуль, занимающийся программированием флеши, но документации на него нет. Скажу больше, он простой, и все длительности импульсов, реально шьющих/стирающих флеш, там формируются программными задержками, поэтому и недокументировано, так как неумелое обращение туда может стать причиной гибели микросхемы. А API техасское вполне доступное, маленькое по размеру и простое.

 

Что касается защиты - после подключения дебаггера защищенные области памяти по умолчанию защищены. Для получения доступа надо разблокировать CSM, как - читайте документацию на него (code security module), или просто смотрите ф-цию Unlock_CSM в GEL-файлах, поставляемых в композере. Там все просто - сначала прочитать содержимое ячеек где расположен пароль во флеше, затем записать пароль в регистры KEY. По дефолту он 0xFFFF. После этой "магии" защита памяти снимается, и можно лазить через JTAG где душе угодно.

Изменено 13 июля, 2012 пользователем SAURIS GmbH

[MihailS 0]

Тогда есть вопрос по пункту 1.

Бутлоадер можно заставить исполнять код из SARAM.

Собственно откуда там код, это`ж ведь ОЗУ, после ресета кода там быть недолжно.

 

[Sauris 0]

Бутлоадер можно заставить исполнять код из SARAM.

Собственно откуда там код, это`ж ведь ОЗУ, после ресета кода там быть недолжно.

Это после включения питания там кода быть не должно. А после резета может быть вполне, резет не всегда бывает толкьо после включения.

[MihailS 0]

А каким образом происходит инициализация PIE Vector in RAM после сброса?

[Sauris 0]

Вопрос не понятен. Любым удобным Вам способом занесения данных в память.

[MihailS 0]

Вопрос не понятен. Любым удобным Вам способом занесения данных в память.

 

Я пока не до конца понимаю процесс размещения программы/данных в памяти.

Попробую изложить то, как я это понимаю. Пример стандартной/простой реализации.

После включения запускается BOOTLOADER, делает свои дела (SPRU963). Согласно GPIO84-87 (Jump to Flash) происходит переход на main(). В программе ENPIE=1 но эта область пуста. Очевидно, что в программе нужно скопировать эту таблицу из flash и все ОК.

НО! Я пока не нашел концов. В экземплах имеется фуцнкция InitPieVectTable(void) (DSP2833x_PieVect.c) в ней и реализовано копирование:

....

void InitPieVectTable(void)

{

int16 i;

Uint32 *Source = (void *) &PieVectTableInit;

Uint32 *Dest = (void *) &PieVectTable;

 

EALLOW;

for(i=0; i < 128; i++)

*Dest++ = *Source++;

EDIS;

 

// Enable the PIE Vector Table

PieCtrlRegs.PIECTRL.bit.ENPIE = 1;

 

}

....

Очевидно линковщик формирует данную таблицу, но где задается ее размещение и вообще описание этогопроцесса, я пока не нашел.

Я пока в принципе не могу понять что и по каким адресам пишется.

Мне интересен процесс записи программы во флеш - не могу найти описание этого процесса.

Еще один момент: CCS настраивается для создания *.out файла программы для debug и release.

Как я понимаю в дебуг прошивке что-то добавляется в код собственно для реализации процесса дебугинга. (Что добавляется и куда пинется в контроллере?)

Если я возьму релиз прошивку(например экземпл) и прошъю, оно должно работать?

 

Буду благодарен за помощь.

 

 

[Sauris 0]

Размещение и адреса секций указываются в .cmd файле для линкера. Там же можно указать для секций, копируемых в память, и содержащих исполняемый код, load и run - то есть расположить физически в одном месте (откуда будут копировать), а выполняться она будет из другого места (куда скопируют).

 

в debug прошивке в сам код ничего не добавляется. Обычно только уменьшается степень оптимизации, либо она отключается вообще, чтобы отладчик в любое время знал, где хранится текущее значение всех переменных. А вот в .out файл добавляется куча информации о символах. Однако они, естественно, не грузятся ни во флеш, ни в процессор вообще, их считывает отладчик прямо из файла. Короче тут все так же, как и при напиcании программ, например, для windows.

Изменено 18 июля, 2012 пользователем SAURIS GmbH

[MihailS 0]

...Там же можно указать для секций, копируемых в память, и содержащих исполняемый код, load и run - то есть расположить физически в одном месте (откуда будут копировать), а выполняться она будет из другого места (куда скопируют)....

 

Да, по поводу копирования.

Как я понял есть два способа работы программы:

1. - Брать код напрямую из флеш. (28335_RAM_lnk.cmd)

2. - Копировать код из флеш в ОЗУ и исполнять его от туда. (F28335.cmd)

 

Я правильно понимаю?

 

А вот описание структуры .cmd файла где можно поглядеть?

[Sauris 0]

Обычно большинство кода выполняется из флеш, и только небольшая его часть может копироваться в ОЗУ. Про примеры cmd файлов ничего не скажу, я их не видел. Описание cmd файлов в документации к линкеру, его быстрее самому написать, чем ковырять что-то готовое.

Изменено 19 июля, 2012 пользователем SAURIS GmbH

[Andron77 0]

А что вы имеете ввиду под Flash API от TI? Эмуляцию EEPROM в области одного сектора флэш памяти?

Для загрузки кода во флэш-память, вам нужно два cmd файла в каталоге проекта - DSP280x_Headers_nonBIOS.cmd и F28335.cmd. Cmd-файл с именем RAM удалите, он указывает линкеру, что код нужно загружать в область озу, при передергивании питания данные теряются.

Для примера выложу свой тренировочный проект под F2808 в CCS4, посмотрите. В проекте нет обращений на файлы запутанных примеров "DSP280x_Examples.h", все данные используемые при компиляции находятся в проекте, ничего лишнего, то есть все предельно прозрачно, как на авр :) Начиная с ассемблерного кода по адресу резета при переходе от Jump to Flash (111), создание векторов прерываний и заканчивая распределением памяти в cmd-файле. Проект компилится и работает без ошибок и зависаний.

Control.rar

[Sauris 0]

А что вы имеете ввиду под Flash API от TI?

 

Flash API и имеем. Например для 281x вот - http://www.ti.com/tool/sprc125

для других разновидностей - другие пакеты

[Andron77 0]

Да, точно, это оно и есть, EEPROM через неё реализуется. Кстати интересный момент, в доках к ней написано, что при обращении к функциям API автоматически отключаются глобальное прерывание и сторожевой таймер, хотя реально это не так, пока принудительно командой это не сделал, перед вызовом функций API, редко, но были зависания.

[MihailS 0]

Cmd-файл с именем RAM удалите, он указывает линкеру, что код нужно загружать в область озу, при передергивании питания данные теряются.

 

Да, действительно при замене файла линкера программа после ресета начала работать заново.

СПАСИБО!

А где содержится подробная информация по структуре *.cmd файла?

[Andron77 0]

Посмотрите этот pdf, многое станет понятным.