Диагностика двигателя, логгирование и прошивка ECU. Опции

[gktuning]

Ну, то, что 00 это не признак свободного места - понятно, скорее уж FF, хотя это тоже только намек на то, что нужно проверять по коду, как используется блок.
У Артема я действительно не верно понял, что копируется в RAM, а что - нет, уж было возрадовался, что ему удалось туда это все втиснуть.
И еще, не очень понятно про "атоматчиков", ведь там разные проци и разные размеры ROM/RAM.
По поводу блока FFFF 9C00 - FFFF 9FFF - если знать точно, когда и для чего он используется, то есть шанс загнать туда
например, большую 3D VE (не страшно, то после включения зажигания блок затирается FF, можно после вкл. зажигания скопировать туда карту, завести двиг. отстроить ее, перенести в ROM, и забыть пронее до изменения "железячной" конфигурации ведь она нужна в основном при начальной настройке, что б добиться соответствия реальной смеи заданной в топливной карте, дальше в основновном работа с топливной и картой зажигания). На "турбо" сложнее, VE нужно корректировать при изменении наддува, хотя на "атмосфере" тоже при развороте Р-валов.
Вообще, VE -это в "русском" варианте Базовое Цикловое Наполнение (воздухом) (БЦН), исходя из температуры возуха на впуске (IAT) и абсолютного давления (MAP) рассчитывается плотность, из плотности и рабочего объема (где-то должна у нас присутствовать константа, соответствующая раб. объему двигателя или цилиндра) вычисляется весовой заряд воздуха, попавшего в цилиндр за один цикл, - это рассчетное наполнение, дальше по таблице VE оно приводится в соответствие с реальным и исхоя из этого, производительности форсы и заданного состава смеси рассчитывается длитнльность открытия форсунки.
В общих чертах - как-то так.
Где-то встречал у себя более подробно расписанную формулу, но как всегда, когда надо, не могу найти - найду - выложу.

[gktuning]

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

[falcon]

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

Единственное, что могу посоветовать - выкинуть из РАМ те таблицы, которые отлажены или не представляют большого интереса. Недомут - в том числе, только зиада надо тогда запинать, чтобы сделал нормальное логирование, а не через задницу.

Еще могу сказать что можно использовать ИММОвские таблицы - оно использует в памяти несколько блоков, только сейчас навскидку не помню какие в рам а какие в ром. Если отключить иммо - эту память можно использовать.

[gktuning]

To falcon:
Извини, что пристаю с этим ликбезом, но очень хочется разобраться (IMG:style_emoticons/default/biggrin.gif)
Объясни, что за сигнатура такая DEAD, ее назначение, особенно что она делает в РАМ?
Она прописана в РАМ по FFFFA800, за ней следует довольно большой массив непонятных данных аж до начала стека,
начиная с А800 там 0х300 байт, особенно интересно с точки зрения - нельзя ли ее подсократить?
После А800, явных обращений нет, или FFFF A800 - это начало блока? Тогда я где-то прозевал указание на его размер.

И еще, в блоке данных, копируемом в РАМ между многими картам есть промежутки по 5-7 байт FF - обязательно ли соблюдать эти промежутки (понятно, что если их убрать то адрессацию придется корректировать), хотелось бы собрать все свободное место в кучу.
И, если можешь, дай адреса карт Иммо, он все равно всегда отключен.

[Titus]

Вопрос.
Можно ли сдвинуть время начала работы форсунок (не длительность их впрыска, а именно точку старта, относительно ВМТ), и как?

[Artem NN]

После прошивки нужно делать reset DEAD - для EVO 7 и 8. (256кб)
Эта процедура вычищает память RAM A000-A800 т.к. после прошивки
там остается какая то информация. Потом можно делать rom2ram - копировать таблицы из ROM 37B000+800 в RAM.
На Evo 9 (512кб) этого делать не нужно - память вычищается при перепрошивке.
Это написано в хэлпах у Зиада.


