sst78rus

Команду диагностики я послушаю в CAN шине. Этот датчик сидит на отдельной CAN шине и общается только с блоком ESP. Из pyren вытащить команду калибровки не получится, поскольку pyren командует блоку ESP, а уже тот командует датчику. Просто нет машины подходящей для экспериментов под рукой. Но вопрос решаемый и я именно так его и решу - через pyren запущу процесс калибровки и послушаю обмен на шине. В байте контрольной суммы присутствуют какие-то флаги. Не особо важно для моих целей, но все же было бы неплохо разобрать. И еще один довод для чтения дампа - у меня шина в которую хочу подключить этот датчик на 1000 кб/с работает, а датчик на 500 кб/с. При наличии дампа, вполне может получиться пропатчить инициализацию CAN и не использовать лишних шлюзов.

Я извиняюсь, если обижу вопросом, но вы же инициализируете в 1-битном режиме, а потом командой ACMD6 переключаете в 4-х битный? Что значит "зависает", ответа на ACMD6 нет? Осциллографом смотрели на линии данных? Если решите проблему, напишите тут пожалуйста. Микросхема выглядит прямо как мне нужно 🙂 Интересно как оно на практике. "Запаянная sd карта" это emmc. Но emmc это bga, не очень удобно паять. Для устройств из которых карту вынимать не предполагается, такой вариант прямо то, что нужно. Объем только не большой.

Спасибо, почитал User Manual, есть режим прошивки по UART. Утилиту пока не нашел, но продолжу изучение сайта 🙂 Немного огорчает только, что в User Manual упоминается возможность записи и стирания по UART, но про чтение ни слова. По поводу защиты от чтения - я тоже был уверен, что она везде и всегда включена. Тем более на устройствах, которые перепрограммировать не предполагается. Но, как ни странно, оказывается, что во многих автомобильных блоках защита от чтения не стоит. Ну попробовать в любом случае стоит.

Добрый день. Есть задача попытаться прочитать флеш с МК Infineon XC886 (https://www.infineon.com/dgdl/Infineon-XC88XCLM-DS-v01_02-en.pdf?fileId=db3a304412b407950112b40c4a9e0afb). Я прекрасно понимаю, что может стоять защита от чтения, но думаю стоит попробовать. Согласно даташиту, МК построен на High-performance XC800 Core – compatible with standard 8051 processor. У меня есть опыт работы с ARM контроллерами, которые прошиваются по SWD, с 8051 не работал. В наличии есть J-Link. В списке совместимости Segger такого МК нет. Насколько я понял, программируется он по JTAG. Я нашел пример демо-платы, для программирования на разъем JTAG выведено много ног. Я правильно понимаю, что для чтения и записи мне достаточно TCK, TDO, TDI и TMS? На плате есть пятаки на этих ногах, можно удобно подпаяться. В описании от Infineon для программирования предлагается ULINK2. У китайцев вроде есть недорогие клоны https://aliexpress.ru/item/1705172312.html Есть шанс, что заработает? PS: МК стоит на плате автомобильного датчика. Я хочу использовать этот датчик в своих целях, мне нужно разобраться с протоколом обмена по CAN. Основные параметры я разобрал анализом шины, но некоторые параметры таким образом не узнать. Если получится считать прошивку, возможно в дизассемблере удастся выяснить то, что мне нужно. Все что удалось узнать - https://github.com/Sergey1560/sas

Да, извиняюсь, про корпус пропустил. tqfp-48 корпус. Ближе фото нет сейчас к сожалению. Попробую сравнить с XC800 по выводам питания и ногам кварца.

Добрый день. Есть устройство с МК от Infineon с маркировкой K886C8RAA. На сайте infineon поиск по этой маркировке совсем ничего не выдал. Гугл выдает только пару торговых площадок. Нужна документация по этому МК, datasheet, reference manual, описание интерфейса его программирования.

https://github.com/racerxdl/stm32f0-pico-dump У меня на тестовой плате с F030 работало. Поскольку использует ногодрыг, вместо pico можно использовать что угодно.

Спасибо, посмотрел. Тему эту периодически читаю, но как-то пропустил. Т.е. судя по диалогу там, ограничения в прошивке самого J-Link, а не в dll. Поправить самостоятельно J-Flash я бы возможно смог, а для прошивки опыта не хватает. Но по совету UniSoft данные все же забекапил :) Я правильно понял Ваше последнее сообщение, на 83 странице, что если использовать J-Link 6.30, то указанными там командами можно добавить лицензию на Flash? Этого будет достаточно? PS: оказалось в китайце есть уже JFlash лицензия. Попробую с ним, возможно и не придется EDU курочить :)

Изучаю вопрос прошивки spi flash через подключение к МК. Судя по описанию, это делается через J-Flash. В описании различий в моделях J-link указано, что этот функционал для EDU и BASE не поддерживается. А где сделано это ограничение, в J-Flash или в прошивке самого J-link? У меня в наличии оригинальный v11 EDU и китайский клон v9.4. Возможно чем-то из них прошивать spi flash?

Благодарю. Убрал RDDI и заработало без defective.

Я видимо что-то не понимаю. По ссылке на гитхаб, лежит бинарник с прошивкой от 8 марта 2020. В библиотеке JLink последняя версия для OB от 7 января 2019. При этом, если верить гитхабу, бинарник был залит 6 декабря 2017 года и больше изменений не было. И вообще последние изменения в там были 2 года назад. Кто-то похоже все таки сделал машину времени :) x893, благодарю, понял по поводу обновления.

А откуда эта прошивка? С ней так же говорит про defective, но прошивка внутри от 8 марта 2020. JlinkConfig версии 6.86d имеет внутри прошивку от 7 января 2019.

Да, клон. Извиняюсь, сразу не уточнил. На stm32f072c8t6 сделан. Фото показывать особо смысла нет, на плате только МК, 4 конденсатора, 2 резистора, светодиод и ams1117 :) Посмотрел по ссылке с предыдущей страницы, вроде бы "условия" выполнены - GDBFULL нет в списке лицензий, за серийным номером идет 0xFF. До недавнего обновления JLink-а работал без предупреждения о devective.

Добрый день. Есть J-Link OB-STM32F072-CortexM, на последних версиях JLink стал писать, что он defective, хотя работать продолжает. Как оказалось, МК на нем не защищен от чтения, соответственно считал с него прошивку, исправил серийный номер на одну цифру (стоял не -1, а какой-то осмысленный) и залил обратно. Однако все равно Jlink считает его defective (исправленный серийник отображается верно). Не подскажете, на основании чего JLink определяет его как defective и можно ли это исправить в прошивке? Пока просто пропатчил библиотеку, чтобы убрать окно, но делать это после каждого обновления не хочется.

Вот тут есть пример использования - https://www.youtube.com/watch?v=q4CxE5P6RUE&t=622s Я только не нашел как перенести "отладочную информацию" из гидры куда-нибдь в отладчик. Благодаря "псевдокоду" удобно разбирать что происходит и можно "переименовать" интересующие функции, добавить комментарии к коду и т.д. Но не всегда получается чисто статически разобраться, иногда удобнее в отладчике посмотреть. И вот было бы здорово или подключить отладчик интерактивно (так точно умеет IDA с x86 кодом), или хотя бы экспортировать комментарии в отладчик. Сейчас пользуюсь Ozone в качестве отладчика и во втором окне смотрю в гидре подсказки, что происходит. Код который разбираю был на С++ и много вызовов происходит очень не очевидно, без отладчика не понять куда будет переход.