[prst 0]

TMS320F28335 CAN Bootloader

 

Ранее не было опыта с самописными бутлоадерами(только ознакамливался), поэтому щас

столкнувшить с этой задачей и читая даташиты по bootloader-у появились вопросы на

которые на данный момент времени не нашел явного ответа.

Так что, хочу с вами на эту тему пообщаться, уверен что-то новенькое сможете посоветовать.

 

Итак, Цель: Загрузить прошивку для TMS320F28335 через CAN и сохранить

в Flash с дальнейшем прыжком туда.

 

Вот тут, есть описание от Тексаса используя OTP, но оно больше для пояснения.

http://www.ti.com/mcu/docs/litabsmultiplef...mp;familyId=916

http://www.ti.com/lit/an/spraaq3/spraaq3.pdf

http://www-s.ti.com/sc/techlit/spraaq3.zip (пример использования OTP для SPI, CAN)

Документ простой, всего в несколько страниц, и в этом кстати есть некоторая

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

практике всё требуется чуть сложнее или вообще иначе.

Для начала, там описано только как принятый поток загрузить в ОЗУ, и на этом всё,

а этого явно не достаточно.

 

Как мне видится возможным решить это:

1) Загрузить прошивку используя CAN MSGID1(можно ли другой?)

- По частям? С задержками в потоке или без?

- Целиком? (ну тогда всё в память не влезет)

- Выходит, что лучше сразу писать принятую часть потока в Flash...

2) Для того, что бы сохранить чтото в Flash, нужно подключать уже готовую и специфическую

библиотеку с уже реализованными API Flash (http://www.ti.com/tool/sprc539#), последняя версия на данный

момент версия 2.10.

- Какая скорость записи, нужно понять будет ли ДСП успевать качать данный с

CAN потока при условии что спец задержек нету) и одновремено записывать?

У интерфейса CAN скорость максимум 2 МБита\сек, в теории должно успевать

записываться приянятых несколько байт с потока, а вот на деле?

3)

 

Ну и теперь вопрос - как правильно сделать загрузку?

Поправьте меня плиз, если где-то не в ту сторону думаю. На сколько я понимаю то, что я опишу,

это весьма традиционный подход, но всё же хочу у уточнить...

 

1) - Работает программа и слушает указание на готовность принимать новые данные.

2) - Принять первый пакет, и тут же послать команду ожидания перед посылкой

следующего пакета, за это время выключить устройство или перевести в режим

ожидания и быть готовым принять весь поток с новой прошивкой.

3) - Нужно ли тут сразу переходить в OTP и делать дальнейшее в нем?

Более того для переходя в любой другой режим загрузки, нужно перед ресетом

предварительно установить на boot-пинах другую конфигурацию состояния пинов.

? - Как в этом случае люди поступают, внешняя логика или можно какими-то уже

заложенными средствами? (я их пока не нашел в описании)

4) - Далее, уже основной поток (это как раз описано в документе для OTP что писал

линк выше), согласно документации выше, в начале должен идти адрес точки входа

в прошивку (его-то и нужно извлечь и потом на него перепрыгнуть), отдельно

сохранить в память (мало ли).

5) - Прием слудующего(-их) пакета(-ов). Проверить, не последний ли это пакет в потоке,

с обязательной проверкой контрольной суммы (мало-ли, шумы могут исказить).

6) - Если обраружен сбой - goto 11)

7) - Принятый пакет сохранить в Флэш.

8) - Ожидать следующий пакет или же сделать явный запрос.

9) - goto 5)

10)- По признаку конца потока, посчитать контрольную сумму на целостность

прошивки, если все ОК, то перейти по адресу точки входа (пункт 4).

11)- Послать запрос на повторную посылку предудущей команды, и так например повторить

5 раз(или до упора). Выход с сохранением статуса аварийсного сбоя или попытаться

запросить снова, через например 10 минут. Если сбой, записать статус и сообщить

по CAN об аварийной остановке, так называемый в РЖД-шных устройствах "защитный отказ".

 

В общем после ознакомления выяснил что вопрос TMS320F28335 CAN Bootloader не растрыт

