Jump to content

    
Sign in to follow this  
prst

TMS320F28335 - формирование .bin файла для записи из внутри

Recommended Posts

Есть уже мной написанный загрузчик через CAN(пропустим особенности, они не нежны). Он получает прошивку, которую помещает в ОЗУ. От туда её нужно записать в DSP Flash чтоб потом нормально с неё загружаться.

То есть, мне нужно записать прошивку, не через CCS, а через внтруннюю FlashAPI, своей программой.У меня TMS320F28335 - как устроено формирование .bin файла я разобрался,

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

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

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

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

Share this post


Link to post
Share on other sites

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

Какой режим загрузки выбран пинами процессора? Вы должны были выбрать Boot To OTP, чтобы сначала стартовал OTP загрузчик, потом передавал управление основной программе. Проблема может быть тут. Если вы заливаете прошивку из CCS, то даже если у Вас выбран неправильный режим загрузки при включении питания, CCS начнёт выполнение программы с нужного адреса.

Share this post


Link to post
Share on other sites
Вообще программатор заливает не bin, а out-файл. Bin

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

Когда я проверял тот же файл слинкованный под старт с флэша - оно работало. Перелинковывал под OTP отказывалось грузиться, и конечно же бут-пины я выставля в соответствии с Flash/OTP.

 

 

Вы формируете на основе out при помощи hex2000.
Ага, так и есть.

 

Стоило бы рассказать весь реализованный алгоритм старта процессора и загрузки новой прошивки.

Да все стандартно, линкуются секции

codestart .initboot .text cinit, .pinit ... итд.

юзается библиотека rts2800_ml.lib которая предоставляет точку входа _c_int00 и она уже вызывает main()

Классика.

 

Пока могу предположить, что Ваш загрузчик неправильно передаёт управление основной программе (Вы говорите, что bin при помощи FlashAPI пишется правильно, всё ложится по нужным адресам).
Щас вопрос не про загрузку. Там я уже разобрался давно. Тут вопрос про то если этот код загружен уже в ОЗУ и из него произвидится запись в флеш, тоесть мне прилетает стрим и я его должен записать, потом перегрузиться и должно работать с новой прошивкой.

 

Какой режим загрузки выбран пинами процессора? Вы должны были выбрать Boot To OTP, чтобы сначала стартовал OTP загрузчик, потом передавал управление основной программе.

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

 

Проблема может быть тут. Если вы заливаете прошивку из CCS, то даже если у Вас выбран неправильный режим загрузки при включении питания, CCS начнёт выполнение программы с нужного адреса.

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

 

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

Но у меня нет столько чипов для экспериментов, да и времени тоже.

 

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

Share this post


Link to post
Share on other sites

Ответте, пожалуйста на следующие вопросы:

1. Какой режим загрузки процессора выбран железно пинами (он не меняется!!!) и, соответственно, с каких адресов стартует процессор при включении питания?

2. Что делает OTP загрузчик после загрузки загрузчика второго уровня в RAM? Каждый ли раз при включении питания происходит загрузка загрузчика второго уровня в RAM?

3. Что делает загрузчик второго уровня после записи прошивки во флэш-память? Каждый ли раз при включении питания происходит загрузка прошивки и её запись во флэш?

 

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

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

 

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

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

 

Да все стандартно, линкуются секции

codestart .initboot .text cinit, .pinit ... итд.

юзается библиотека rts2800_ml.lib которая предоставляет точку входа _c_int00 и она уже вызывает main()

Классика.

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

Share this post


Link to post
Share on other sites
Ответте, пожалуйста на следующие вопросы:

 

1. Какой режим загрузки процессора выбран железно пинами (он не меняется!!!) и, соответственно, с каких адресов стартует процессор при включении питания?

 

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

 

 

 

 

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

 

 

 

 