Время начала работы форсунок и зажигания завязано на датчики коленвала и распредвала.
В коде пока еще не знаю где стартуют данные процедуры.
Пока не могу сказать идет там работа через формулы или просто вкл/выкл от датчика.

[Yuriy_R]

Вить, наверное можно, переделав чуток пластину коленвала... но тогда вся прога собъется,
ибо ignition работает именно по ней.
А кстати что работает по ДПРВ?


Наверное это нужно для того, что новый распредвал будет раньше открывать впускной клапан? (IMG:style_emoticons/default/biggrin.gif)

[falcon]

To falcon:
Извини, что пристаю с этим ликбезом, но очень хочется разобраться (IMG:style_emoticons/default/biggrin.gif)
Объясни, что за сигнатура такая DEAD, ее назначение, особенно что она делает в РАМ?

Да не проблема. DEAD - сигнатура целостности РАМ. Потому что РАМ нельзя переписывать каждый раз, когда включаешь зажигание - иначе будут теряться все сделанные тобой изменения. Поэтому там сделана переменная, по которой судят о том, что надо переписать таблицы в РАМ данными из РОМ, потому что ты, скажем, снимал клемму. Вот снял ты клемму. Откуда при этом в РАМ появятся таблицы? Их нужно скопировать туда. А как узнать, что их НАДО туда копировать? Вот для этого и есть переменная, куда записывают значение DEAD (0xDEAD, 57005). Как только при включении зажигания там оказывается значение, отличное от 57005, то подразумевается, что данные в рам покорежились, и все таблицы в РАМ перетираются блоком памяти из РОМ.

Она прописана в РАМ по FFFFA800, за ней следует довольно большой массив непонятных данных аж до начала стека,

До ВЕРШИНЫ стэка - стэк "растет" "вниз" по адресам.

начиная с А800 там 0х300 байт, особенно интересно с точки зрения - нельзя ли ее подсократить?
После А800, явных обращений нет, или FFFF A800 - это начало блока? Тогда я где-то прозевал указание на его размер.

Это и есть место для стэка. При старте стэк "нацеливается" на 0xFFFFAB00 и дальше стэк при работе "растет" "вниз" 0xFFFFAAFC, FFFFAAF8 и т.д.

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

И еще, в блоке данных, копируемом в РАМ между многими картам есть промежутки по 5-7 байт FF - обязательно ли соблюдать эти промежутки (понятно, что если их убрать то адресацию придется корректировать), хотелось бы собрать все свободное место в кучу.

Нет, эти хвосты не нужны, это "отходы производства" Тэфры. В коде - тут понятно зачем оно - процедуры переписывались много раз, становились длиннее или короче - поэтому он отводил место под каждую процедуру а в конце их оставлял запас "на вырост". Это - понятно. А вот зачем оставил хвосты после таблиц в РАМ - это мне не понятно. Я у себя это место занял переменными-переключателями, изменением которых я управляю опциями прошивки. Но в принципе - никто не мешает просто сдвинуть таблицы вплотную.

И, если можешь, дай адреса карт Иммо, он все равно всегда отключен.

Ну, наиболее подробно у меня "разобрана" моя прошивка, что неудивительно (IMG:style_emoticons/default/wink.gif) , в других я это дело не отмечал. Постараюсь выбрать время и сделать список этих блоков у тебя.

После прошивки нужно делать reset DEAD - для EVO 7 и 8. (256кб)

Потому что в "родном" тефрокоде там косяк - при определении целостности dead регистры сравниваются без предварительной подготовки extu.w. Если ты переписывал это место из моей версии, то там это я исправил, все будет работать автоматически, так как положено.

Можно ли сдвинуть время начала работы форсунок (не длительность их впрыска, а именно точку старта, относительно ВМТ), и как?

Насколько я понимаю, именно об этом у меня спрашивал несколько раз Артем. Пока не скажу. Процедуру-обработчик сигнала ДПКВ я видел, там много чего обсчитывается, надо разобраться подробнее. А то я там только вычисление RPM разобрал, дальше ковыряться не стал - посчитал это место неинтересным (IMG:style_emoticons/default/wink.gif)

