Есть уже мной написанный загрузчик через CAN(пропустим особенности, они не нежны). Он получает прошивку, которую помещает в ОЗУ. От туда её нужно записать в DSP Flash чтоб потом нормально с неё загружаться.
То есть, мне нужно записать прошивку, не через CCS, а через внтруннюю FlashAPI, своей программой.У меня TMS320F28335 - как устроено формирование .bin файла я разобрался,
но не могу понять как сделать формирование этой прошивки в .bin для записи из ОЗУ внутри.
Когда я получаю прошивку через CAN и записываю +передергиваю питание... она не стартует, а если ту же прошивку записать через CCS, то все работает. кстати если сразу после прошивки начать дебажить, то она работает. Также я проверил содержимое флэша, по тем адресам, что в бинарике, они так же там же находятся в флеше после записи, то есть полностью правильно записываются.
Такая же задача, но с записью в OTP секцию - работает, а вот с записью в флэш - не получается..., возможно что то с линкер файлом.
Помогите плиз разобраться с проблемой, а то уже мозги выкручиваются...

Вообще программатор заливает не bin, а out-файл. Bin Вы формируете на основе out при помощи hex2000. Стоило бы рассказать весь реализованный алгоритм старта процессора и загрузки новой прошивки. Пока могу предположить, что Ваш загрузчик неправильно передаёт управление основной программе (Вы говорите, что bin при помощи FlashAPI пишется правильно, всё ложится по нужным адресам).
Какой режим загрузки выбран пинами процессора? Вы должны были выбрать Boot To OTP, чтобы сначала стартовал OTP загрузчик, потом передавал управление основной программе. Проблема может быть тут. Если вы заливаете прошивку из CCS, то даже если у Вас выбран неправильный режим загрузки при включении питания, CCS начнёт выполнение программы с нужного адреса.

+1 к Boot Mode Select.

