Karloson

J-Link умеет. Придется писать командный файл. Всем спасибо!

Мужики, спасибо за ответы! Эти варианты рассматривал как очевидные, но задача немного в другом: передать/переслать прошивку монтажникам на месте, у них из инструмента только J_Link, шить умеют, но что-то сложнее это уже напряг. Поэтому пытаюсь создать прошивку с областью Option Bytes (на крайняк два *.hex). Считал банк OPT 0x1FFF7800-0x1FFF 7830, заменил нужные биты (см.картинку) и зашил обратно, но биты... В общем вопрос как правильно шить область Flash OPT имея только хекс-файл? За BOOT_LOCK спасибо за наводку! Обижаете ;)

stm32G431. Печать развели так, что проц. всегда грузится в System memory (0x1FFF 0000) вместо флеш (0x0800 0000), т.к. BOOT0 (PB8) подвешен к питанию.. Решил изменить FLASH option bytes, чтоб не читал ногу PB8 при включение так (nSWBOOT0=0): const char OffBoot0[] __attribute__((at(0x1FFF7800))) = { 0xAA, 0xF8, 0xEF, 0xFB, 0x55, 0x07, 0x10, 0x04, 0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0x00, 0xC0, 0xFF, 0x7F, 0xFF, 0x3F, 0x00, 0x80, 0xFF, 0xFF, 0xC0, 0xFF, 0x00, 0x00, 0x3F, 0x00, 0xFF, 0xFF, 0xC0, 0xFF, 0x00, 0x00, 0x3F, 0x00, 0x80, 0xFF, 0xFE, 0xFF, 0x7F, 0x00, 0x10, 0x00 }; .hex файл заливается без ошибок (проверка проходит), но стоит перегрузить проц. все биты восстанавливаются.:( Есть идее как заставить грузиться на 0x0800 0000?

Поделитесь секретом, чем и как читаете. ПС: после восстановления отладчик работает как новый. Ещё раз, огромное спасибо!!!

Спасибо, восстановил. CortexM7 считал. Единственная мелочь, что он остался как "JLink driver" вместо "JLink PLUS" в диспетчере устройств. Если не секрет, откуда информация? Мне не разу не удалось считать эти программаторы, везде защита Flash.

Упал на v634h. Я на нее так "обиделся", что удалил под корень. v633h у меня не было.

Проблема как у haker_fox. отладчик V10.10 на LPC4337, кот. ушел в boot mode и не как не могу оттуда вывести? Куплен был 4 месяца назад у китайца, определялся в системе как JLink PLUS, работал отлично на JLink_V632f (в ней же и обновился до актуальной FW), но прилетела обнова до V634h... Предложила обновить FW, согласился, прошился без ошибок, но после программа его не увидела. В системе стал определяться как JLink driver. JLinkConfig.exe его то же не видит, а JLink.exe, после перетыка, предлагает снова прошиться. Ставил разные версии JLink от сиггера, чистил систему, играл разными версиями драйверов(JLinkx64.sys).

Возникла проблема - подправить старые исходники для 196. Upload file не работает. Где скачать РАБОЧИЙ С-компилятор?

4.72а к.н. пробовал? стоит скачивать - как там с кириллицей, бубен нужен?

Без микросхемы физического уровня т.н. работал? Какие результаты, устойчивость работы?

UvEdit.dll в 4.23 и в 4.60 идентичны. Если менять, то Uv4.exe из вер. 4.23. Uv4.23.zip

Для себя решил проблему так: поставил ARM 4.60 затем C51 9.50a (по факту вернул старый редактор для С51).

Последние два года работал выдирая нужный исходный код из ГУИ. Требования все растут и растут... Думаю полностью перейти на emWin. С ней кто нибуть работал? Много рисурсов отжирает?

Можно ли создать HID репорт, что бы он мог работать с массивом данных переменной длины (в пределах спецификации HID)? Это я к чему: допустим есть ХИД устройство с INPUT и OUTPUT репортами, но я не знаю, сколько байт, в конкретный момент времени, надо будет отправить или принять. Дробить пакет не хочется.

polyakovav, т.е. выкинули резюк с емкостью и тупо соединили?

Чего тут думать, RCC ковыряй, да кварцы (источники частоты).

В Reference manual в п.31.8.1 SW protocol introduction сказано: "For SWDIO bidirectional management, the line must be pulled-up on the board (100 KΩ recommended by ARM)." Уж не знаю, как строго надо этого придерживаться, но я не его не ставлю (внутреннего хватает). ЗЫ: народ, какие разъемы ставите на этот интерфейс?

Народ, чего-то я совсем запутался(. Подскажите про bit-band и extern. Создаю main.h файл со структурой bit-band: typedef struct { unsigned bTime0 : 1; }DispatcherTask __attribute__((bitband)); extern DispatcherTask Task; Главный файл с мейн такой: DispatcherTask Task __attribute__((at(0x20000000))); extern void Test(void); int main(void){ Task.bTime0 = 0; Test(); } в нем все работает правильно, т.е. адресация Task.bTime0 на 0x22000000 Есть ещё один файл *.с: #include "main.h" void Test(){ Task.bTime0 = 0; } И вот в этой ф-ции начинаются траблы: адресация Task.bTime0 на 0x20000000(( Как это победить? ЗЫ: Среда Keil 4.23 Всё, разобрался)). Надо было в *.h файле экстерн прописывать вместе с адресом: extern DispatcherTask Task __attribute__((at(0x20000000))); Почему вдруг так - загадка?

Если в проекте включить Use MicroLIB, то весь подсчет коту под хвост.

Интересную закономерность заметил.. Если флеш память прошита и хочется запустить отладчик (в рам-памяти), то для первого запуска надо нажать кнопку RESET, затем запустить отладчик и только потом отпустить кнопку. Последующие запуски отладчика запускаются без кнопки и так до след. включения питания на отлаживаемой плате. Для чего вешают подтягивающий резистор 10k на ногу RESET для STM32? ЗЫ: отладчик МТ-линк.

Можно с помощью *.ini файла, смотрите в примерах Кейла, что-то типа RAM.ini. Ещё надо подправить адреса в настройках проекта для ROM и RAM (ROM перенести в адреса RAMa).

Может вопрос не в тему, но: почему разработчики ЕвалБордов ставят внешнее АЦП для тачпанелей экрана? Чем их внутреннее АЦП не устраивает?

Слукавил я по поводу Region$$Table$$Limit. Правильно использовать Load$$LR$$LR_IROM1$$Limit и размер кода Load$$LR$$LR_IROM1$$Length, при условии, что скаттер файл по умолчанию (для STM32).

Сам отвечу)) В Keilе есть внутренний символ Region$$Table$$Limit, адрес этой переменой и есть последний адрес кода (как-то так)).

HARMHARM, в строке "--l-e-crc32 --max" параметр --max пишет CRC по махмально возможному адресу. Как потом, в своих прогах, его находите? Он ведь плавает в зависимости от размера кода.