[gktuning]

Витя, Юра, пытаться сдвигать датчик не стОит, это потянет за собой работу прошивки - сигналы ДПКВ и ДПРВ - это начальная точка отсчета для всего, что связано с углам. Впрыск у нас "точечный", фазированный и обязательно подразумевает такой параметр, как "Фаза впрыска", только я пока его не нашел (в прочем, это не показатель, программист из меня очень слабенький). На IX, X фаза впрыска еще и к развороту валов должна быть "привязана".

[gktuning]

To falcon:
Огромнейшее спасибо и + в репу!
Совсем забыл, что стек растет на уменьшение адреса, так что существенно откусить что-то не получится. Мне для полного счастья не хватает "совсем чуть-чуть" - "всего" 622 байта. Так что единственная непонятная облась это перед началом DMA карт, если получится понять, как и когда она используется, то, возможно, появятся мысли по ее использованию.
И еще, на тех Тефра, что я выкладывал, на эво 7, 8 у меня ни разу не возникала необходимость reset DEAD, все на своем месте. Покажи пожалуйста фрагмент своего кода, а если еше кинешь адресочки для сравнения - вообще красота.
А чему соответствует значение DEAD - на контрольную сумму не похоже вроде бы, или просто проверяется наличие этой сигнатуры в РАМ?
Замучал я тебя своими вопросами, боюсь, со мной скоро вот так будет (IMG:style_emoticons/default/s1.gif)
А алгоритмы рассчета фазы впрыска скорее всего будут связаны с ДПРВ, хотя ДПКВ там тоже будет участвовать.
Все, пошел переваривать информацию.
Еще раз спасибо!

[falcon]

Совсем забыл, что стек растет на уменьшение адреса, так что существенно откусить что-то не получится. Мне для полного счастья не хватает "совсем чуть-чуть" - "всего" 622 байта. Так что единственная непонятная облась это перед началом DMA карт, если получится понять, как и когда она используется, то, возможно, появятся мысли по ее использованию.

Мой совет - незначительно уменьшив объем "больших" карт, можно значительно освободить место. Я уже пожалел, что сделал 30х25 карты. Оно, конечно, красиво, и можно очень тонко настроить, это да. Вот только у меня не очень получалось настроить даже старую "родную" карту, поэтому избыточность новых карт, лично у меня невостребована. Обороты - это да, штука нужная. А вот ось нагрузки я бы сейчас без сожаления уменьшил с 30 до штук 20 столбцов, области малой нагрузки можно вообще "сквадратить" до 1-2 столбцов, все равно там одинаковые данные - смысла в них нет, а среднюю область сделать раза в два "реже". У меня такая же проблема нехватки места и я над этим уже задумываюсь, лень только все карты пересчитывать заново..
Кроме того, cranking таблицу тоже можно выкинуть, пусть она маленькая, но все равно, можно сказать, лишняя, там она потому что есть калибровка на альт форсы, насколько я понимаю, большинству оно нафиг не надо - менять форсы по 3 раза на день.

И еще, на тех Тефра, что я выкладывал, на эво 7, 8 у меня ни разу не возникала необходимость reset DEAD, все на своем месте. Покажи пожалуйста фрагмент своего кода, а если еше кинешь адресочки для сравнения - вообще красота.

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

Код

