Jump to content

    

TAutomatic

Участник
  • Content Count

    59
  • Joined

  • Last visited

Community Reputation

0 Обычный

About TAutomatic

  • Rank
    Участник
  1. Источник исключени HardFault в LPC1768

    Цитата(MBR @ Sep 12 2012, 09:58) в принципе, все это умеет моя операционка, mkernel. Я сегодня буду делать коммит, как раз с этой частью кода. Пример можно взять там. Спасибо, посмотрим.
  2. Источник исключени HardFault в LPC1768

    Цитата(jt777 @ Sep 7 2012, 17:14) Оуууу указатели это да. штука веселая, осмелюсь дать совет инициализировать все указатели, было когда то дело, при останове в определенной функции проц улетал в нирвану, оказалось j-link, для отладки, пытался прочитать данные по несуществующему адресу. Возился очень долго))) Спасибо за совет. С указателями я работаю плотно и дружественно уже давно, лет 15 Но казусы с неинициализированными указателями бывают у всех...
  3. Источник исключени HardFault в LPC1768

    Цитата(jt777 @ Sep 7 2012, 14:40) А позвольте поинтересоваться IDE какую используете? если Keil то вот дока для выяснения причины исключения http://www.keil.com/appnotes/files/apnt209.pdf Да, Кеил. Дока не помешает в любом случае, спасибо. Причину уже нашел. Люблю указатели, но стоит иной раз "поработать" с неиницализированным указателем... Вот, вызывало исключение HardFault....
  4. Источник исключени HardFault в LPC1768

    Цитата(SII @ Sep 7 2012, 13:12) Читать документацию на архитектуру про исключения вообще и про HardFault в частности -- там всё расписано. К конкретному типу Как-то замудренно сильно. У Пиков гораздо понятнее и более нагляднее. Жаль, что разработчики ARM не позаботились о пользователях. Все это можно сделать аппаратно и показать наглядную инфу например в отладчике.
  5. Как определить причину вызова этого исключения? Столкнулся с проблемой возникновения этого исключения, хотя версия этого проекта трехдневной давности работает нормально. Причем и текущий проект работает нормально, если одну из ножек замкнуть на корпус. Непонятная ситуация.....
  6. Прием по USART1 через DMA1

    Цитата(MK2 @ Sep 6 2012, 21:21) Столкнулся с проблемой приема байтов по USART1 через DMA. Инициализация проходит успешно, первый массив принимается, этот канал DMA останавливается. Массив обрабатывается и все дальше DMA не хочет запускаться Счетчик стоит в 3FF, бит EN в 1 и все! ничего не идет. Так же используется канал 6 DMA на нем висит I2C прием. Камень F100C4, среда IAR 6.40 Что делать? Кто-нибудь сталкивался? Я использую другой камень, но я сталкнулся с аналогичной ситуацией: после приема нужного количества байт прерывание генерируется, но более не принимаются данные. Решил проблему путем частичной переинициализации DMA после приема. Тоесть там где я обработал очередной блок данных, снова устанавливаею в DMA нужное количество данных для приема и начальный адрес буфера приемника. Может это не совсем красиво, но работает. Другого способа я не нашел.
  7. Протокол программирования ISP

    Цитата(mempfis_ @ Sep 1 2012, 19:29) Я тоже этим не интересовался. Если в позиции 0x1c у топикстартера 0x00000000 то пусть возмёт первые 7 векторов, сложит их ограничивая разрядность в 4 байта, из 0x100000000 вычтет результат и найденную контрольную сумму расположит начиная с позиции 0x1c. Если заработает значит проблема была в этом. Судя по всему у топикстартера именно так и оказалось, по адресу 0х001С нули. Хотя мне это странно, я был уверен, что Кеил должен приготовить файл для прошивки с учетом сигнатуры работоспособности. Значит FM генерирует нужную контрольную сумму и вносит ее в нужное место. Осталось только в понедельник опробовать. Но тут меня одно не понятно. Я же описывал, что сканил обмен FM и контроллера и моей программы и контрллера. Я не увидел разницы в этом месте в нулевом секторе. Плохо что ли смотрел, где мои глаза были.... Ну понедельник все расставит на свои места, отпишусь... Цитата(TAutomatic @ Sep 1 2012, 22:50) Судя по всему у топикстартера именно так и оказалось, по адресу 0х001С нули. Хотя мне это странно, я был уверен, что Кеил должен Топикстартеру так не терпелось, что съездил в офис проверить... Просто очень нужен был этот самодельный прошивальщик. Жму руки всем за участие, особая благодарность KRS и mempfis_. Дествительно, кеил генерит хексфайл без сигнатуры валидности программного кода, маджик на лету правит и вписывает что нужно. Странно, как я не заметил это сканером сличая свой обмен и меджика. В общем, прощивальщик заработал, что и нужно было. Еще раз всем спасибо. Тема закрыта.
  8. Протокол программирования ISP

    Цитата(KRS @ Sep 1 2012, 15:26) не всегда! все зависит от тулчаина. проще всего бинарник посмотреть и проверить. И кстати не знаю как флеш маджик, а еще Philips Flash Utility считала контрольную сумму налету. Я с Вами согласился бы безоговорочно в других условиях, но не этих. Смотрите, я же описывал. гружу hex файл в FM, он принимает по-моему только hex файлы, сейчас утверждать не буду, посколько дома, проверить не могу. Так вот этот файл он защивает в проц и тот начинает работать. Можно предположить, что сам FM высчитывает сумму векторов и вписывает ее в адрес 0х001С. Так нет же, я проверяю сканером, 0 сектор он записал таким, какой он в исходном hex файле. Причем, я тоже никаких сумм не высчитываю, записываю "как есть" , сравнение дампа 0 сектора, полученнго сканером и дампа сектора 0 полученнго тоже сканером от FM показывают их идентичность.
  9. Протокол программирования ISP

    Цитата(mempfis_ @ Sep 1 2012, 14:57) Я бы предложил Вам пойти по длинному пути тщательной отладки. Дело в том, что у меня все это есть. Я программирую контроллер не с помощью контроллера, а с помощью ПО для компа. Весь обмен снимется сканером COM порта. Скан аналогичен скану работы FM. Могу даже вылажить оба файла, там все очевидно. Их можно сравнить какой-то программой сравнения текста. Все идентично, за исключением одного - после прошивки моей программой контроллер не стартует. И это угнетает, так как есть что-то на "ровном месте", чего я не могу понять и пока никто не подсказал.
  10. Протокол программирования ISP

    Цитата(KRS @ Sep 1 2012, 13:14) А как вы его запускаете? После физического ресета тоже не стартует? Контрольная сумма векторов прерываний посчитана? (иначе вход в бутлоадер принудительный) Если командой бутлоадера Go запускать надо флешь отмапить на адрес 0, кроме того надо учитывать что бутлоадер проинитил часть периферии и PLL. Конечно физическим ресетом Вы вот в тупике, как такое может быть, и я вот тоже. Контрольная сумма векторов считается, как я понимаю, автоматически при генерации bin и hex файлов, я так понимаю. Во всяком случае, FM не делает каких то доп. операций. После записи 0 блока, FM начинает писать именно с самого старшего значащего блока к младшим, он не подает команд GO, просто останавливает процесс и все. Все очевидно: стирает все нужные сектора размером под прошивка, затем записывает блоки в озу, подготавливает сектора для записи, перписывает озу во флеш. И так все нужные блоки. Я делая тоже самое. Скан моего обмена отличается только незначащими дополнительными байтами. Но после аппаратного ресета прошивка не запускается
  11. Протокол программирования ISP

    Цитата(mempfis_ @ Sep 1 2012, 10:44) Хочу уточнить на всякий случай - Вы берёте hex-файл как есть и отправляете? или всёже декодируете его в бинарные данные, которые потом кодируете uu-кодированием и отправляете в flash? Заставте keil сгенерировать бинарник для прошивки. Ну конечно же hex файл я не отправляю как есть. Это текстовый файл с сопутствующей информацией. Я его транслирую в бинарник образа прошивки в памяти программы. Просто этот метод работы я использую по наследству. У меня уже есть свой программатор для PIC24, выдернул оттуда код да и все. Структура Intel hex файла стандартная. Естественно, двоичные данные кодирую, иначе контрольная сумма не совпала бы и контроллер бы у меня запрашивал повтор передачи Цитата(KRS @ Aug 31 2012, 23:08) это еще с первых LPC2000 пошло почему то бутлоадер при старте не мапит флешь на адрес 0 (хотя сам больше ни прерываниями ни этой областью не пользуется). Поэтому что бы корректно работала проверка и чтение флеша, надо записать в регистр значение что бы отмапить флешь на адрес 0. Да, я уже догадался, что эти действия нужно выполнять только при верификации. Может верификация не столь актуальна, если в процессе записи на все контрольные суммы блоков получены подтверждения. Но все же ее тоже стоит освоить. Получается ответ на вопрос, что это за сигнатура в 16 байт, вернее 2 разных сигнатуры по 16 байт, нужно искать в описании программирования старых LPC. Цитата(KRS @ Aug 31 2012, 23:08) Кстати при первоначальном тестировании можно вообще флешь не шить а в рам запускать программу, бутлоадер это позволяет а результаты тестирования через тот же уарт и получать... Здравая идея. Я пока не додумался, поскольку ни разу не пользовался такой возможностью. Это мой первый проект на ARM и все возможности контроллера использовать просто не в состоянии. Цитата(KRS @ Aug 31 2012, 23:08) А вы описание бутлоадера читали? А Applicatiion Notes от NXP? (например AN11229) Какой смысл делать reverse engineering флешь маджику если полно открытой информации? Кстати писать можно и по 4 кб за раз (а у некоторых LPC ЕМНИП и по 8), а считывать вообще сразу всю прошивку одной командой. Нет, описание загрузчика не читал, спасибо за информацию. Ерунда какая-то вообще получается. Прочитал документ AN11229, да, все красиво расписано. По поводу добавления байт в блоки, не кратные 3. Пишут, что можно добавлять что угодно, сами добавляют 0. Хотя FlashMagic добавляет какждый раз разное число. Ну тогда мне вообще не понятно. Думал, это последняя проблема, стоит ее устранить и все заработает. Не работает. Есть три 100% факта: 1 моя программа очифает флеш контроллера. После очистки, во-первых девайс перестает работать естественно. Это внешний признак. Во-вторых, при проверке на чистоту с помощью FM говорит, что чистый. 2 запись тоже работает, поскольку после записи моей программой верификация с помощью FM подтверждает идентичность прошивок. 3 скан процесса программирования с помощью FM и моей программы с последующей ферификацией с помошью, например UltraCompare показывает полную идентичность за исключением времени посылок и добавочного 18 байта в каждом секторе. Не понимаю, почему контроллер на запускается после прошивки.
  12. Протокол программирования ISP

    Цитата(mempfis_ @ Aug 31 2012, 19:39) При заливке программы выключаю питание, замыкаю перемычку boot, включаю питание, синхронизируюсь, прошиваю, выключаю питание. Далее снимаю перемычку boot, включаю питание, контролирую запуск программы. У меня такая же пермычка и кнопка Ресет. Цитата(mempfis_ @ Aug 31 2012, 19:39) Сами заведомо рабочие и отлаженные прошивки получаю из IAR путём генерирования бинарного файла. Размер файла кратен 512 байтам - т.е. кратен размер uu-кодированного блока данных. Основная программа занимает всю flash, а тестовая столько сколько надо, если она не кратна 512 то дополняю её 0xff. Вы уверены то бинарный файл что Вы отправляете рабочий? Или он правильно кодируется и отправляется? Я прошиваю hex файлом из Keila. С помощью FlashMagic он прошивается, убираю пермычку, нажимаю кнопку Ресет, программа работает. Прошиваю этот же файл своим изделием... Опс, и ничего Я снял с помощью сканера обмен FlashMagic и свой. Разницы нет никакой. За одним исключением. отправляются блоки не более 45 байт, правильно? Получается отправляем на один сектор 512 байт 11 блоков полных по 45 байт и двенадцатый блок размером 17 байт. Но мы должны при UU кодировании иметь целое количество троек. Тоесть нужно дополнять 17 байт восемнадцатым. Как он определяется, я не могу понять. В описании есть что-то невнятное типа байты надо вычесть из номера линии. Какой номер, какой линии? Они же не нумеруются. Но запись секторов у меня все равно проходит успешно. После записи контрольной суммы контроллер возвращает ее и ОК. Да и понятно, контрольная сумма то формируется из исходных байт, еще не кодированных. Но после полной прошивки контроллер не стартует. И это не понятно. Сейчас посмотрю Ваши исходники, но я на первый взгляд не нашел ответа, чем заполнять последний байт. То, что он как-то вычисляетя, нет соменений, в конце каждого сектора он разный.
  13. Протокол программирования ISP

    И еще вопрос, не могу сообразить, как правильно дополнять в последнем блоке, который из 17 байт, до размера, кратного 3?
  14. Протокол программирования ISP

    Цитата(mempfis_ @ Aug 31 2012, 11:24) А далее передёргивал питания и контролировал запуск программы. Бог с ним, с верификацией. Тоесть у Вас после выполнения всех описанных шагов контроллер запускался? Странно, делаю тоже самое, проверил и перепроверил еще раз. Все аналогично. Но у меня контроллер не запускается
  15. Протокол программирования ISP

    Цитата(mempfis_ @ Aug 31 2012, 11:24) Занимался подобным проектом месяц назад. P.S. Если разберётесь зачем для корректного чтения необходимо отправлять дополнительные команды, напишите сдесь. Спасибо, посмотрю документы. У меня таких не было. Очистка памяти и запись все прошивки у меня работает. Теперь надо разобраться с моментом, который я описал и с верификацией. Честно говоря, если бы был в распоряжении только манул, то по главе 32 трудно было бы все это реализовать. Помогла инфа из инетета да снифер компорта при программировании с помощью FlasMagic Самое интересное все работает. Я стираю девайс своими процедурами. И таки реально стирает, поскольку проверка на чистоту FlashMagic говорит, что читсый кристалл. Записываю прошивку. Верифицирую FlashMagic - говорит что идентично. Почему контроллер не оживает, как после выполнения этих же процедур полностью FlashMagic - не понятно.