3. Что делает загрузчик второго уровня после записи прошивки во флэш-память? Каждый ли раз при включении питания происходит загрузка прошивки и её запись во флэш?

 

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

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

 

 

 

 

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

 

1. На плате железно выбран режим Boot To OTP.

2. Проверяем ветку, где не требуется загрузка новой прошивки.

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

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

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

post-63539-1401607494_thumb.jpg

Share this post


Link to post
Share on other sites
И так, Ваш алгоритм старта процессора: (рисунок).

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 но чтото она не работает с моим эмулятором, так что проверить не смог. Какие еще есть варианты?

Share this post


Link to post
Share on other sites
Все так, только за одним исключением, я прыгаю не на 0033fff6, а на EntryPoint, который мне сообщается в бинарике.

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

 

Подскажите тогда сразу по ходу и на другие вопросы - ответы.

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

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

 

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

 

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

Share this post


Link to post
Share on other sites
Есть уже мной написанный загрузчик через CAN(пропустим особенности, они не нежны). Он получает прошивку, которую помещает в ОЗУ. От туда её нужно записать в DSP Flash чтоб потом нормально с неё загружаться.

То есть, мне нужно записать прошивку, не через CCS, а через внтруннюю FlashAPI, своей программой.У меня TMS320F28335 - как устроено формирование .bin файла я разобрался,

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

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

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

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

 

Делал свой бутлоадер кан для данного проца.

Как реализовал:

В флеше а хранил бутлоадер(после ресета прыгал туда).

Бутлоадер по состаянию кан линии либо передовал управление в области памяти C D либо программировал их.

 

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

 

Бинарник получал через композер.

Его настраивал на формирование флеш имаже в формате hex.Далее hex перегонял в бинарник.

Единственной cmd файле надо правильно настроить адреса.

 

Share this post


Link to post
Share on other sites
Делал свой бутлоадер кан для данного проца.

Как реализовал:

В флеше а хранил бутлоадер(после ресета прыгал туда).

Бутлоадер по состаянию кан линии либо передовал управление в области памяти C D либо программировал их.

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

 

Share this post


Link to post
Share on other sites
о, вот комбинировано я еще не пробовал, все время симуллировал, то в флеше, то в озу.

 

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

 

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

 

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

Edited by Vladm

Share this post


Link to post
Share on other sites
Ваш вариант тут предлагался, но не получил одобрения со стороны создателя темы.

 

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

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

Edited by 1108

Share this post


Link to post
Share on other sites
Ну это из даташита на Ваш процессор, по данному адресу должен лежать переход на _с_int00, при выборе старта с флэша. Если у Вас это другой адрес, то на него и совершаем переход.
Не всё так просто, даже не учитывая лишние и не нужные действия CCSа 5.5.

Начну с того что я заметил и потом еще и понял.

-При записи OTP CCS5.5 делает совершенно лишнее действие - стирает секции флэша. Вот совершенно лишнее.

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

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

 

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

 

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

 

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

 

Делал свой бутлоадер кан для данного проца.

Как реализовал:

В флеше а хранил бутлоадер(после ресета прыгал туда).

Бутлоадер по состаянию кан линии либо передовал управление в области памяти C D либо программировал их.

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

Бинарник получал через композер.

Его настраивал на формирование флеш имаже в формате hex.Далее hex перегонял в бинарник.

Единственной cmd файле надо правильно настроить адреса.

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

У меня весь стрим принимается по 2 байта и также и пишется сразу же по 1 слову. (Про эту находку я писал ранее)

 

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

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

 

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

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

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

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

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

Share this post


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

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

code_start:
    .if WD_DISABLE == 1
        LB wd_disable      ;Branch to watchdog disable code
    .else
        LB _c_int00        ;Branch to start of boot.asm in RTS library
    .endif

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

 

 

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

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

__inline void GotoLoadedProgram(){ asm(" LB 0x3DA000"); }
__inline void GotoBootLoader(){ asm(" LB 0x3F7FF6"); }

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this