ROM:0003EEB0 TephraMOD_Engine_Main_Loop_Hook_3EEB0:; CODE XREF: Main_Engine_Control_Loop+8Ep
ROM:0003EEB0                                ; DATA XREF: Main_Engine_Control_Loop:No_IMMOo
ROM:0003EEB0
ROM:0003EEB0; FUNCTION CHUNK AT ROM:0003E000 SIZE 000000E8 BYTES
ROM:0003EEB0
ROM:0003EEB0                 sts.l   pr, @-r15    ; was MUT9A_Control
ROM:0003EEB0                                ; called from Main_Engine_Control_Loop
ROM:0003EEB2                 mov.l   r0, @-r15
ROM:0003EEB4                 mov.l   r1, @-r15
ROM:0003EEB6                 mov.l   r2, @-r15
ROM:0003EEB8                 mov.l   r10, @-r15
ROM:0003EEBA                 mov.l   r11, @-r15
ROM:0003EEBC                 mov.w   word_3EF40, r0; h'FFFFDEAD
ROM:0003EEBE                 mov.l   off_3EF18, r1; DEAD_LOCATION_FFFF78FE
ROM:0003EEC0                 mov.w   @r1, r1

ROM:0003EEC2 extu.w r1, r1
ROM:0003EEC4 extu.w r0, r0

Код

ROM:0003EEC6                 cmp/eq  r1, r0
ROM:0003EEC8                 bt      Signature_OK;
ROM:0003EECA RAM corrupted. Reinit RAM tables with ROM copies
ROM:0003EECA                 mov.l   off_3EF34, r10; NEW_MUT_MAP_37B00; From

Без двух указанных операторов старшие биты регистров R1 и R0 неопределены (точнее, такие, как "пришли" из "родного" кода). Соответственно, результат сравнения зависит не только от того, что там с DEAD, но и от того, в какой прошивке какие данные приходят в регистрах 0 и 1.

А чему соответствует значение DEAD - на контрольную сумму не похоже вроде бы, или просто проверяется наличие этой сигнатуры в РАМ?

Ничему. Dead - по-пиндосски "мертвый", вот некоторым личностям и нравится использовать значение 0xDEAD (IMG:style_emoticons/default/wink.gif)

Замучал я тебя своими вопросами, боюсь, со мной скоро вот так будет (IMG:style_emoticons/default/s1.gif)

На то и форум. Кто может - помогает. Кто не может - не помогает. Я тоже коллективным разумом пользуюсь, когда вопросы возникают (IMG:style_emoticons/default/drinks.gif)
Titus и вовсе, можно сказать, за меня мне EGT поможет сделать, потому что у меня руки кривые. Почитав тему про взорванный двиг, я только укрепился в мысли что не зря решил перестраховаться. (IMG:style_emoticons/default/wacko.gif)

[gktuning]

Взаимно (IMG:style_emoticons/default/drinks.gif)
И спасибочки огромное! Что называется, разжевал и в рот положил!
А по поводу больших карт у меня тоже давно руки чешутся их поуменьшить.
Единственная карта, которую желательно иметь большой, так это как раз 3D VE, а для топливной вообще хватило бы стокового размера.
Эх, люблю MoTec в этом отношении, (да и во всех других, кроме цены), там размер карт, оси по которым будешь работать, сам определяешь - хочешь тебе по дросселю, хочешь по давлению, хочешь - по нагрузке, комплектуешь периферией по своему усмотрению практически без привязки к пинам (есть группа аналоговых, группа дискретных входов и группа каналов управления с довольно мощными ключами на выходе) вот и распределяй как хочешь. Да еще библиотека всяких датчиков и форсунок - хочу, к примеру на такой-то вход IAT поцепить - тыц мышкой в библиотеку - фирма такая-то, номер такой-то - тыц мышкой , а в прошивку уже и тарировка датчика прописалась. Ну и онлайн полный по CAN.
Вот такое небольшое "лирическое отступление". (IMG:style_emoticons/default/biggrin.gif)

[falcon]

gktuning, двигать датчик неохота.. Но найти бы это место в прошивке.. Много интересного позволит сделать (IMG:style_emoticons/default/wink.gif)

Чтобы точно сказать - надо знать схемотехнику - что куда подключено в эбу.
А так как есть - не хватает данных - в коде идет работа с какими-то регистрами, понятно, что это что-то "железное" управляется, но что именно...
Некоторые датчики, например датчик коленвала, я вычислил косвенно - по датчику коленвала идет рассчет РПМ.

