Jump to content

    

Recommended Posts

Ну и второй вопрос:

На сколько я понимаю, для того чтоб мне слали то что я должен буду своим бутлоадером обновить, то это должен быть бинарик в формате *.bin. Который я должн буду предоставить, чтоб мне его отправили по CAN.

Как в хекс знаю, но это ж не то...

Так вот, а как правильно его с *.out сконвертировать в *.bin?

 

На этот вопрос похоже нашел решение

Сделал make_bin.bat.

Но не знаю правильно ли - нет возможности проверить результат в реале на железе...

 

rem C:\ti\hex2000.exe -boot -i -spi8 -spibrr=6 -pllcr=9 C:\ti\myprojects_v4\qwerty\RAM\qwerty.out 
  echo "    ======  MAKE BINARY FORMAT ==> *.bin  ======"
  hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2  ../Debug/28335_Boot1st_OTP2CANRAM__git.out

 

Выдало:

d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>make_bin.bat
  d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>echo "    ======  MAKE BINARY FORMAT ==> *.bin  ======"
  "    ======  MAKE BINARY FORMAT ==> *.bin  ======"
  
  d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2  ../Debug/28335_Boot1
  st_OTP2CANRAM__git.out
  Translating to Binary format...
     "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .InitBoot         (BOOT LOAD)
     "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .text     (BOOT LOAD)
     "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .cinit    (BOOT LOAD)
     "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> ramfuncs  (BOOT LOAD)
  d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>

 

Ну и выходной файл с именем 28335_Boot1st_OTP2CANRAM__git.b00, походу нужно просто переименовать в .bin чтоб не было путаниц в будущем

Share this post


Link to post
Share on other sites
Но я вот чего еще не могу понять, запутался окончательно...

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

Так вот, как я понял: Флэш секция-А начинается с 0x338000, а почему то я встречаю часто что бут делают с 0x3F7FF6

 

Если у нас конфигурационными ногами выбран режим старта с флэша, то процессор начинает исполнение программы с адреса 0x3F7FF6 (В Вашем случае его можно поменять, т.к. загрузчик сам будет "прыгать" на нужный адрес). Чтобы при этом произошёл старт выполнения программы, по этому адресу необходимо разместить "точку входа". В .cmd файле есть область с названием BEGIN (стандартно 0x3F7FF6) и туда положить секцию codestart. В секции codestart и размещается код, который отвечает за дальнейший старт программы:

 

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

 

Для примера можете глянуть мой проект (файлы DSP281x_CodeStartBranch.asm, Flash2812_BootLoader.cmd, F2812_Loaded_Program.cmd).

Для загружаемой программы BEGIN разполагается уже по другому адресу.

Edited by doom13

Share this post


Link to post
Share on other sites
http://www.ti.com/lit/an/spra958l/spra958l.pdf тоже об этом говорят на стр:32 только сказано что для моего проца это должен быть адрес 0x3F7FFE так как у меня TMS320F28335.

0x3F7FFE это Jump-to-Flash, НО! У меня то OTP бут-пины буду всегда...(как и когда с него прыгать в влэш, это уже другой вопрос)

И ведь, 0x3F7FFE это судя по карте, это зарезервированное и неиспользуемое адресное пространство.

 

Так почему бы не прыгать сразу в начало флэша 0x338000 ?

 

Из приведённого Вами даташита следует что для Вашего процессора таким адресом является 0x33FFF6, т.е. ROM bootloadef (factory bootloader) при включении питания и выбранном режиме "Boot to Flash" переходит на адрес 0x33FFF6. По данному адресу располагается инструкция перехода на точку входа для си программы _c_int00:

 

    .ref _c_int00 

    .sect "codestart" 
    LB _c_int00                    ;branch to start of code 

    .end                              ;end of file CodeStartBranch.asm

 

Если вы расположите (привяжите) эту инсрукцию в начале флэша то тоже будет работать, при условии, что будет осуществлён переход на этот адрес, а это уже забота Вашего OTP загрузчика (первого уровня, если по can ничего принимать не будем) и загрузчика второго уровня (если загрузили прошивку по can и хотим её стартануть). Если стандартный адрес старта иэ флэша не меняем, то Ваши загрузчики (первого и второго уровня) должны осуществлять переход на адрес 0x33FFF6, где и должен располагаться:

 

LB _c_int00

 

 

 

PS. На 32-33 страницах вышеуказанного даташита и показана привязка перехода на точку входа к адресу старта (только адрес не Вашего процессора).

Share this post


Link to post
Share on other sites
Ну и второй вопрос:

На сколько я понимаю, для того чтоб мне слали то что я должен буду своим бутлоадером обновить, то это должен быть бинарик в формате *.bin. Который я должн буду предоставить, чтоб мне его отправили по CAN.

Как в хекс знаю, но это ж не то...

Так вот, а как правильно его с *.out сконвертировать в *.bin?

Если не ошибаюсь, то утилита hex2000.exe не умеет из .out файла сразу сделать бинарник, который можно было бы просто положить во флэш, а потом читать. Она умеет конвертить .out файл в несколько форматов (всегда пользовался ASCII-Hex форматом), но ни один из них ни есть бинарник. Т.е. чтобы записать во флэш нужно, чтобы загрузчик умел преобразовывать принимаемый поток в бинарный - плохой вариант.

Тут упоминается такая штука как hex2array, она уже умеет конвертировать из ASCII-Hex в бинарник. Я на основании данного документа немного адаптировал её под себя и использовал для преобразования ASCII-Hex в бинарник. Работает как при использовании оции -boot для hex2000.exe, так и без неё.

 

 

Ну и выходной файл с именем 28335_Boot1st_OTP2CANRAM__git.b00, походу нужно просто переименовать в .bin чтоб не было путаниц в будущем

 

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

 

Share this post


Link to post
Share on other sites
Если не ошибаюсь, то утилита hex2000.exe не умеет из .out файла сразу сделать бинарник, который можно было бы просто положить во флэш, а потом читать. Она умеет конвертить .out файл в несколько форматов (всегда пользовался ASCII-Hex форматом), но ни один из них ни есть бинарник. Т.е. чтобы записать во флэш нужно, чтобы загрузчик умел преобразовывать принимаемый поток в бинарный - плохой вариант.

Тут упоминается такая штука как hex2array, она уже умеет конвертировать из ASCII-Hex в бинарник. Я на основании данного документа немного адаптировал её под себя и использовал для преобразования ASCII-Hex в бинарник. Работает как при использовании оции -boot для hex2000.exe, так и без неё.

 

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

hex2array - это для С6000, я сегодня попытался её завести, но что-то как-то оно криво работает, не стал время тратить, файл открывает, но не читает...

Но больше всего я решил потратить время на разбирательство что ж такого из себя представляет бинарик который на выходе hex2000.exe. И судя по тому что я понял, это правильный бинарик, тупо бин всего стрима для программы, без всяких заполнений лишних... По крайней мере, результат совпадает с несколькими hex2bin конверторами.. Далее, я начал исследовать что внутрях бинарика, и вот каково же было моё удивление, что оказуется, тот пример, что предоставляет Тексас для бутлоадера, как раз и есть самый простой парсер этого бинарика... Тоесть они его сразу разворачивают в память из потока. и потом тупо возвращаяет указатель на точку старта который в бинарике идет после 18го байта. Короче, то что я мучался когда писал свой загрузчик первого уровня, все коту под хвост, ибо одно и тоже, только у меня перемудренне и с развернутой инициализацией..., а у тексаса все намного проще.

 

А вот второго уровня не зря писал. И вот по нему у меня остались вопросы. Я чтото запутался вкрай. Программа допустим размером в 4 флэшовых секции, так вот нужно в DSPFlash начинать писать с секции A или к примеру с секцции D? Если писать с D то получается красивое нарастание адреса пока не дойдет до конца секции А, точнее до секюр-зоны.