толком со стороны Тексаса, но и то что они предоставляют тоже явно помогает.

В общем нужна ваша помошь.

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

 

Заранее спасибо за все советы.

[Gradient 1]

Прием слудующего(-их) пакета(-ов). Проверить, не последний ли это пакет в потоке,

с обязательной проверкой контрольной суммы (мало-ли, шумы могут исказить

 

CRC вообще-то проверяется автоматически аппаратно.. но если вам хочется...

 

 

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

Примеров в интернете сколько хочешь, например для AT90CANx.

При небольших усилиях, удаётся легко адаптировать код под ваш процессор и наслаждаться..

[doom13 0]

Загрузчик реализовывался как-то так:

1. Flash на две части делим. Одна под загрузчик, вторая для основной программы.

2. Команда перехода в режим загрузчика и обратно(при необходимости).

3. Пару байт флэша под флаг наличия основной прошивки.

4. После перехода в режим загрузчика, посылаем ответ о режиме.

5. После отправки команды на стирание флэша, ожидание ответа о завершении стирания.

6. Ответ на каждое сообщение. После чего отправка нового сообщения.

7. Комада завершения прошивки и перехода на выполнение основной программы.

[Gradient 1]

Ответ на каждое сообщение тоже не нужен.

CAN контроллер аппаратно подтверждает доставку и достаточно слушать ACK.

Всё уже давно придумано не нами.?

[doom13 0]

Ответ на каждое сообщение тоже не нужен.

CAN контроллер аппаратно подтверждает доставку и достаточно слушать ACK.

Всё уже давно придумано не нами.?

 

Запись флэша какое-то время занимает и её лучше не прерывать - я бы с ответом делал (ответ на каждую запись флэша).

[Gradient 1]

Зачем захламлять шину?

Не нужно... ведь на ней могут работать ещё много устройств.

Достаточно ждать проверки crc после записи страницы.

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

И вы вылетите в загрузку заново.

[prst 0]

CRC вообще-то проверяется автоматически аппаратно.. но если вам хочется...

 

Примеров в интернете сколько хочешь, например для AT90CANx.

При небольших усилиях, удаётся легко адаптировать код под ваш процессор и наслаждаться..

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

 

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

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

 

Запись флэша какое-то время занимает и её лучше не прерывать - я бы с ответом делал (ответ на каждую запись флэша).

А вот какое время? я не нашел ответа в документации, мне нужно также знать с какой скоростью он по факту пишет....

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

[Gradient 1]

CAN имеет свой механизм проверки целостности пакета

судя по отзывам он часто сбоит при больших ЭМ шумах

Вот это уже полная хрень, за 10 лет никогда не видел.

Отзывы приведите тут...

[doom13 0]

А вот какое время? я не нашел ответа в документации, мне нужно также знать с какой скоростью он по факту пишет....

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

 

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

[prst 0]

Вот это уже полная хрень, за 10 лет никогда не видел.

Отзывы приведите тут...

Отзывы просты. мне их несколько раз подчеркивали. Устройство, рядом с которым коммутируют немалые токи, и сама система от 20 до 50А, и импульсные до 200А, наводит наводки на все коммуникационные переферии, и более того несмотря на всё негативное влияние таки есть. Ну даже не это важно, а важно то что эти доп проверки от меня тоже требуют чтоб они обязательно были реализаванны, и даже в случае, если вдруг их не будет - хуже не станет. :)

 

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

да, это как запасной вариант с запросом, а точнее скорее всего мной будет реализовано чуть позже, изначально была мысль без запроса просто реагировать на стрим, и запрос только при обнаружении сбоя. Почему так, просто для OTP выделено очень мало памяти, всего 1Кбайт, и если туда влезет реализация с запросами и остальным то так и быть. Сегодня проверил - Flash_Erase() в дебаг режиме более 3сек ...долго. А вот Flash_Program() вроде быстро, но не удалось заметить на сколько быстро. гдето 100...200мсек максимум., а может и быстрее.

Вот по этому я и хочу найти найти инфу с какой же скоростью API Flash пишет. Думал что раз флэш работает на частоте 30..40МГц в чтении, то хотя бы на 5..10МГц в записи, но это от фонаря прикидки.

