Что такое отладочный интерфейс
BSL режим / BDM / JTAG / БУТ ПИН / ЧТО ЭТО И ЗАЧЕМ
Способы программирования
Разделим условно их на «диагностический»(ПС)* и «инженерный»(ПС)*. В чем-же их различия.
Первое и самое главное в порядке доступа к содержимому Flash-памяти ЭБУ.
«Диагностический» предполагает всегда доступ через сервисный разъем автомобиля посредством программы-загрузчика подгружающей «Loader» в ОЗУ или ПЗУ ЭБУ автомобиля на время сессии чтения-записи. Тут надо сразу оговориться, что не все Флешеры (от слова Flash, так мы будем далее именовать устройства работающие с ЭБУ через диагностический разъем) имеют возможность читать содержимое Flash-Памяти. Некоторые, как например практически все дилерские приборы, умеют только производить запись.
«Инженерные» варианты загрузчиков работают с содержимым памяти ЭБУ через так называемый отладочный интерфейс, который по своему существу и называется «инженерным». В зависимости от семейства процессоров, этот интерфейс на сегодня может быть различным.
Для ЭБУ, оснащенных процессорами Motorola MPC, он носит название BDM (Background Debug Mode).
Для ЭБУ, оснащенных процессорами семейств «Infineon» (С167xx, ST10xx, TC17xx и т.д.), он носит название BSL (Bootstrap Loader)
Для ЭБУ, оснащенных процессорами семейства «Renesas», он носит название JTAG (Joint Test Action Group)
Данные загрузчики используют Loader самого процессора ЭБУ.
Следующим достаточно существенным отличем являются принципы «получения разрешения» загрузчиком от ЭБУ на начало процесса чтения-записи. При работе «дилерским» методом ЭБУ запрашивает ключ доступа (пароль) для разрешения сессии репрограмминга.
При получении правильного ключа, ЭБУ разрешает работу со своим массивом памяти. При не получении ответа, получении неправильного ответа — сессия закрывается. Назовем такой метод полученя разрешения ВИРТУАЛЬНЫМ.
При работе «инженерным» методом разрешение на такую сессию получается путем изменения физического уровня сигналов на соответствующих выводах процессора ЭБУ. Принято называть такие выводы Boot-Pin. Их может быть от одного и до… Зависит от схемотехники и конфигурации конкретного процессора. В ряде случаев необходимо бывает снять физический уровень с одного пина процессора и подать его на другой. Например С167хх ST10хх. Снимем со 105 пина процессора, подаем на 104 пин.
Соответстенно и назовем такой метод получения доступа ФИЗИЧЕСКИМ.
Но… производитель не стоит на месте. С целью затруднить доступ тюнерам к своему ПО, способы защиты постоянно совершенствуются. Повышается ее уровень (TPROT от Protection). Примерно с TPROT9 при открытии BSL-Сессии процессор запрашивает у загрузчика ключ доступа.
Еще одним действием для защиты ПО стало помещение одного из ключей RSA в ОТР (одноразово программируемая) область Flash-Памяти процессора. Например Bosch Kefico ME17.9.хх, что затруднило работу с данным ЭБУ «Диагностическим» методом. Благо сам же производитель закладывает в ПО ряд моментов, которые позволяет тюнерам обходить данные способы защиты. (например флаг конфигурации » Не рассчитывать RSA»)
Статья не моя но для общего развития будет совсем не лишней.
Русские Блоги
Кратко опишите различия между различными интерфейсами отладки (SWD, JTAG, JLink, ULink, STLink)
Эта статья перепечатывается в блогеleon1741, Щелкните здесь, чтобы перейти к блогу оригинального автора
Я полжизни занимался разработкой встраиваемых систем и ARM. Программа отладкиНеизбежноиз. Я имел дело со многими спецификациями отладки, инструментами отладки и методами отладки, но взаимосвязь между ними не особенно ясна. Давайте взглянем сегодня:
Протокол JTAG
Когда был определен протокол JTAG, поскольку компьютеры (ПК) в то время обычно имели параллельные порты, используемый параллельный порт был определен при подключении к компьютеру. Сегодня компьютеры, не говоря уже о ноутбуках, сейчас на настольных компьютерах очень мало параллельных портов.Замени этоПортов USB становится все больше. Поэтому его редко можно увидеть на рынке.
SWD интерфейс
Последовательную отладку (Serial Wire Debug) следует рассматривать как режим отладки, отличный от JTAG, и используемый протокол отладки также должен отличаться, поэтому он наиболее непосредственно отражается в интерфейсе отладки. По сравнению с 20 выводами JTAG, SWD требует только 4 (или 5) контактов, и структура проста, но сфера применения не такая широкая, как JTAG.Основной отладчик также является режимом отладки SWD, добавленным позже.
Отличие SWD от традиционных методов отладки:
RDI интерфейс
Эмулятор JLink
Эмулятор ULink
Эмулятор ST-Link
ST-LINK специально дляSTMicroelectronicsЭмулятор для микросхем серий STM8 и STM32. Основные функции стандартного интерфейса SWIM и стандартного интерфейса JTAG / SWD, указанного в ST-LINK / V2:
Отладочный интерфейс
В данном разделе приведено описание отладочного интерфейса процессора ARM7TDMI в следующей последовательности:
В разделе также описывается модуль эмуляции EmbeddedICE, который входит в состав процессора ARM7TDMI, в следующих параграфах:
1. Общие сведения об отладочном интерфейсе
Процессор ARM7TDMI содержит аппаратные расширения для выполнения расширенных функций отладки. Это существенно упрощает разработку программного обеспечения, операционных систем и собственно аппаратной части.
Отладочные расширения позволяют перевести ядро в состояние отладки. В состоянии отладки ядро останавливается и изолируется от остальной части системы. Это позволяет проверить внутреннее состояние ядра и внешнее состояние системы, когда остальная часть системы функционирует в нормальном режиме. По завершении отладки отладчик восстанавливает состояние ядра и системы, после чего возобновляется выполнение программы.
Запрос, поступивший через один из сигналов интерфейса отладки или внутренний функциональный блок, именуемый логикой эмуляции EmbeddedICE Logic, переводит процессор ARM7TDMI в состояние отладки. Ниже приведены события, которые активизируют отладку:
После перевода в состояние отладки внутреннее состояние процессора ARM7TDMI может управляться с помощью последовательного интерфейса JTAG. Он позволяет загружать в последовательном формате инструкции в конвейер процессора без использования внешней шины данных. Например, после перевода в состояние отладки, инструкция Многократной записи (STM) может быть помещена на конвейер инструкций и это приведет к экспорту содержимого регистров ядра ARM7TDMI. Эти данные могут быть переданы в последовательном формате отладчику, не нарушая работы остальной части системы.
Ядро ARM7TDMI использует два сигнала синхронизации:
В нормальном режиме работы ядро тактируется сигналом MCLK, а внутренняя логика удерживает DCLK в низком состоянии.
Если процессор ARM7TDMI находится в состоянии отладки, то ядро синхронизируется DCLK под управлением цифрового автомата TAP-контроллера, а MCLK может работать вхолостую. Выбранный сигнал синхронизации присутствует на выходе внешней синхронизации ECLK для использования внешней системой.
Прим.: nWAIT не оказывает должного влияния, если ядро ЦПУ находится в состоянии отладки и тактируется сигналом DCLK.
2. Отладочные системы
На рисунке 5.1 показана типичная отладочная система с использованием ядра ARM.
Рисунок 5.1. Типичная отладочная система
Отладочная система обычно состоит из трех частей:
Отладчик и преобразователь протокола являются системно-зависимыми.
В качестве отладчика выступает компьютер, на котором запущена отладочная программа, например, ARM Debugger for Windows (ADW). Отладчик позволяет вводить такие команды высокого уровня, как установка точки прерывания или проверка содержимого памяти.
2.2 Преобразователь протокола
Преобразователь протокола отвечает за преобразование команды высокого уровня отладчика в команды низкого уровня интерфейса JTAG процессора ARM7TDMI.
Как правило, подключение к компьютеру выполняется через расширенный параллельный порт (ЕРР).
Процессор ARM7TDMI содержит аппаратные расширения, которые упрощают отладку на самом низком уровне. Отладочные расширения:
2.3 Отлаживаемое целевое устройство
Основные блоки отлаживаемого целевого устройства показаны на рисунке 5.2.
Рисунок 5.2. Блок-схема ARM7TDMI
Ядро содержит аппаратную часть, поддерживающая отладку.
Это набор регистров и компараторов, используемых для генерации отладочных исключительных ситуаций, как, например, точки прерывания. Описание этого блока приведено в параграфе «Общие сведения о логике эмуляции EmbeddedICE».
ТАР-контроллер управляет действием цепей сканирования через последовательный интерфейс JTAG.
3. Сигналы интерфейса отладки
Отладочный интерфейс состоит из трех основных внешних сигналов:
Прим.: Для полного разрешения отладочных функций процессора DBGEN необходимо перевести в высокое состояние. См. «Отключение EmbeddedICE».
3.1 Переход в состояние отладки
Процессор ARM7TDMI переходит в состояние отладки после запроса со стороны точек прерывания или точек наблюдения, а также при запросе отладки. Для программирования условий активизации точек прерывания или точек наблюдения необходимо использовать логику EmbeddedICE. Альтернативно, вы можете использовать сигнал BREAKPT, который позволяет внешней логике устанавливать точки прерывания или точки наблюдения, а также контролировать:
Временная диаграмма аналогична внешне-сгенерированным точкам прерывания и наблюдения. Данные должны быть действительными по падающему фронту MCLK. Если инструкцию необходимо снабдить точкой прерывания, то сигнал BREAKPT должен иметь высокий уровень при следующем нарастающем фронте MCLK. Аналогично, при чтении или записи данных установка BREAKPT во время нарастающего фронта MCLK маркирует данные, как точка наблюдения.
Когда процессор переходит в состояние отладки, устанавливается сигнал DBGACK.
Временная диаграмма внешне-сгенерированных точек прерывания показана на рисунке 5.3.
Рисунок 5. Вход в состояние отладки
Вход в состояние отладки по точке прерывания
Ядро ARM7TDMI определяет, что инструкция содержит точку прерывания еще при поступлении на конвейер, но ядро переходит в состояние отладки только при достижении такой инструкцией ступени исполнения.
Инструкция с точкой прерывания не выполняется. Вместо этого процессор переходит в состояние отладки.
Внутреннее состояние, которое вы можете проверить после перехода в состояние отладки, соответствует состоянию после выполнения инструкции предшествующей точке прерывания. После завершения проверки состояния необходимо удалить точку прерывания. Как правило, это происходит автоматически под управлением отладчика, который также возобновляет выполнение программы с инструкции, на которой было прервано выполнение программы.
Прим.: Процессор переходит в состояние отладки независимо от выполнения условия.
Инструкция с точкой прерывания не вызывает переход ядра ARM7TDMI в состояние отладки в следующих случаях:
Вход в состояние отладки по точке наблюдения
При срабатывании точки наблюдения завершается выполнение текущей инструкции, после чего выполняются все изменения состояния ядра, считываемые данные помещаются в регистры назначения и выполняется основная обратная запись.
Прим.: Точки наблюдения похожи на Авар. данные. Отличие заключается в том, что при возникновении ситуации Авар. данных, несмотря на завершение выполнения инструкции, процессор предотвращает любые последующие изменения состояния процессора ARM7TDMI. Данное действие позволяет вызвать обработчик аварийной исключительной ситуации, устранить причину аварийной ситуации и повторно выполнить инструкцию.
Если точка наблюдения срабатывает после начала обработки исключительной ситуации, то ядро вводит состояние отладки в том же режиме, что и исключительная ситуация.
Вход в состояние отладки по запросу отладки
Процессор ARM7TDMI может быть переведен в состояние отладки при запросе отладки одним из следующих способов:
3.2 Действие процессора в состоянии отладки
Когда ядро ARM7TDMI вводит состояние отладки, сигналы nMREQ и SEQ индицируют внутренние циклы. Это позволяет оставшейся части системы памяти игнорировать ядро и функционировать в нормальном режиме. Поскольку, оставшаяся часть системы продолжает функционировать, то ARM7TDMI игнорирует аварийные ситуации и прерывания.
Система не должна изменять сигнал BIGEND в процессе отладки, поскольку отладчик не подозревает о реконфигурации ядра.
nRESET должен оставаться стабильным в процессе отладки, т.к. сброс ядра в состоянии отладки вызывает потерю слежения за ядром со стороны отладчика.
Если система устанавливает активный низкий уровень сброса на входе nRESET процессора ARM7TDMI, то процессор изменяет свое состояние, в то время как отладчик не имеет информации об этом.
При выполнении инструкций в состоянии отладки все выходы интерфейса памяти, кроме nMREQ и SEQ, изменяются асинхронно по отношению к системе памяти. Например, при каждом сканировании инструкции в конвейере изменяется шина адреса. Несмотря на то, что это происходит асинхронно, система не подвергается влиянию, т.к. сигналы nMREQ и SEQ индицируют внутренние циклы, независимо от того, что выполняет остальная часть системы. При разработке контроллера памяти необходимо гарантировать, чтобы асинхронная работа не оказывала влияние на остальную часть системы.
4. Домены синхронизации ядра ARM7TDMI
Синхронизация ARM7TDMI описана в параграфе «Синхронизация».
4.1 Переключение синхронизации в состоянии отладки
При переходе процессора ARM7TDMI в состояние отладки происходит автоматическое переключение сигналов синхронизации с MCLK на DCLK, после чего устанавливается сигнал DBGACK во время высокого полупериода MCLK. Переключение между двумя сигналами синхронизации возникает при следующем падающем фронте MCLK. Это демонстрируется на рисунке 5.4.
До завершения отладки ядро использует сигнал DCLK в качестве основного сигнала синхронизации. При выходе из состояния отладки возобновляется синхронизация ядра сигналом MCLK. Это выполняется отладчиком следующим образом:
В этом случае ядро автоматически возвращается к синхронизации сигналом MCLK и запускает выборку инструкций из памяти на частоте MCLK.
См. «Выход из состояния отладки».
Рисунок 5.4. Переключение синхронизации при входе в состояние отладки
4.2 Переключение синхронизации в процессе тестирования
Когда последовательная тестовая комбинация поступает в ядро ARM7TDMI через интерфейс JTAG, то процессор должен тактироваться сигналом DCLK, а MCLK должен находится в низком состоянии.
Вход в состояние тестирования выполняется менее автоматически, чем в состояние отладки и, поэтому, необходимо принять меры, чтобы предотвратить ложную синхронизацию.
TAP-контроллер может использоваться для проверки процессора. Если выбраны цепь сканирования 0 и INTEST, то DCLK генерируется, когда цифровой автомат находится в состоянии RUN-TEST/IDLE (запуск тестирования/холостой ход). В состоянии EXTEST DCLK не генерируется.
При выходе из состояния тестирования необходимо ввести в ТАР-контроллер инструкцию RESTART, после чего возобновляется работа MCLK. После проверки INTEST необходимо убедиться, что перед возвращением к нормальной работе ядро находится в восприимчивом состоянии. Наиболее безопасными способами для этого являются следующие:
5. Определение состояния ядра и системы
Когда ядро находится в состоянии отладки, можно проверить состояние ядра и системы путем размещения нескольких инструкций чтения и записи на конвейере инструкций.
Перед тем как проверить состояние ядра и системы, отладчик путем проверки 4-го бита регистра статуса отладки логики EmbeddedICE должен определить, процессор введен в состояние отладки из состояния Thumb или ARM. Если этот бит равен 1, то ядро введено в состояние отладки из состояния Thumb.
Более детальная информация по определению состояния ядра приведена в параграфе «Определение состояния ядра и системы».
6. Общие сведения о логике EmbeddedICE
Логика EmbeddedICE процессора ARM7TDMI поддерживает встроенные функции отладки ядра ARM7TDMI.
Логика EmbeddedICE программируется последовательно с помощью ТАР-контроллера процессора ARM7TDMI. На рисунке 5.5 иллюстрируется соотношение между ядром, логикой EmbeddedICE и TAP-контроллером с указанием только используемых сигналов.
Рисунок 5.5. ARM7TDM, TAP-контроллер и логика EmbeddedICE
Логика EmbeddedICE содержит:
Регистр управления отладкой и регистр состояния отладки полностью управляют работой EmbeddedICE.
Вы можете запрограммировать один блок или оба блока точек наблюдения для приостановки выполнения инструкций ядром. Выполнение приостанавливается, когда значения, запрограммированные в EmbeddedICE, совпадают с текущими значениями на шине адреса, шине данных и различными сигналами управления.
Прим.: Можно маскировать любой бит для его исключения из процесса сравнения.
Каждый блок точек наблюдения можно конфигурировать как блок точек наблюдения или как блок точек прерывания.
Точки прерывания и точки наблюдения могут быть зависимыми от данных.
7. Отключение EmbeddedICE
Логика EmbeddedICE отключается путем установки низкого уровня на DBGEN.
Замечание: если на вход DBGEN подать непрерывный низкий уровень, то это приведет к отключению логики EmbeddedICE.
Однако этим лучше не пользоваться для повышения безопасности системы.
Если DBGEN в низком состоянии, то:
8. Отладочный коммуникационный канал
Логика EmbeddedICE процессора ARM7TDMI содержит DCC для передачи информации между целевым отлаживаемым устройством и отладчиком. Он реализован как сопроцессор 14 (CP14).
Данные регистры размещены в фиксированных позициях карты регистров логики EmbeddedICE, как показано на рисунке 5.7. Доступ к регистрам со стороны процессора выполняется с помощью инструкций MCR и MRC к сопроцессору 14.
DCC-регистр управления доступен только для чтения. Он управляет синхронизированным подтверждением связи между процессором и отладчиком. Формат регистра управления показан на рисунке 5.6.
Рисунок 5.6. Формат DCC-регистра управления
Ниже приведено назначение каждого бита регистра:
Биты 31:28 | Содержит фиксированную комбинацию, которая определяет номер версии EmbeddedICE, в данном случае 0001. |
Биты 27:2 | Зарезервировано. |
Бит 1 | Если W сброшен, то DCC-регистр записи данных готов для получения данных от процессора. Если W установлен, то данные в DCC-регистре записи данных готовы для сканирования отладчиком. |
Бит 0 | Если R сброшен, DCC-регистр чтения данных свободен и данные могут быть помещены в него из отладчика. Если R установлен, то DCC-регистр чтения данных не могут быть считаны процессором и отладчик должен ожидать. |
Если смотреть со стороны отладчика, то доступ к регистрам выполняется через цепь сканирования 2 обычным образом. Со стороны процессора, доступ к данным регистрам выполняется с помощью инструкций передачи регистра сопроцессора.
Доступ к DCC-регистрам необходимо осуществлять с помощью инструкций из таблицы 5.1.
Таблица 5.1. Инструкции доступа к DCC-регистру
Инструкции | Описание |
MRC CP14, 0, Rd, C0, C0, 0 | Помещает значение из DCC-регистра управления в регистр назначения (Rd) |
MCR CP14, 0, Rn, C1, C0, 0 | Запись значения из регистра-источника (Rn) в DCC-регистр записи данных |
MRC CP14, 0, Rd, C1, C0, 0 | Возвращает значение из DCC-регистра чтения данных в Rd |
Поскольку набор инструкций Thumb не содержит сопроцессорных инструкций, то в этом случае рекомендуется выполнять доступ с помощью инструкции SWI.
8.2 Связь через DCC
DCC позволяет принять и отправить сообщение.
Отправка сообщения в отладчик
Когда процессору необходимо отправить сообщение в отладчик, он должен убедится в том, что регистр записи данных свободен. Это выполняется путем опроса бита W в регистре управления, который должен быть сброшен.
Процессор считывает регистр управления для проверки состояния бита 1:
Поскольку передача данных выполняется от процессора к DCC-регистру записи данных, то устанавливается бит W в DCC-регистре управления. Когда отладчик опрашивает данный регистр, он наблюдает синхронизированные версии бит R и W. Если отладчик определяет, что бит W установлен, то он может считать DCC-регистр записи данных и выполнить его последовательный вывод. По завершении чтения данного регистра данных происходит сброс бита W в DCC-регистре управления. На данном этапе коммуникационный процесс может начаться заново.
Прием сообщения из отладчика
Передача сообщения из отладчика похожа на отправку сообщения в отладчик. В этом случае, отладчик опрашивает бит R в DCC-регистре управления:
Если DCC-регистр чтения данных свободен, то данные записываются в него с помощью интерфейса JTAG.
Со стороны процессора бит R DCC-регистра управления используется следующим образом.
Процессор опрашивает DCC-регистр управления. Если бит R установлен, то имеются данные, которые могут быть считаны с помощью инструкции MRC в сопроцессор 14. После выполнения чтения сбрасывается бит R в DCC-регистре управления. Когда отладчик опрашивает данный регистр и определяет, что бит R сброшен, то это означает, что данные были приняты и процесс можно повторить заново.
Использование DCC с управлением по прерываниям
Альтернативным и потенциально более эффективным методом опроса регистра управления является использование выходов COMMTX и COMMRX процессора ARM7TDMI. Вы можете использовать данные выходы для прерывания процессора, когда:
Данные выходы, как правило, подключаются к системному контроллеру прерываний, управляя входами nIRQ и nFIQ процессора ARM7TDMI.
Прошивка через JTAG: схема, распиновка, инструкция
Открываем для тебя дивный мир флеш-памяти
Содержание:
Ingredients
Directions
Что касается спутников ресиверов, то JTAG дает возможность перепрошить микросхему flash-памяти, если нет возможность прошить ресивер стандартным способом, через кабель к компьютеру. Сегодня мы разберем прошивку через JTAG-интерфейс на примере спутникового ресивера Globo X90 для его восстановления. Ранее мы уже научились прошивать его через кабель (см. предыдущую часть)
Зачем нужен JTAG
Прошивка через JTAG куда сложней обычной процедуры, поэтому к ней прибегают только в самом крайнем случае, когда ресивер совсем не подаёт признаков жизни: не загружается, не горит индикация, прошили другой прошивкой, либо после прошивки у вас только черный экран
JTAG прошивка по шагам
1. Собрать интерфейс (переходник) от порта ресивера к порту ПК
Собрать адаптер для JTAG не так сложно, как кажется на первый взгляд. Для Globo X90, да и вообще для всех ресиверов, предпочтительным вариантом сборки является вариант на микросхеме 74HC244N (её еще называют даташит). Распиновка JTAG:
Так выглядит собранная схема:
Со стороны ресивера это будет специальный разъём, он иногда даже так и подписан — JTAG
Второй «конец», который уходит в сторону ПК — это обычный LPT-кабель, который можно купить в любом компьютерном магазине. О том, как можно собрать всё это хозяйство:
3. Скачать программу для прошивки
Для реанимации ресиверов Globo и всех их клонов, а так же для Евросатов/Евроскаев потребуется специальный программатор. Что касается программного обеспечения, то на данных процессорах используется программа EJTAG_TT_1.0.6.17 (Я.Диск)
4. Установить драйвер, если у вас Windows XP
Если вы используете Windows XP, то необходимо установить драйвер giveio.sys (Я.Диск). Скопируйте файл драйвера GIVEIO.sys в папку C:\Windows\system32\drivers\ если, конечно, система у Вас установлена на диск С: и Вы не меняли пути установки Windows. Запустите файл install.reg.
5. Скачиваем прошивку
6. Переводим ресивер в отладочный режим
Обратите внимание на точки подключения. Они должны совпадать с тем, как вы собрали переходник. В некоторых Globo-ресиверах бывает обратная последовательность — не перепутайте. На некоторых ресиверах можно сделать обычную перемычку для перевода в отладочный режим
Можно использовать перемычку с IDE-винчестеров
Так это будет выглядеть:
7. Настраиваем EJTAG и прошиваем
Настройки в нашей JTAG tool выставляем так же как на скриншоте:
Если EJTAG не увидит ресивер, попробуйте поменять тип флеш памяти в последнем столбике. Вообще, здесь можно пробовать менять любые параметры, чтобы ресивер определился
Если после нажатия кнопки «коннект», у вас выходит ошибка «флэш ID нету в *.ini –файле», то попробуйте поменять настройки в программе, как и советовали выше, нужно попробовать все вариации галочек и точек в настройках. Если и это не приведет к успеху, то тут стоит насторожиться — проверить питание процессора, напряжение с БП — есть вероятность того, что флеш-память уже «умерла», тогда никакой JTAG уже не поможет. Следующим шагом жмём «Записать» и в окне проводника выбираем нужный файл с дампом или загрузчиком (лоадером)
[adace-ad >
При необходимости, как мы и писали выше, EJTAG сотрёт самостоятельно нужный блок памяти и начнет запись.
Здесь есть небольшой нюанс — достаточно залить около 50-70% прошивки через JTAG (желательно, конечно, полностью), но если у вас оборвалась прошивка на этом этапе, то можно попробовать прошивать стандартно (через порт), т.к. дальше уже идут списки каналов, спутники и так далее, т.е. то, что вы зальете и обычный прошивкой.
8. Убираем перемычку, отключаем Debug Mode
Не забудьте в конце прошивки корректно завершить программу EJAG, отключить от сети ресивер и аккуратно отключить JTAG-интерфейс. Так же снять перемычку для входа в отладочный режим. Далее подключаем ресивер уже через ком-порт и заливаем в него софт обычным способом.
Ручной поиск транспондера у спутника
Если вы заливаете «голую» прошивку, то есть необходимость вбить вручную нужные вам транспондеры. У некоторых ресиверов есть функция ручного ввода транспондеров. Для этого