Если напичнать писать с секции А (ну логично же что А это первая, с неё то и надо начинать, как бы...) то получается идиотизм с постоянным перепрыгиванием (буквой Z по карте адресов) с конца предыдущей секции на начало другой, меняя при этом намерено адреса и анализируя какой хвост дописывать в новую секцию... мрак какойто...

Так вот как правильно писать? Я еще не успел с этим разобраться. Но чтото похоже что правильно так как легче, с секции H->G->F->....->B->A.

Уточните плиз, бо крыша уже едет.

И главное, ни где про это не нашел описания...

 

Из приведённого Вами даташита следует что для Вашего процессора таким адресом является 0x33FFF6, т.е. ROM bootloadef (factory bootloader) при включении питания и выбранном режиме "Boot to Flash" переходит на адрес 0x33FFF6. По данному адресу располагается инструкция перехода на точку входа для си программы _c_int00:

    .ref _c_int00 
      .sect "codestart" 
     LB _c_int00                   ;branch to start of code 
      .end                             ;end of file CodeStartBranch.asm

Если вы расположите (привяжите) эту инсрукцию в начале флэша то тоже будет работать, при условии, что будет осуществлён переход на этот адрес, а это уже забота Вашего OTP загрузчика (первого уровня, если по can ничего принимать не будем) и загрузчика второго уровня (если загрузили прошивку по can и хотим её стартануть). Если стандартный адрес старта иэ флэша не меняем, то Ваши загрузчики (первого и второго уровня) должны осуществлять переход на адрес 0x33FFF6, где и должен располагаться:

LB _c_int00

PS. На 32-33 страницах вышеуказанного даташита и показана привязка перехода на точку входа к адресу старта (только адрес не Вашего процессора).

Да, с этим разобрался... Кстати, в том бинарике что герерирует hex2000.exe точка входа где находится _c_int00, если сравнить с map файлом, то это она и будет, перепроверил на нескольких файлах... Что все таки намекает на то что генерит то что нужно ;)

Share this post


Link to post
Share on other sites
hex2array - это для С6000, я сегодня попытался её завести, но что-то как-то оно криво работает, не стал время тратить, файл открывает, но не читает...

Можно заюзать и для С2000, разницы нет, формат файлов и там и тут одинаковый (проверено на деле и для С6000 и для С2000).

 

 

Но больше всего я решил потратить время на разбирательство что ж такого из себя представляет бинарик который на выходе hex2000.exe. И судя по тому что я понял, это правильный бинарик, тупо бин всего стрима для программы, без всяких заполнений лишних...

Хотелось бы посмотреть, как из out-файла при помощи hex2000.exe Вы получаете бинарник. Если можно выложите Ваш out-файл и всё необходимое для его преоблазования его в бинарник.

 

 

А вот второго уровня не зря писал. И вот по нему у меня остались вопросы. Я чтото запутался вкрай. Программа допустим размером в 4 флэшовых секции, так вот нужно в DSPFlash начинать писать с секции A или к примеру с секцции D? Если писать с D то получается красивое нарастание адреса пока не дойдет до конца секции А, точнее до секюр-зоны.

Если напичнать писать с секции А (ну логично же что А это первая, с неё то и надо начинать, как бы...) то получается идиотизм с постоянным перепрыгиванием (буквой Z по карте адресов) с конца предыдущей секции на начало другой, меняя при этом намерено адреса и анализируя какой хвост дописывать в новую секцию... мрак какойто...

Так вот как правильно писать? Я еще не успел с этим разобраться. Но чтото похоже что правильно так как легче, с секции H->G->F->....->B->A.

Уточните плиз, бо крыша уже едет.

И главное, ни где про это не нашел описания...

Один из вариантов (на мой взгляд, наиболее удобный) посылать прошивку в виде boot table (про формат boot table почитать можно в spru513 - TMS320C28x Assembly Language Tools). Для hex2000 выставляем опцию -boot и получаем файл прошивки в виде boot table. Тогда загрузчик точно знает по какому адресу и сколько надо записать.

Share this post


Link to post
Share on other sites
Хотелось бы посмотреть, как из out-файла при помощи hex2000.exe Вы получаете бинарник. Если можно выложите Ваш out-файл и всё необходимое для его преоблазования его в бинарник.

А я ж чуть више писал, вот так (ну только можно еще через -o явно задать имя bla-bla.bin)

d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2  ../Debug/28335_Boot1
    st_OTP2CANRAM__git.out
    Translating to Binary format...
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .InitBoot         (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .text     (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .cinit    (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> ramfuncs  (BOOT LOAD)

Сегодня изучал формат бин-файла - один в один как расписано в протоколе для бутлоатера от тексаса. сделал распечатку и побайтно все проверил - Оно! ;)

(там в конце исходникоа есть коментарий с стримом начинается с 0xAA08 .... )

Но еще не проверял это залить...

 

/*

Data frames with a Standard MSGID of 0x1 should be transmitted to the ECAN-A bootloader.

This data will be received in Mailbox1, whose MSGID is 0x1. No message filtering is employed.

 

Transmit only 2 bytes at a time, LSB first and MSB next. For example, to transmit

the word 0x08AA to the 280x, transmit AA first, followed by 08. Following is the

order in which data should be transmitted:

AA 08 - Keyvalue

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

00 00 - Part of 8 reserved words stream

bb aa - MS part of 32-bit address (aabb)

dd cc - LS part of 32-bit address (ccdd) - Final Entry-point address = 0xaabbccdd

nn mm - Length of first section (mm nn)

ff ee - MS part of 32-bit address (eeff)

hh gg - LS part of 32-bit address (gghh) - Entry-point address of first section = 0xeeffgghh

xx xx - First word of first section

xx xx - Second word......

...

...

...

xxx - Last word of first section

nn mm - Length of second section (mm nn)

ff ee - MS part of 32-bit address (eeff)

hh gg - LS part of 32-bit address (gghh) - Entry-point address of second section = 0xeeffgghh

xx xx - First word of second section

xx xx - Second word......

...

...

...

xxx - Last word of second section

(more sections, if need be)

00 00 - Section length of zero for next section indicates end of data.

*/

Share this post


Link to post
Share on other sites
А я ж чуть више писал, вот так (ну только можно еще через -o явно задать имя bla-bla.bin)

d:\work\28335_Boot1st_OTP2CANRAM__git\Operations>hex2000.exe -boot -b -can8 -pllcr=10 -divsel=2  ../Debug/28335_Boot1
    st_OTP2CANRAM__git.out
    Translating to Binary format...
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .InitBoot         (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .text     (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> .cinit    (BOOT LOAD)
       "../Debug/28335_Boot1st_OTP2CANRAM__git.out"   ==> ramfuncs  (BOOT LOAD)

Когда делал, не заметил, что для с2000 доступна опция -b (давно очень было), надо будет проверить, как она работает. Для с6000 такой опции нету, поэтому и используется hex2array. Вижу, Вы все "манипуляции" проводите из консоли, могу посоветовать создать два файла .cmd и .bat, в cmd-файл прописываете все настройки для hex2000, из bat-файла запускаете hex2000 c файлом настроек. Всё автоматом будет конвертиться и не надо каждый раз в консоли кучу строк прописывать.

У меня из батника ещё и отправка по tftp запускается.

 

И вот по нему у меня остались вопросы. Я чтото запутался вкрай. Программа допустим размером в 4 флэшовых секции, так вот нужно в DSPFlash начинать писать с секции A или к примеру с секцции D? Если писать с D то получается красивое нарастание адреса пока не дойдет до конца секции А, точнее до секюр-зоны.

Если напичнать писать с секции А (ну логично же что А это первая, с неё то и надо начинать, как бы...) то получается идиотизм с постоянным перепрыгиванием (буквой Z по карте адресов) с конца предыдущей секции на начало другой, меняя при этом намерено адреса и анализируя какой хвост дописывать в новую секцию... мрак какойто...

Так вот как правильно писать? Я еще не успел с этим разобраться. Но чтото похоже что правильно так как легче, с секции H->G->F->....->B->A.

Уточните плиз, бо крыша уже едет.

И главное, ни где про это не нашел описания...

Просмотрел, что Вы используете опцию -boot. Тогда что не понятно, есть загрузочная таблица, принимаем размер блока и адресс блока, по мере записи блока инкрементируем начальный адресс блока, принимаем размер второго блока и адресс второго блока, делаем тоже самое. Если в качестве размера блока встречаем ноль - запись закончена, переходим на entry point. В пределал блока адрес только возрастает.

Share this post


Link to post
Share on other sites

Опробовал опцию -b для hex2000, всё работает, можно сразу бинарник генерить. Не знал, интересно, почему для с6000 она не поддерживается?

Share this post


Link to post
Share on other sites

таксь, проблемма, причём какая-то странная.

вот я написал это своё OTP, причем оно основано на том что предлагал TI, только в коде еще одним слоем протокола обросло, тоесть проблема явно не в коде...

Я его шью в 0x380400(для моего TMS320F28335) но оно шьет только секцию .InitBoot (она там у меня 28байт) и при попытке писать следующую следом секцию .text (которая начинается с 0x380420) вываливается с ошибкой...

Длина указана даже чуть меньше чем за вычетом тез 28байт. Тоесть все вместе меньше чем 1к*16.

Более того, оно же ещё и позволяет перезапитывать, по идее не должно, так как OTP одноразовое.

 

Потом я попробовал вообще все в оду секцию впихнуть, не зашило.

 

Ну и теперь, я уже сомниваюсь - а пишет ли вообще CCS5.4 в ОТП, может этото из за того что фришная версия отладчика?

Но думается это я уже начинаю фантазировать, короче не могу понять почему не программируется ОТП-шная секция...

Share this post


Link to post
Share on other sites

Стирает без проблем, но при записи...

вот что пишет при попытки записать в OTP

C28xx: Flash Programmer: Error encountered when writing to Flash memory

C28xx: Error writing: Flash @ address 0x00380400 of length 0x000003F8

C28xx: GEL: File: D:\work\...bla_bla...\my_file.out: load failed.

Share this post


Link to post
Share on other sites

Подскажите, сейчас мне не совсем загрузчик нужен, но работа тоже с flash (камень f28069).

Выделил я свою секцию в *.cmd, для сохранения констант:

 

 
mydata_servise       : > FLASHH,     PAGE = 0

 

попробывал со структурой не получается, щас пробую хотябы с одной переменной, вот так пишу в файле с переменными

#pragma DATA_SECTION(wer, "mydata_servise");
volatile Uint16 wer=3;

 

Потом смотрю в отладке адрес этой переменной 0x3D8000 как бы правильно, но значение её 0xFFFF. Секцию H использую только для этого. Что еще объявить чтобы по этому адресу появилось присвоенное значение?

Еще интересно если убрать в конфигурации загрузчика галочку на секции H ничего не происходит, если же галочку убрать на других секциях где код находиться, то загрузчик ругается и не прошивает.

Edited by ELEKTROS

Share this post


Link to post
Share on other sites

Странно пробывал и с const не работало.

 

Щас массив попробывал так:

 

#pragma DATA_SECTION(wer, "mydata_servise");
const Uint16 wer[6]={1,5,6,8,4,0};

 

Смотрю значения всё нормально присвоилось массиву.

Видимо что-то еще поменялось раз заработало.

Кстати стало ругаться на не подключенную секцию при программировании, а вот если volatile const то ошибку при загрузки выкидывает позже, а так в принципе также работает.

 

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

Share this post


Link to post
Share on other sites
Ну с этим разобрался, а как теперь мне эту константу переписать, допустим есть некий коэффициент чьё значение нужно сохранить на следующее включение устройства? В дальнейщем это будет не одна переменная а целая структура переменных с некими настроечными параметрами, но думаю тут уже не особо важно сколько их там будет.

Ну здесь у Вас программатор всё записывал, а надо чтобы процессор сам писал, посмотрите либу FlashAPI (в начале темы упоминалось), она позволяет процессору самому переписывать свою флэш-память. В CMD выделяете кусок флэша под свои настройки и вперёд.

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