esaulenka

и что поменялось? 'error determining flash info' явно не будет ввиду отсутсвия такового запроса. Что "то же самое" ? "просто arm7" ничего никуда записать не может. И я не говорил "arm7", я говорил "samsung", это принципиально важно. Попробую чуть-чуть навести порядок в вашей голове. Читать из флеш просто - выставляем нужный адрес, забираем данные. Точно так же работает чтение и запись в ОЗУ. А вот для записи во флеш нужны определённые магические действия: прошивальщик записью в определённые регистры должен запустить стирание, потом подождать (проверяя готовность чтением регистра статуса), потом инициировать запись, скопировать кусок данных, и снова подождать (опять с проверкой готовности). Стандартный подход - создание небольшой программы специально для этого, которую прошивальщик заливает в ОЗУ контроллера, и дальше только "кормит" её данными. Последовательность этих "магических действий" у каждого производителя своя (часто и между моделями есть отличия). Ну попробуйте J-Mem ещё. Простейшая утилита, которая умеет только читать память, зато - любую, какую попросить. Можете ей посмотреть содержимое ОЗУ или периферийных регистров, например. А вообще говоря, правильно начинать с документации. Я вот полистал даташит и убедился, что флеш и ОЗУ включены всегда (эх, здравствуй 2006 год, камень примитивный совсем..). Т.е. оно ДОЛЖНО отдавать какие-то данные.

Ох... Ну зачем же _фото_ ?! Есть прекрасная кнопка PrintScreen (или, на win10, ещё более прекрасная Win-Shift-S). Быстро, удобно, и гораздо более читаемо. Подозрения подтверждаются - в Сеггере считают, что память там внешняя. Походу, они что-то напутали в самсунговской номенклатуре. Варианты действий: - попробовать снять галку "Automatically detect flash memory". Записать ничего не получится, но, возможно, даст прочитать. - попробовать выбрать другие процессоры в настройках. Попутно очень желательно сравнивать даташиты, чтоб там алгоритм записи (и соотв. регистры) соответствовали вашему процессору. Возможно, какой-то другой самсунг подойдёт. - вдумчиво покурить сеггеровские доки и написать загрузчик самостоятельно. Я так не делал, но вроде б это не запредельно сложно. - если вы платили Сеггеру деньги (ну, вдруг?), самое время написать в техподдержку 🙂 PS ссылка на даташит, если кому-то ещё будет интересно: https://www.datasheetarchive.com/datasheet?id=2342587efb1d49c7ec3feaee40e48b07fad5d9&type=P&term=s3f4a0k

Наоборот. Reserved и DataFlash по умолчанию недоступны. Хм. 32k RAM + 1M Flash. Странная пропорция, но автопроизводителям виднее, не зря ж они такой проц выпустили... У меня два предположения: - если у вас по-прежнему вот такая картинка, то, возможно, вам нужно поискать, кто мешает отладчику - кажется, судя по слову CFI, J-Flash пытается искать внешнюю флешку. Либо это следствие "универсальности" джейфлеша, либо Сеггер ошиблись с моделью процессора и по факту он не поддерживается. У меня сейчас под рукой джей-флеша нет, как там настройки для этого проца выглядят?

Уже хорошо. У меня почему-то подозрение, что вы пытаетесь читать внешнюю флешку. Давайте подробности - что у вас на плате (проц + внешняя SDRAM ?), как сконфигурирован J-Flash, какие конкретно ошибки при чтении? Я вижу, что отключена только data flash. Остальное, если верить даташиту, должно быть доступно.

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

А у меня два монитора и несколько проектов, в каждом из которых по полсотни исходных файлов. Вы уж определитесь - у вас всё хорошо, или "куча варнингов, проблемы, я не понимаю". "приравнивается к единице" записывается как "var = 1;", а тут, с высокой вероятностью, написана ерунда. В вашем коде ДВА вызова eeprom_write_block. Найдите оба и сравните адреса, которые вы туда передаёте. Сравнить два массива. Ну ок. Вы даже читать не пытаетесь. Вопросов больше не имею.

