• ISP_MB9X: Релиз v2.10.
  • Fix bug: МК (MB90) с заданной строкой Baud2 программировались только при первом значении частоты кварца из списка Clock.
  • Отключен вывод отладочной информации;
  • Переработан процесс-индикатор;
  • Переработан интерфейс вывода ошибок;
  • Поддержка работы через мост USB-COM (увеличены таймауты);
  • Добавлен ключ /z - поменять функциональное назначение выводов RTS/DTR;
  • Добавлен ключ /q - один код '1' на все ошибки;
  • Добавлены 15 серий МК семейства MB90: 337, 342, 345, 346, 349, 351, 362, 367, 378, 395, 488, 489, 822, 823, 983;
  • Добавлены 7 серий МК семейства MB91: 356, 267, 272, 248, 314, 318, 345;
  • Удалена краткая форма задания МК - /Fxxx;
  • /MB90Fxxxi не чувствителен к регистру символов;
  • Файлы исполняемых модулей для разных семейств разнесены по каталогам;
  • В состав архива isp_mb9x добавлены:
    • схема адаптера;
    • screenshot отчета о выполнении операций;
  • Документация соответствует всем изменениям;

Что-то не работает, в чем ошибка?
Запускаю командной строкой:

isp_mb9x.exe /1 /o4 /MB91F362 /b sepr2.bin /P

Процессор делает ресет, а в консоле:


И так остается.
FME FR-Flashprogrammer V3.7 шьет без вопросов.
Схема:
Rx, Tx через MAX, reset - DTR.

К чему подключен вывод 46 м/с MB91F362?
У меня к 0VD через сопротивление.

Reset формируется транзистором, аналогично приведенному примеру?

46 нога (BOOT) на земле (согласно схеме Cremson-StarterKit), она у меня на выключателе, и на единице и на земле одинаково - не шьет.
Reset формируется MAX-ом 811: с DTR, через MAX232 - на вход MAX 811.
Изменение ключа /w от 0 до 9 не приводит ни к чему.

Вот что посмотрел:
FR Flash Programmer посылает 0x56 гораздо чаще, чем Ваш, и F362 после резета, в отведенные для этого 200 мСек, не успевает "поймать" V от вас, соответсвенно не отвечает, и переходит на исполнение программы.
Т.е. в случае, если включить reset транзистром с DTR, то Ваша прога делает reset и посылает 0x56, вероятно попадая в отведенные 200 мСек, вторая посылка 0x56 от Вас уже смысла не имеет, т.к. время уже ушло.

Не могли бы Вы сделать более частую отправку 0x56 и ожидание ответа, скажем каждые 50-60 мСек, как это сделано в FR FlashProgrammer ?

Почему хотелось бы пустить Ваш программатор? - потому что есть функция стирания только необходимых секторов и исполнение из командной строки (чтоб не выходить из SlickEdit-а). И само-собой, свой писать не очень хочется - в выходной надо отдыхать.

PS На днях решил вопрос с параллельным программированием MB91F36x (требуется в случае изменения Security Vector или при сбое на стирании). Если надо напишу в FAQ,

Уже догадался. Это из-за увеличения таймаутов, что необходимо для поддержки моста USB-COM.

Сделаю к понедельнику.


Да и зачем, если уже есть


Шли на мыло, которое на страничке "О сайте".

А можно как-нибудь, чтоб всем хорошо было, и на USB-COM и на COM работало? Тайм-ауты это в смысле ожидания ответа на USB-COM больше нежели на COM? А если пустить на параллельном потоке отправку 0x56 каждые 50 мСек, а в основном ожидать ответа.

Еще такой вопрос, можно ли ввести сервис (по ключу), который бы сравнивал предыдущий записанный файл в МК с записываемым сейчас и стирал-переписывал только те сектора, которые изменились относительно старого? При этом, само-собой, не проверяя содежимого самого МК. А при отсутвие предыдущего записанного файла (но наличию ключа) проводил обычную запись.

Уже сделал.

Затруднительно:
1.Текущий движек программатора не расчитан на такое (операция стирания ничего не знает и знать не может о параметрах программирования)
2. Функция адресного стирания не реализована (ни в ПО PC, ни в ПО MCU ), но возможна подмена ae_flash.362 для выполнения специфичных операций подготовки flash к программированию ПО.

Почему до сих пор не сделано?
Потому что считаю что все подобные вещи (хитрые режимы стирания и прошивки) лучше реализовывать в bootloader'е.

PS:
Сам isp_mb9x использую только для проверки его функцианирования, вся аппаратура на MB9X программируется через bootloader по CAN.

Увеличение таймаутов было сделано для поддержки F2MC LX-серии, при использовании кварцевого резонатора на 4 МГц. В этом случае используется очень низкая скорость обмена по СОМ-порту (4800/9600) и на длинных передаваемых блоках получается разница в таймаутах. Т.е. по сути, удлинять таймауты можно было бы только для передачи длинных блоков данных. Наверное, можно переделать и в этом направлении. Не знаю, как Сергей, сейчас это реализовал.

ISP_MB9X: Релиз v2.12.

• • Корректно выводится имя загружаемого в RAM файла при операциях с МК семейства MB91;
  • Весь вывод через cout вместо printf, для удобства работы в SlickEdite;
  • Add source code for ae_flash.362;
  • Option "DownloadOption=1" read from config.ini (for mb90f59X);
  • Skip "BIROM Communication check" if "DownloadOption=1" (for mb90f59X);
  • Fix bug: /w корректно работает при операциях с МК семейства MB91.
  • Расширен диапазон значений параметра /w - 0..9.
  • Выполняется вторая попытка операции чтения или записи при сбое передачи блока данных.

Релиз v3.00.

Исходный код открыт и размещен в репозитории на sf.net.

Небольшие изменения:
- входной файл может быть в формате S-records (определяется по расширению .mhx)
- из комплекта удалены BIROM-модули. Теперь необходимо устанавливать
FLASH MCU Programmer 16LX (и/или FR) и указывать в конфиге isp-mb9x.cfg путь до этих инструментов.

можно ли прочитать данной программой MB90F038S проч по datasheet похож на MB90F345 ?

Как с Васи можно связаться ?

038 - о таком процессоре не припомню сведений (давненько это было), название указано верно?

Если название верно, то точно опыта работы с ним не было. Т.е. надо пробовать. Необходимо искать на него документация по его прошивке.
ISP_MB9X использует механизм BIROM.

как с Вами связаться?

Как вариант - см. на сайте mb9x