Это я знаю. Я формирую именно бинарик. И потом, когда мой OTP скачивает загрузчик 2го уровня, в котором уже FlashAPI, то в нем то я из ОЗУ и собираюсь писать прошивку (также я записывал OTP, потому что через CCS не получалось), согласно тому как устроен бинарик так и пишу, там же указывается и адрес и размер и сами данные. Но почему то оно так не работает с CCS`а. Хотя по идее должно.
Когда я проверял тот же файл слинкованный под старт с флэша - оно работало. Перелинковывал под OTP отказывалось грузиться, и конечно же бут-пины я выставля в соответствии с Flash/OTP.


Ага, так и есть.


Да все стандартно, линкуются секции
codestart .initboot .text cinit, .pinit ... итд.
юзается библиотека rts2800_ml.lib которая предоставляет точку входа _c_int00 и она уже вызывает main()
Классика.

Щас вопрос не про загрузку. Там я уже разобрался давно. Тут вопрос про то если этот код загружен уже в ОЗУ и из него произвидится запись в флеш, тоесть мне прилетает стрим и я его должен записать, потом перегрузиться и должно работать с новой прошивкой.


на данном этапе, в вопросе это по идее и не важно, исходим из того что программа уже в работе...


да, я это знаю.

Кстати я нашел еще другой странный баг. Если в CCS5 зашивать собранный OTP код, он зашивается, но не грузится, а если через такую программу как у меня уже написано(тоесть через FlashAPI принятые байты бинарика сразу записывать то тем адресам что сообщает бинарик) то все записываемое потом работает и нормально бутится с OTP, то настолько странно что у меня мозги вывернулись а попытке понять причину. По идее с CCS нужно нажать F11 и записать без всяких проблем.
Но у меня нет столько чипов для экспериментов, да и времени тоже.

Сегодня кстати вообще пояаился фиерический глюк, при компиляции FlashAPI начал писвть что он не совместим с моим процом, хотя в настройказ проекта установлен правильно, пробовал вчерашний и ранее, новый глюк...

Ответте, пожалуйста на следующие вопросы:
1. Какой режим загрузки процессора выбран железно пинами (он не меняется!!!) и, соответственно, с каких адресов стартует процессор при включении питания?
2. Что делает OTP загрузчик после загрузки загрузчика второго уровня в RAM? Каждый ли раз при включении питания происходит загрузка загрузчика второго уровня в RAM?
3. Что делает загрузчик второго уровня после записи прошивки во флэш-память? Каждый ли раз при включении питания происходит загрузка прошивки и её запись во флэш?


Тут и нужно понимать алгоритм запуска, всю последовательность передачи управления (из Вашего описания не совсем понятно), иначе ничего не должно работать, вобщем ответте на вопросы, а там дальше посмотрим.


Программа в работе, если процессор перешёл на адрес выполнения программы, тут-то у Вас, по-идее, и проблема.


Классика, это когда выбран режим загрузки с флэша, вы кладёте прошивку по нужным адресам флэша и при включении питания она стартует. У Вас же несколько этапов загрузки, так что рассказывайте всё по-порядку.

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




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





выше я уже написал что загрузка 2го не всегда, а только при наличии явного указания для обновления.





у меня отп режим который при старте смотрит нужноли скачивать новую прошивку, если не нужно, старт старой. если нужно то качается 2го уровня, запускается, скачивается полностью фирмваря и записывается вместо старой.

И так, Ваш алгоритм старта процессора: (рисунок).

1. На плате железно выбран режим Boot To OTP.
2. Проверяем ветку, где не требуется загрузка новой прошивки.

В ОТР прошит загрузчик, который должен стартануть основную программу. Основную программу заливаем при помощи CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, процессор должен прийти на нашу точку останова. Если нет, разбираемся, что по каким адресам положили и почему ОТР загрузчик не стартует основную программу во флэш-памяти

3. Проверяем работу второй ветки аналогичным способом.

Если уверены, что программа записывается правильно загрузчиком второго уровня, то заливаем её из CCS, ставим точку останова в начале main, из ССS делаем Reset, далее Run, и посылаем процессору загрузчик второго уровня и эту же прошивку, после перепрошивки флэша процессор должен попасть на нашу точку останова. Если нет, но уверены что во флэш легло всё правильно, то смотрим как передаётся управление загрузчиком второго уровня из RAM.

о, вот комбинировано я еще не пробовал, все время симуллировал, то в флеше, то в озу. Спасибо за совет.


Да именно так и делаю, сегодня как раз дебажил (но еще не до конца). Все так, только за одним исключением, я прыгаю не на 0033fff6, а на EntryPoint, который мне сообщается в бинарике.

Подскажите тогда сразу по ходу и на другие вопросы - ответы.
1) Столкнулся с глюком CCS изза которого пришлось делать все через свою прогу 2го уровня. А точнее, вот создал я прошивку для OTP но при записи средствами CCS (F11) она не стартует после рестарта и разумеется плата с уже установленными пинами в отп загрузку. Но если я записую эту же прошивку своим загрузчиком 2го уровня, то все отлично(только для отп не делаю стирания перед записью). Выглядит как будто какойто косяк в CCS. Но чтото мне подсказывает что это не так. может встречались с таким?
2) Как быть? прошивку для OTP я слелал (допустим уже она финально отлажена) как теперь на производстве массово её прошивать, сотнями-тысячами в день? Вчера начальник сказал это вопрос тоже первостепенной важности и его нужно решить. Разумеется отдавать на завод исходники чтоб они компилили и прошивали, так это точно не способ. Вот как тут быть? Подскажите.
Сегодня нашел прогу C2Prog но чтото она не работает с моим эмулятором, так что проверить не смог. Какие еще есть варианты?

Ну это из даташита на Ваш процессор, по данному адресу должен лежать переход на _с_int00, при выборе старта с флэша. Если у Вас это другой адрес, то на него и совершаем переход.


Вот тут подсказать не могу, с ОТР не работал. По-идее, должна быть возможность прошивки ОТП из CCS. Может какие настройки покопать? Не может ли это быть защищённой областью, где надо какие-нибудь галки или пароли прописать?

Тут, наверное, только google впомощь и на сайте TI можно попробовать вопрос задать.

Ещё раз просмотрел spraaq3 по поводу ОТР загрузчика, пишут, что стандартный On-Chip Flash Programmer должен уметь програмить ОТР память.

Делал свой бутлоадер кан для данного проца.
Как реализовал:
В флеше а хранил бутлоадер(после ресета прыгал туда).
Бутлоадер по состаянию кан линии либо передовал управление в области памяти C D либо программировал их.

В случае режима программирования получал во внутреннюю память бинарник и потом их массивами прошивал во флеш.

Бинарник получал через композер.
Его настраивал на формирование флеш имаже в формате hex.Далее hex перегонял в бинарник.
Единственной cmd файле надо правильно настроить адреса.

Ваш вариант тут предлагался, но не получил одобрения со стороны создателя темы.

На "живом" процессоре часто бывают совсем другие результаты, чем на симуляторе или эмуляторе. Вот "типичный" пример.

Отлаживал программу, которая работала отлично при подключенном эмуляторе, но не работала "вживую". Вот что обнаружилось. Согласно документации, функция ExitBoot() в bootloader 28335 возвращает указатель стека на 0x400. Но в процессе проверки я нашел, что SP при выходе из загрузчика указывает на область ОЗУ M0. Так что, если в программе эта область используется под данные, можно поиметь проблему.

По основной проблеме. Писал почти такую же систему, с одним отличием - менеджер загрузки у меня SPI BOOT - читается из SPI Flash, проверяет флаг в I2C EEPROM, и так же предлагает залить новую прошивку или стартует старую из FLASH процессора. Я прочел Ваши посты, но не понял - Вы проверили весь FLASH, уверены, что по всем адресам Ваша программа через FlashAPI записала то, что нужно? Включая Entry Point? Попробуйте сделать верификацию прошивки через CCS3.

В топике был вопрос как формируется бинарник.
Об этом и был мой развернутый ответ в том числе.

Не всё так просто, даже не учитывая лишние и не нужные действия CCSа 5.5.
Начну с того что я заметил и потом еще и понял.
-При записи OTP CCS5.5 делает совершенно лишнее действие - стирает секции флэша. Вот совершенно лишнее.
-А вот при повторной попытке перезапи OTP с другим адресом старта - оно дописывает биты по адресу старта для OTP 0x380400 - а вот это уже откровенный косяк, так как он то должен быть тоже однократно записываемый... короче я так запорол несколько чипов в экспериментах...
Потом этот идиотский _с_int00 - я нашел на него исходники и продебажил, спечатления что он вообще на фиг не нужен для OTP. Вообще вся библиотека rts2800_ml.lib уже несколько дней мне трахает мозги, по той причине что она не нужна для задачи OTP, вот вообщем как я понял. А еще то что она при выходе с main() перехватывает и отправляет в exit() от куда потом в abort() это рвет сохги в клочья. Короче пришлось сегодня писать хак на асме для непосредтвенного прыжка по адресу хранящемуся в переменной. Тоже кстати та ещё задачка, не зная асма этого проца...

Да я нашёл, оказуется там все просто, пока не обнаружил на днях выше описанный косяк в чипе не понял что это вообще у меня такое было.

Вот чтото ТИ саппорт на многие вопросы не может дать ответа, судя по наблюдениям при поиске последних дней, видать у меня тоже били такое сложные вопросы... и часто даже они просто юлят, что в край было странною наблюдать.

так и есть.


Я попытался тоже так сделал - но когда промучался пару дней с поиском вопроса на ответ, отказался и вернулся к ОТП. А проблема вот какая, когда ОТП-лайк прога в флэшн - её стандартный адрес BEGIN=0x38fff6, но кактолько она скача саму фирмвалю и написала то в BEGIN переписался тоже алрес старта, и разумеется наша ОТП-лайк прога уде ни когда не стартанет. В общем я не нашел и не придумал как это обойти (единственное было с мыслях парсить весь стрим и найдя этот пдоес тупо его игнорить и перехватывать для записи в другое место)
У меня весь стрим принимается по 2 байта и также и пишется сразу же по 1 слову. (Про эту находку я писал ранее)


Я досе часто заглядую в Ваш код поискать чё нить полезное в качестве ответа на вопросы, и часто нахожу... )) Спасибо!


CCS3 не использую, меня от него коробит, кашмарный софт, не удобный ни разу. Но возможно таки прийдется тоже под него проект сделать.
"ExitBoot() в bootloader 28335 возвращает указатель стека на 0x400. " - О да, я несколько дней дебажил, и нашел виновника зла... - RTS2800_ml.lib. Пришлось сегодня писать хак на асме (основан на http://e2e.ti.com/support/development_tool...27/767892.aspx). "Но в процессе проверки я нашел, что SP при выходе из загрузчика указывает на область ОЗУ M0. Так что, если в программе эта область используется под данные, можно поиметь проблему." - ага, с похожим сталкивался тоже. По этому щас *.cmd линкер-файле разбрасываю секции памяти, это еще тоже отдельное "поле для экспериментов" кстати.

Не совсем понял, что Вы хотели этим сказать. Что адрес старта процессора всё время меняется? Так это не так, Вы сами задаёте этот адрес. Если Вы посмотрите мой проект для загрузчика и загружаемой программы (файлы .cmd), то найдёте, что там описывается кусок флэша с названием BEGIN на который ложится секция codestart. В секции codestart располагается асмовская инструкция перехода на _c_int00 (), т.е. на функцию main (см. DSP281x_CodeStartBranch.asm)

Таким образом, не смотря на то что адрес main (_с_int00) может меняться, адрес перехода на _c_int00 всегда остаётся постоянным, и вы его сами задаёте, можете BEGIN положить по любому адресу, который Вам нравится.



А как Вы до этого осуществляли переход? Всё просто, одна инструкция:

Что-то я не понял последовательность в Вашем описании. У меня в cmd-файле для таких кусков записано неcколько описаний секций вроде этого:



После старта мой загрузчик переписывает эти куски из FLASH в ОЗУ (memcpy, как в примере с FlashAPI) и передает туда управление. Эти куски, записанные в FLASH, из самого FLASH работать не могут, ибо содержат заведомо не те адреса, где лежат, а заточены под ОЗУ.



Мне приходится работать именно с CCS3, ибо код основной (рабочей) части весь на ассемблере - реал-тайм приложение, управляющее через PWM силовыми ключами. На С слишком много накладных расходов, не хватает тактов, да и бороться с излишней "оптимизацией" кода не очень приятно.

Третий имеет конечно свои недостатки, но именно в одном он круче и четвёртого, и пятого: он может считать прошивку из разлоченного проца, без отдельных ухищрений вне среды разработки. Проект для этого создавать не надо. Я тоже его для этой цели одно время держал на винчестере.


Простите, а как связано написание основных функций на ассемблере и версия CCS?

Пишу свои функции на асме в 5.5 совершенно спокойно. Оптимизация вообще работать не мешает, с этим в CGTools С2000 всегда всё в порядке было.

Сейчас уже точно не помню, где именно, но когда попробовал в CCS5 поработать с asm-проектом, показалось очень неудобно. Дело привычки, наверное.

Хотя

У меня 2 уровня, Первый сам OTP, который грузит в ОЗУ вторую, промежуточную прогу, Второй - грузит фирмварю, вторая кстати и записывает её в флеш через флэшАпи. Так вот там адрес точки входа то может меняться, не исключено, ибо она а ОЗУ а а будущем неизвестно как всё повернется.


да, я знаю, я так пробовал, распалогал по адресу 0x8000 и от туда успешно грузился способом как вы написали ниже. Но как я уже писал адрес точки схода может поменяться.

Тут только константой задается, если передать вместо 0x3F7FF6 например _var_addr где будет храниться значение адреса, то по факту будет переход по адресу той самой переменной var_addr, а это точно не то, что мне нужно


Если честно я не понял как оно у вас так работает. То что вы описали это классический подход к приложению в флеше. Ведь по идее точка входа даже в вашем случае будет гдето, но чтоб до неё добраться нужно пройти сквозь _c_int00, на адрес который то и будет указывать значение в 0x38fff6.

Так вот о чем я и говорил, что если вместо секции OTP, расположить нашу прогу(А), которая на самом деле OTP, только собранная для старта флеш, то будет её точка старта всё в том же 0x38fff6, и как только она скачает новую прошивку для флеша и перезапишет, то в том же 0x38fff6 уже будет указание не на (А) п на нашу новую прогу. Вот что я имел ввиду. И вот это как побороть я не понял, все пробы что делал не венчались успехом.

Адрес точки входа _с_int00 меняется, но адрес перехода на точку входа _c_int00 не меняется, он через секцию codestart привязан к одному и тому же адресу, т.е. зная этот адрес Вы всегда можете попасть на _c_int00. Для перехода, который выполняет занрузчик при старте программы, удобнее использовать не адрес _c_int00 (адрес самого main), а адрес перехода на _c_int00, т.е. постоянный адрес секции codestart.

Так. Давайте еще раз, с самого начала. У Вас в OTP записана программа-загрузчик (отдельный проект, со своим CMD-файлом). Процессор настроен выбором пинов на "boot from OTP", то есть точка BEGIN вашей проги-загрузчика, описанная в CMD-файле, всегда равна 0x380800. Программа записана раз и навсегда (так как OTP). Она откуда-то (неважно) читает какой-то параметр, и делает выбор - загрузить в ОЗУ кусок с FLASH API и передать туда управление для последующей загрузки и записи нового firmware (назовем его "основная программа" для однозначности) в FLASH, либо сразу передать управление в FLASH на уже ранее записанную программу.

Адрес точки входа (BEGIN) для FLASH всегда равен 0x33FFF6, он же указывается в CMD-файле при сборке проекта основной программы. А уже по этому адресу лежит переход (LB) на _c_int00 основной программы. То есть ваша программа-загрузчик при отсутствии необходимости обновления основной программы всегда передает управление по одному и тому же адресу 0x33FFF6. Что по этому адресу лежит, зависит от ранее прописанного из бинарника кода. А лежит там обычно "LB _c_int00", естественно, с абсолютным адресом, вычисленным при компиляции кода основной программы. Программе-загрузчику этот адрес знать не нужно - достаточно передать управление на 0x33FFF6.

Кусок программы-загрузчика для работы в ОЗУ расположен в проекте в отдельной секции, как и FLASH API, переносится из места хранения (OTP или FLASH, неважно) в ОЗУ через memcpy, адреса хранения в OTP/FLASH (LOAD) и перемещения/выполнения в ОЗУ (RUN) описываются в CMD-файле, как я написал ранее. Их можно задать жестко.

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

То есть все адреса известны заранее. Где наши методы (или понимание работы) расходятся?

все именно так, только вместо 0x380800, должно быть 0x380400
А так, как раз Вами описан классический способ, и как раз подобного поста мне не хватало в начале всего этого пути...

Только отличие в том, что мне нужно не только грузиться по тому что в 0x38FFF6, но и возможно по совершенно другому адресу
самый простой пример, на чипе, в разные секции записаны разные версии, и нужно на них уметь перепрыгивать.
своего рода - мультибут, и главная особенность что точки старта у них могут меняться после перепрошивки каждый раз
То есть, цель сделать чуть более разумный и гибкий лоадер. что вобщем-то, мне кажется, удалось.


Вот тут то и проблема, была, которую я уже пофиксил, что в LD передается только константа... щас я могу гибко перепрыгивать в любое место которое узнаю при записи новой версии передав только переменную с значением точки бута.
Ну и второй момент, приложение может быть собрано в бинарик без всякого там _c_int00, а точнее без библиотеки rts2800_ml.lib, конечно это малая вероятность, но тем не менее не исключено тоже

Что-то Вам всё рассказывают-рассказывают, а Вы всё равно о своём. Для каждой прошивки свой BEGIN, гле лежит переход на свой _c_int00 и адрес BEGIN == const.

Так это я уже давно понял, где-то по теме выше, уже это пару раз рассказывали. Я же говорю о другом совсем(ну или немножко)...
в принципе то что я делаю, это не так уж и важно, оно просто не совсем традиционное.
Но если говорить кратко - то тема помогла решить те вопросы что были ранее ))
По этому всем кто помог прояснить и объяснить непонятные моменты - огромное спасибо! Я стартанул в разных видах свои прошивки, и получил довольно хороший результат, как мне показалось.
А особенно, !спасибо! doom13

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

#pragma CODE_SECTION(Cycle, "MY_SEG");
volatile void Cycle(void)
{
тут у меня инициализация PLL,
настройка порта и просто светодиодная мигалка
}

Сама по себе функция рабочая, светодиод мигает. Ниже мой cmd файл:


MEMORY
{
PAGE 0: /* Program Memory */
/* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE1 for data allocation */

RAML0 : origin = 0x008000, length = 0x001000 /* on-chip RAM block L0 */
OTP : origin = 0x3D7800, length = 0x000400 /* on-chip OTP */
FLASHH : origin = 0x3D8000, length = 0x004000 /* on-chip FLASH */
FLASHG : origin = 0x3DC000, length = 0x004000 /* on-chip FLASH */
FLASHB : origin = 0x3F0000, length = 0x004000 /* on-chip FLASH */
FLASHF : origin = 0x3E0000, length = 0x004000 /* on-chip FLASH */
FLASHE : origin = 0x3E4000, length = 0x003F80 /* on-chip FLASH */
FLASHD : origin = 0x3E8000, length = 0x004000 /* on-chip FLASH */
FLASHC : origin = 0x3EC000, length = 0x004000 /* on-chip FLASH */
FLASHA : origin = 0x3F4000, length = 0x003F80 /* on-chip FLASH */
CSM_RSVD : origin = 0x3F7F80, length = 0x000076 /* Part of FLASHA. Program with all 0x0000 when CSM is in use. */
BEGIN : origin = 0x3F7FF6, length = 0x000002 /* Part of FLASHA. Used for "boot to Flash" bootloader mode. */
CSM_PWL : origin = 0x3F7FF8, length = 0x000008 /* Part of FLASHA. CSM password locations in FLASHA */

ROM : origin = 0x3FF000, length = 0x000FC0 /* Boot ROM */
RESET : origin = 0x3FFFC0, length = 0x000002 /* part of boot ROM */
VECTORS : origin = 0x3FFFC2, length = 0x00003E /* part of boot ROM */


PAGE 1 : /* Data Memory */
/* Memory (RAM/FLASH/OTP) blocks can be moved to PAGE0 for program allocation */
/* Registers remain on PAGE1 */

RAMM0 : origin = 0x000000, length = 0x000400 /* on-chip RAM block M0 */
RAMM1 : origin = 0x000480, length = 0x000380 /* on-chip RAM block M1 */
BOOT_RSVD : origin = 0x000400, length = 0x000080 /* Part of M1, BOOT rom will use this for stack */
RAML1 : origin = 0x009000, length = 0x001000 /* on-chip RAM block L1 */
RAMH0 : origin = 0x3FA000, length = 0x002000 /* on-chip RAM block H0 */
}

SECTIONS
{

/* Allocate program areas: */
.cinit : > FLASHA PAGE = 0 /*память для глобальных переменных*/
.pinit : > FLASHA, PAGE = 0 /*значения начальной инициализации переменных*/
.text : > FLASHA PAGE = 0 /*содержит исполняемый код и константы*/
codestart : > BEGIN PAGE = 0 /*в codestart сщдержится адрес старта программы BEGIN*/
MY_SEG : > FLASHH PAGE = 0
ramfuncs : LOAD = FLASHB,
RUN = RAML0,
LOAD_START(_RamfuncsLoadStart),
LOAD_END(_RamfuncsLoadEnd),
RUN_START(_RamfuncsRunStart),
PAGE = 0

csmpasswds : > CSM_PWL PAGE = 0
csm_rsvd : > CSM_RSVD PAGE = 0

/* Allocate uninitalized data sections: */
.stack : > RAMM1 PAGE = 1 /*системный стек (для сохранения контекста процессора при вызове процедур)*/
.esysmem : > RAMM1 PAGE = 1
.ebss : > RAML1 PAGE = 1
MY_SEG : > FLASHH PAGE = 0
/* Initalized sections go in Flash */
/* For SDFlash to program these, they must be allocated to page 0 */
.econst : > FLASHA PAGE = 0 /*инициализация констант (для языка С)*/
.switch : > FLASHA PAGE = 0

Flash28_API:
{
-lFlash2809_API_V100.lib(.econst)
-lFlash2809_API_V100.lib(.text)
}
LOAD = FLASHA,
RUN = RAML0,
LOAD_START(_Flash28_API_LoadStart),
LOAD_END(_Flash28_API_LoadEnd),
RUN_START(_Flash28_API_RunStart),
PAGE = 0


/* Constants caching */
ramconsts : LOAD = FLASHB, PAGE = 0
RUN = RAML1, PAGE = 1
LOAD_START(_RamconstsLoadStart),
LOAD_END(_RamconstsLoadEnd),
RUN_START(_RamconstsRunStart)

/* Allocate large memory blocks section: */
data_mem : > RAMH0 PAGE = 1
data_mem2 : > RAMM0 PAGE = 1

.reset : > RESET, PAGE = 0, TYPE = DSECT
vectors : > VECTORS PAGE = 0, TYPE = DSECT
}

Данная функция записывается в SECTORH. Но вот никак не могу запустить этот код из моей функции main. Пробовал так:

int main(void)
{
asm(" LB 0x3D8000");
}

и так:

int main(void)
{
jumpToAppEntry();
}

где jumpToAppEntry(), взятая с форума ti, где обсуждали подобную тему.

_jumpToAppEntry:
SETC INTM;
ZAPA;
MOV @SP,#0;
PUSH ACC;
PUSH AL;
MOV AL, #0x0a08;
PUSH AL;
MOVL XAR7, #0x3D8000;
PUSH XAR7;
POP RPC;
POP ST1;
POP ST0;
POP IER;
POP DBGIER;
LRETR;

В результате после выполнения asm(" LB 0x3D8000"); или jumpToAppEntry(); всегда в отладчике появляется сообщение : No source available for "0x3d8000"

Люди, помогите разобраться. Что я делаю не так?

Тут было начало разговора, можете глянуть, возможно найдёте что-нибудь полезное.


Так и должно быть, программа уходит в область памяти, которая ей не принадлежит.

Ту тему читал в первую очередь. Ничего, что могло бы мне помочь я не нашел. Кстати процессор TMS320F2809. Может будут еще мысли какие нибудь у кого? Буду очень признателен, а то уже отчаялся.




Возможно я чего то не до понимаю, но ведь именно по этому адресу расположена моя функция, которую я хочу запустить. Собственно я видел это отладчиком.

Не совсем понятно, что Вы хотите сделать. Этим переходом LB 0x3D8000 хотите попасть в функцию Cycle()? А Вы уверены, что 0х3D8000 это её адрес в памяти?

Лучше опишу конечную цель - это CAN загрузчик. Этим примером я хотел отработать некоторые механизмы этого процесса. Данной темой раньше не занимался и возможно, а скорее точно думаю не совсем в правильном направлении.

Сам процесс вижу так: В секторе А, В и т.д. может располагаться основная программа, которая также работает и с CAN. Если приходит команда о перепрошивке, то необходимо запустить загрузчик, который заранее записан в сектор Н и этот загрузчик уже сотрет необходимые страницы памяти и запишет в них основную программу, которую по-блочно будет получать по CAN. С чего начать и на что особенно необходимо обратить внимание? С записью и стиранием флешки я разобрался.



В CCS смотрел отладчиком сектор Н и там начиная с адреса 0x3d8000 были данные моей функции Cycle();. Чтобы удостовериться, что это данные именно этой функции, я вызвал эту функцию напрямую из main и убрал строку #pragma. Данные с сектора Н исчезли, зато тот же самый порядок байт оказался в секторе А. Отсюда я сделал вывод, что в первом случае в секторе Н по адресу 0x3d8000 находилась моя функция Cycle();

В той теме, если не ошибаюсь, этот процесс расписан. Должно быть две прошивки: одна - загрузчик, вторая приложение. У каждой свой cmd-файл, описывающий память в которой располагается соответствующая программа (загрузчик/приложение). Области памяти загрузчика и приложения не пересекаются.
Возможный вариант работы - при включении питания стартует загрузчик, проверяет записано ли приложение, если записано, то переходит на адрес основной программы. Если подробнее, при включении питания процессор стартует с адреса BEGIN (для f2812 было 0x3F7FF6), там лежит переход на _c_int00, запускается загрузчик. Далее если условия совпали осуществляется переход на BEGIN_APP (адрес старта приложения), тут лежит переход на _c_int00 программы приложения.

PS:
В той теме был пример загрузчика и приложения.

Скорее всего у меня не получалось, потому что cmd файл получался один на оба приложения. Пример скачал.

Спасибо за помощь!

Еще раз всем привет. С прыжками и выполнением программы разобрался. Большое спасибо doom13!!! Но всплыл еще один момент, касающийся утилиты hex2000. Пытаюсь преобразовать out файл в bin. Вот что я ввожу и вот, что мне выдает эта прога:

F:\hex2000>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2 F:\hex2000\LED.out
>> warning: invalid option: --pllcr=10
>> warning: invalid option: --divsel=2
Translating F:\hex2000\LED.out to Binary format...
>> application error: reading 2 bytes at position 0, which accesses data
beyond the end of DATA_MAP 0x0018FE20 of size 0
"F:\hex2000\LED.out" ==> .text (BOOT LOAD)
"F:\hex2000\LED.out" ==> codestart (BOOT LOAD)
"F:\hex2000\LED.out" ==> ramfuncs (BOOT LOAD)

F:\hex2000>

При этом файл LED.b00 создается, но я не уверен, что он корректный. Программе не нравятся параметры ключей, которые я ввел. Собственно их я взял где то тут на форуме. Где можно прочитать про эти ключи, если конечно причина в них?

У нас использовался ACII-HEX формат, загрузчик сам конвертил данные и записывал по нужным адресам.

Понятно, посмотрю структуру hex файла. Возможно тоже передам функцию декодирования загрузчику. Спасибо Вам большое за помощь!

doom13, а не подскажете про формат ASCII-HEX? CCS мне с генерировал сам файл, начинается он так:

$A3f0000,
02 04 5F 5A 42 5F 42 00 1F 17 42 AB 32 02 20 02 04 5F 5A 42 56 42 00 1F


Но в процессоре на самом деле данные по адресу 0x3f0000 такие:
2902 2904 565F FF5A 0642 565F 1E42 0200

Т.е. в ASCII-HEX отсутствует старший байт. Может в CCS есть настройка какая то для этого, я не нашел?

Если генерить обычный hex, формата : :100000001FC0FECFFDCFFCCFFBCFFACFF9CFF8CF8B То данные в нем такие же, как и в ASCII HEX, т.е. без старшего байта

Правила преобразования смотрите в Assembly Language Tools User’s Guide (если spru513 то раздел 11.11).

Разобрался, большое спасибо.