Потому что заголовочный файл может include'иться в несколько .c файлов одновременно. Ваш подход приведёт к образованию нескольких копий переменных, и благоприятный исход всего этого - линкер при компиляции выдаст ошибку (неблагоприятный - накомпилирует чёрт знает что). Размер массива в байтах, в документации вполне явно написано. Ну и это не с++, компилятор не сможет узнать размер одного элемента. У вас, кстати, с этими eeprom read/write ещё одна ошибка. Надо указывать адреса так, чтобы они не перекрывались. Сейчас massive_open состоит из одного байта, принятого при открытии и "хвоста" из massive_close. Ещё одно "темное" место: if (button_open) { flag_button_open; } ... if (flag_button_open) { ... Что такое flag_button_open ? если это переменная типа bool, то что происходит в начале? И ещё. Что за магия с memccpy ? Вы точно хотите использовать это вместо обычного memcpy ?

Несколько замечаний. Сам алгоритм не пытался понять, чисто визуально. 1) вы не приложили main.h, в котором, подозреваю, определены переменные. В заголовочных файлах в 99% случаев нужно делать только объявления (declaration) с префиксом extern, а не определения (definition). Ваш подход приведёт к "непонятным" проблемам, если проект разрастётся до нескольких .c файлов. 2) в обработчике прерывания таймера вы записываете значения (не очень понятно, какие, ну да ладно) в массив без проверки значения 'i'. Это может закончится порчей памяти и очень странными ошибками. 3) eeprom_read_block, eeprom_write_block, memcmp в качестве последнего аргумента используют размер в байтах. 'unsigned int massive[10]' в случае AVR имеет размер 20 байт.

либо, как вариант, https://www.segger.com/supported-devices/infineon/fm3

Так бывает разве? Там весь обмен защищён какой-то примитивной контрольной суммой - бит чётности, что-ли. Т.е. при настабильной работе (скорость высокая, провода - метровая лапша, и т.д.) отладчик просто отваливается. Но я с ST-Link не очень много работал, может они "забыли" это реализовать.

Похоже на собственную реализацию SWD (хотя... мне кажется, программный SWD слейв сделать довольно сложно, там интерфейс тактируется отладчиком, и устройство как-то должно за ним успевать). Попробуйте Connect under Reset, или как оно у куба называется. В этом случае вы точно будете общаться с "оригинальным" SWD. Но в любом случае, как-то фантастически это всё звучит...

находится в porttimer.c находится в mbrtu.c находится в portevent.c Ни один из этих файлов в проект не включен. Какие пути вы проверяли? PS да, обратите внимание в каталоге port есть комплект файлов с суффиксами `_m`. У меня подозрение, что это для modbus master (без таковых - будет slave). В проект надо включать только один комплект, иначе будут новые ещё более "непонятные" сообщения линкера.

Когда-то давным-давно я использовал вышеупомянутый код Алекса для прошивки NRF52. А он его под Atmel'овские кортексы писал. Так что да, SWD довольно стандартный. Проблема, правда, в том, что SWD ногодрыгом получается довольно медленный. Я в итоге сделал микро-загрузчик, который SWD пишет в RAM, а вся основная прошивка передаётся по UART. Какая магия используется в JLink / STLink, я не разбирался.

Я тут мимопроходил, но википедия говорит, что Возможно, в этом была ваша проблема. А сами по себе симлинки в NTFS давно есть. Симлинки на каталоги появились в win2000, на файлы - в winxp.

Давайте всё-таки определимся, что такое "размер файла" ? Количество данных, которые там содержатся? Ваша магия на awk'е, кажется, должна корректно это считать. Но я плохо понимаю, зачем это нужно, поскольку из-за потенциальных "дырок" арифметика вида стартовый адрес + кол-во данных = конечный адрес здесь не работает. Этот топик вы начинали с вопроса "хочу найти конечный адрес". С применением удобных инструментов это решается очень просто: #!/usr/bin/env python import sys from intelhex import IntelHex ih = IntelHex(sys.argv[1]) print('min addr = %X, max addr = %X' % (ih.minaddr(), ih.maxaddr()))

Не надо так делать. Во-первых, в HEX файле некоторые строки - служебные, и содержат, например, адрес, с которого эта программа должна стартовать. Или наоборот, в hex-файле допустимы "дырки" в данных. Т.е. посчитать-то можно, но "простенький" код при изменении входных данных может внезапно сломаться, и выдавать ПОЧТИ правильный ответ.

Ну очевидно же, что оригинальный вопрос надо читать как "определить размер данных (макс. адрес) внутри хекс-файла". Можно, конечно, разобраться в формате hex и парсить его самостоятельно длинными регекспами, но в жизни есть и более интересные занятия. @VaTiKaNeTs, у вас на выбор два варианта. Можно внимательно прочитать доку к srec_cat, оно так точно умеет, я делал. Другой вопрос, что при малейшем изменении придётся её читать заново и всё переписывать, синтаксис сложных команд там совершенно нечеловеческий. Второй варинат - взять прекрасный питоновый модуль IntelHex, и написать два десятка строчек (из них половина - расчёт CRC).

Первое утверждение (что append() - это новый абзац) - из документации на QTextEdit. Второе, действительно, касается QPlain..., но в первом же ответе упоминается, что в обоих случаях поведение одинаковое. Чем поможет ваша ссылка, я, если честно, не понял. Один вызов append() добавляет один абзац. Ну да, это логично. Для добавления нескольких можно побить добавляемый текст символами '\n'. Тоже логично. Только к обсуждаемой "проблеме" отношения примерно никакого.

Согласно документации, append() 'appends a new paragraph to the end of the text edit'. Тут надо либо делать промежуточный обработчик "протокола" и выводить уже готовые склееные строки, либо применять магию для вывода: https://stackoverflow.com/questions/13559990/how-to-append-text-to-qplaintextedit-without-adding-newline-and-keep-scroll-at (я не пробовал, просто спросил у гугла).

Можно, конечно. И более новые тоже можно - активно денег они хотят только за всякий embedded. Нет, это и было, и остаётся нарушением GPL. Ну, если только вы не готовы выдавать ВСЕ исходники всем желающим - тогда можно.

Могу предположить, что вы делаете опечатку в названии месяца, и Filezilla не может его распарсить.

Если передавать в бинарном виде, это всего 3*2(у вас же <=16 бит АЦП?)*6000 = 36kbyte/sec. В 115200 не лезет, но в мегабитный UART с бааальшим запасом на любые протоколы. Правда, не уверен, что вы сможете перепосылать ошибочные данные - только выкидывать битые. Ну да ладно. У меня другой вопрос - что такое while (cs.cbInQue) { ... и зачем оно тут? Достаточно ж вроде верхнего цикла. Ещё вопрос. Вы можете поменять софт отправителя, чтобы просто слал байты по кругу? У вас потери всегда на стыке вызовов Read() (и всегда ли?) или возможны другие варианты? Ещё вопросы: SetCommMask() / ClearCommError() из цикла убирать пробовали? Кажется, так делать не обязательно. И вообще, чем вам QSerialPort не угодил?

А вы пробовали? Лет пять назад я собирал статику Qt5 на MSVC. Не могу сказать, что я суперкрутой программист под win32, но подбор всех ключей, чтобы оно нормально собралось и не пыталось затащить всякие webengine, занял несколько дней. Может, с mingw будет проще, но что-то я сомневаюсь... Информация на тот момент в тамошней вики была слегка устаревшая и противоречивая. Что, впрочем, можно понять - те, кому это нужно (и можно), могут и техподдержку спросить, у них уплочено.

Ну вот и получили гадание на кофейной гуще... Попробуйте лучше погадать на map-файле, там хоть будет видно, что сколько занимает.

Для начала понять бы, что именно у вас там такое большое. По опыту - всякие "излишние" фичи стандартной библиотеки занимают десяток кБ, не больше. Я пользовался этим рецептом: (что-то не могу найти его где-нибудь на гитхабе...) Но, повторюсь, магической экономии сотни килобайт он не даст, надо разбираться, что вы такое сделали. У меня прошивки в 300 килобайт ни разу не получались. Хотя не один год старался, писал 🙂