[Gradient 1]

несмотря на всё негативное влияние таки есть

Сказочник... :)

 

хочу найти найти инфу с какой же скоростью API Flash пишет

Разве в документации нет значений времени записи байта?

Если TI не привел данную цифру в документации, это было бы ещё сказочнее...

[ELEKTROS 0]

Мне вот интересно зачем выбирать пины для загрузки, вы же собрались писать свой загрузчик на TMS (или я не правильно понял, и вы хотите написать прикладную программу на ПК только), кстати сбросить камень можно программно почитайте про собачий таймер раздел.

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

 

[doom13 0]

да, это как запасной вариант с запросом, а точнее скорее всего мной будет реализовано чуть позже, изначально была мысль без запроса просто реагировать на стрим, и запрос только при обнаружении сбоя. Почему так, просто для OTP выделено очень мало памяти, всего 1Кбайт, и если туда влезет реализация с запросами и остальным то так и быть.

 

Неправильно понял сразу, что конкретно вы хотите сделать. Я предлагал делить флэш на две части, одну из которых отдать под загрузчик. У Вас же задача сделать загрузчик для ОТР, но тут ограничения по размеру кода. Как вариант, выбираем режим загрузки с флэша 0х3F7FF6 (111) и делаем полностью изменяемый (при необходимости) загрузчик, без жёстких ограничений по размеру кода. Возможно, в Вашем варианте есть преимущества.

 

Более того для переходя в любой другой режим загрузки, нужно перед ресетом

предварительно установить на boot-пинах другую конфигурацию состояния пинов.

? - Как в этом случае люди поступают, внешняя логика или можно какими-то уже

заложенными средствами? (я их пока не нашел в описании)

 

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

 

Во втором мануале есть упоминание о примере необходимого Вам загрузчика (f280x_otp2can_boot_rom), попробуйте поискать, думаю, так будет проще.

 

Мне вот интересно зачем выбирать пины для загрузки, вы же собрались писать свой загрузчик на TMS (или я не правильно понял, и вы хотите написать прикладную программу на ПК только), кстати сбросить камень можно программно почитайте про собачий таймер раздел.

 

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

 

Изменено 17 апреля, 2014 пользователем doom13

[ELEKTROS 0]

doom13, я как бы в курсе что там куча вариантов загрузки через встроенный бутлодер, я имел ввиду самописный бутлодер которому чтобы запуститься нужно принять опреденённые команды CAN и всё, никакие пины конфигурировать не нужно. Примерно так:

 

1) Приняли опреденённый пакет - маркер.

2) Запустился бутлодер в фоновой программе в каком нибудь бесконечном цикле по флагу и отключил прерывания.

3) Далее с CAN интерфейсом работа идёт в этом цикле (считывая или передавая).

4) Отсылка команд очистки flash и записи прошивки.

 

Ну и сам код загрузчика хранить в секции H допустим(предлагали уже) или копировать в RAM встроенный загрузчик и запускать его прямо без ресета. Прошивку передавать по байтно или блоками по 8-мь байт (собственно по SCI так).

 

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

[doom13 0]

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

 

Как минимум, необходимо конфигурационными ногами выбрать вариант загрузки процессора, без этого процессор вообще не стартанёт.

1. Для варианта OTP custom bootloader необходимо выбрать режим Boot to OTP 0x3D7800 (gpio18 - 0, gpio29 - 0, gpio34 - 1). При включении питания управление передаётся OTP custom bootloader, который умеет принимать прошивку по can и заливать её во флэш, умеет стартовать уже имеющуюся во флэши прошивку. А уже основная программа понимает команду перехода на OTP custom bootloader.

2. Для варианта custom bootloader in flash необходимо выбрать режим Boot to flash 0x3F7FF6 (gpio18 - 1, gpio29 - 1, gpio34 - 1). Для этого варианта бьём флэш на две части, при включении питания стартует custom bootloader in flash, который умеет заливать прошивку по can (в моём случае can + ethernet) и стартовать залитую прошивку. Основная программа понимает команду перехода в режим загрузчика.