В подозрении у меня три регистра GR2E, GR2F и GR2G - с ними активно идет управление каким-то железом. Точно не скажу, но регистры выбираются, вроде, от фаз газораспределения или от чего-то похожего, и значения в них записываются тоже вычисляемые по датчику коленвала.

Дальше можно только догадываться - знаний какой регистр за что отвечает не хватает.
Толи это управление моментом впрыска, толи что-то подобное. Хотя тогда остается вопрос, почему регистров ТРИ а не четыре??

Может у кого-нибудь есть полезная инфа по этому вопросу и совместно удастся разобраться?

PS: Если двигать датчик коленвала:
1. Съедет УОЗ
2. Съедет момент впрыска
3. Скорее всего будет ошибка рассинхронизации коленвала<->распредвала, при попытке установить ГБО-шный вариатор УОЗ, по-крайней мере, ошибка выскакивала.

[Artem NN]

Есть автожурнал - Автомастер.
Скачивал с рутрейкера. http://rutracker.org/forum/index.php (в поиск)
С номера 2009.08 - 2010.08 Есть статьи в каждом журнале - MPI система многоточечного впрыска. (как раз только по Мицубиси)
Там как раз расписываются работы всех датчиков - углы, фазы, и т.д. все подробно разжевывается в каждом журнале. Куча полезной информации.
Сюда выложить проблематично 90mb. А из PDF х.з. как выдернуть текст с картинками.

[Artem NN]

Вырезки из журнала Автомастер по MPI.
Нарезал джепегов.
 MPI.ZIP ( 4,74 мегабайт ) Кол-во скачиваний: 361

налетаем качаем.
Жаль - статья не полная. Если кто найдет продолжение - выкладывайте.

[gbix]

Вырезки из журнала Автомастер по MPI.
Нарезал джепегов.
 MPI.ZIP ( 4,74 мегабайт ) Кол-во скачиваний: 361

налетаем качаем.
Жаль - статья не полная. Если кто найдет продолжение - выкладывайте.

нашел журналы 10-12 за 2010. 09 почему-то нигде-нет

Прикрепленные файлы

 mpi_продолжение.zip ( 2,4 мегабайт ) Кол-во скачиваний: 250

 

[gktuning]

Хотел отследить, на какие ноги проца заходят сикналы ДПКВ и ДПРВ, но не тут-то было, уперся в буферную микруху.
На ней написано:
(значек Mitsu)Е328
27A5Y7J
Написал, точно, как на ней, т. к. идентифицировать ее не удалось - или что-то очень специализированное, или имеет еще какое-то название.
Может кто знает, что за зверь, нужно одно из двух - или даташит на эту микруху или схема ECU.
Черкните, если кто встречал подобную инфу.

[falcon]

Хотел отследить, на какие ноги проца заходят сикналы ДПКВ и ДПРВ, но не тут-то было, уперся в буферную микруху.
На ней написано:
(значек Mitsu)Е328
27A5Y7J
Написал, точно, как на ней, т. к. идентифицировать ее не удалось - или что-то очень специализированное, или имеет еще какое-то название.
Может кто знает, что за зверь, нужно одно из двух - или даташит на эту микруху или схема ECU.
Черкните, если кто встречал подобную инфу.

Сильно предположительно: Какой-то высокоточный таймер? "Своими силами" процу не хватит быстродействия и точности, чтобы ТОЧНО замерять период между сигналами - вероятно для этого эта микруха и есть. А можно посмотреть какие еще датчики заведены на нее? На АТ там ВЕРОЯТНО будут вход/выходные валы. А вот что там еще может быть - это интересно.

[dmitrij_b]

Насколько я понял из беглого чтения инета через эту-же микруху идет управление катушками...

[gktuning]

Через нее проходит большинство сигналов от / к портам проца. Ну, например, сигналы управления катушками зажигания проходят через нее, приходят на микросборку из двух NPN транзисторов и с нее - на катушки.
Похоже, на какой-то шинный усилитель-формирователь. Возможно, набор программируемой логики.
Он так выглядит: