Перейти к содержанию

marus-ka

Участник
  • Публикаций

    56
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о marus-ka

  • Звание
    Участник
  • День рождения 01.06.1987

Информация

  • Город
    Москва
  1. Всем привет! Есть необходимость создать 1-wire slave устройство, точнее сразу несколько. Так как не было ни мастера, ни слейва, нужно было для отладки создать и то, и другое. Для мастера была взята библиотека отсюда для слейва после гугления тоже нашлась, правда несколько странная и пришлось ее немного "допилить". Все работало прекрасно, пока была связь точка-точка. Как только подключаю еще один-два слейв устройства, начинается свистопляска при поиске. То одно устройство находится мастером, то два, то одно аж два раза. Было принято стратегическое решение найти "нормального" мастера и "нормальных" слейвов, чтобы тестировать с ними. В закромах Родины нашелся переходник USB-1-wire от Maxim (мастер) и платка с термодатчиком, реле и UIDом (слейвы). И тут тоже самое. Подправила задержки, вроде "нормальный" мастер обнаруживает мое устройство, но получается такая же свистопляска, если подключать более одного слейва. Все тайминги проверила ( по крайней мере постаралась). Все равно не работает( А вообще должно? Как в реальных сетях? Поиск выполняется мастером однократно в начале? Или мониторится сеть постоянно и перебои в количестве обнаруживаемых устройств это в рамках нормы? Куда копать? Тех. детали: в качестве моего слейва платка с контроллером xmega32d4, дергает ногой, не уартом.
  2. Error[Lc003]: IAR for ARM

    Сама не люблю темы без окончательного ответа, поэтому решила отписаться. Изначально было непонятно, какие настройки линкера стоит ставить для совпадения программного и линкерного расчетов, правильно ли считается программно, по какому диапазону считается CRC (совпадает ли он с диапазоном заполнения), есть ли какие-то отличия в алгоритме подсчета CRC для первых байт (или таблицы векторов прерываний) и для остальной части кода, почему для заполненных диапазонов CRC программное и линкерное совпадало. Были прочитаны форумы, википедии и документация на линкер. В итоге мне помогло тупое перебирание способов подсчета CRC (разных галочек в меню линкера) и порядка байт при подсчете. Смогла проверить с помощью он-лайн калькулятора CRC программный способ подсчета CRC. Программно все было правильно. А с помощью калькулятора все гипотезы удавалось проверять быстрее, чем прогоняя код. Для проверки для простоты брала первые 2 или 4 байта ( в разных экспериментах) с первой страницы кода. Было выяснено, что IAR при подсчете CRC два соседних байта меняет местами. Причем, если убрать галку с пункта reverse byte order within word (что должно бы помочь от смены мест байт), получается еще какой-то вариант расчета, который не совпадает ни с одним из тех, что представлены в калькуляторе. При подсчете CRC области памяти заполненной одинаковыми байтами линкерный и программный способы совпадали именно из-за одинаковости байт. Они менялись местами, но так как одинаковые, на результат расчета это не влияло. Еще были сомнения, что CRC считается как-то особенно для первых байт или таблицы векторов прерываний. Это не подтвердилось - проверила с помощью подсчета CRC по алгоритму прямой суммы. Таким образом, для обеспечения совпадения программного и линкерного расчета перед программным расчетом меняю соседние байты местами.
  3. Error[Lc003]: IAR for ARM

    У меня изначально была концепция проверять crc в бутлоадере, поэтому такой подход как у вас, если я его правильно понимаю, мне не подходит. Пока от своей концепции я не хочу отказываться, но, возможно, придется. Я изначально хотела не скопировать чей-то пример, а разобраться, именно поэтому задавала и задаю вопросы. Если вы не считаете нужным и правильным отвечать, зачем тогда продолжать разговор?
  4. Error[Lc003]: IAR for ARM

    Спасибо за уделенное время. Контроллер у меня другой алгоритм расчета Crc тоже. Поэтому предоставленные вами примеры мне не сильно помогли, к сожалению. Я, естественно, перед тем, как писать на форум, попробовала все возможные настройки линкера и прочитала документацию на компилятор.
  5. Error[Lc003]: IAR for ARM

    Цитата(jcxz @ Oct 3 2014, 16:51) Что значит "делать заполнение"? Start address и End address - это начальный и конечный адреса области, для которой рассчитывается CRC. А Fill pattern нужно ставить равным содержимому стёртой флеши. Обычно это FF или 00. Для меня это не очевидно. Поля Start address и End address доступны для записи в них значений даже если расчет CRC не производится. Поэтому более логично, что это именно диапазон для Fill pattern. И путем экспериментов выяснила, что диапазон расчета CRC совпадает. Только вот сама crc не сходится. Да и так уж обязательно, что это должно быть значение стертой flash? Я в документации на IAR этого не нашла. Насколько я помню там пишут, что это может быть любое число. Цитата(jcxz @ Oct 3 2014, 16:51) То же самое, что и для чего-либо другого: величина выравнивания. Мне понятнее не стало, так как я меняю это значение адрес crc не меняется. Или что должно меняться в зависимости от выравнивания? Просто это мой первый опыт работы с 32х разрядными МК, а в 8 разрядных как-то не приходилось с этим сталкиваться.
  6. Error[Lc003]: IAR for ARM

    Спасибо за ответ! Мне в нем еще разбираться и разбираться))) У меня IAR 7.20 и контроллер SAM D20. А у меня вот такие настройки: [attachment=87325:CRC_screenshot_IAR.jpg] 0x4000 это адрес начала application section. Если делать заполнение с 0 до 0x4000, а в bootloader считать CRC от массива с таким же заполнением и длиной, то все сходится. Как только добавляю хоть одну страницу кода, не сходится. Если считать только одну страницу кода, тоже не сходится. Если считать страницу кода после таблицы векторов прерываний, не сходится. И еще вопрос от блондинки, никак не могу понять что значит aligment 4 для CRC16. Понимаю, что глупый вопрос, но вот так)
  7. Error[Lc003]: IAR for ARM

    Всем привет! И снова у меня проблемы с crc. Теперь с IAR ARM. Пыталась двумя способами: через меню линкера и через файл линкера. Через меню: не сходится с программным расчетом. Что пробовала: разные алгоритмы: CRC16, CRC32 и разные настройки (Reverse, initial value и т.д.) Код для программного расчета брала из EWARM IAR C/C++ Development Guide Что непонятно: как указывать диапазон адресов из которых вычисляется CRC? (есть подозрение, что это несовпадение связано именно с несовпадением диапазонов данных, которые считаются) Совпадает ли он с диапазоном для Fill unused code memory? А если нет, то как его настроить, чтобы вычислялся только по коду, а не по пустому месту? Через файл icf: постоянно возникает ошибка Error[Lc003]: expected "check", "define", "do", "export", "if", "include", "initialize", "keep", "place", or a placement label, D:\IAR_projects\ARM\concentrator_RE013_M0+\samd20g16_flash.icf 78 В icf файле определяю блок CHECKSUM, и пишу следующее из EWARM IAR C/C++ Development Guide ielftool --fill=0xdd; 0x00000000 – 0x00010000; --checksum=__checksum:2,crc16;0x00000000 – 0x00010000 concentrator_RE013_M0+.out.temp concentrator_RE013_M0+.out. Пробовала просто fill, та же ошибка. Гуглила, не помогло((( Что я делаю не так?
  8. Спасибо за комментарий. Только сегодня увидела, так как забыла что несмотря на соответствующую галку оповещения об ответах не приходят на почту. Дизассемблер действительно помог. Выяснила, что все же уходит в hard fault из-за попытки записи за границы sram, что было вызвано неправильной установкой значения переменной, которая задавала номер элемента массива для записи.
  9. Цитата(Сергей Борщ @ Aug 22 2014, 13:06) Проблемы со стеком, невыровненным доступом и т.п. приводили бы к попаданию в обработчик исключения HardFault. У вас же, полагаю, происходит переход на ResetHandler. Наиболее вероятной причиной мне кажется срабатывание собаки (Watchdog). Почитайте ее описание для вашего процессора - возможно она включена по умолчанию и ее надо принудительно выключить или перенастроить на нужное вашей программе время. Да, спасибо за совет. Сама думала проверить эту гипотезу, но забыла. Судя по описанию, фьюзам и значениям регистров в debug режиме watchdog выключен. Еще дополнение. Оказывается, курсор прыгает на начало main в отладке, а следующим шагом на строку, следующую за той, после которой перепрыгнул на начало main. И вот в этой второй строке он вообще уходит непонятно куда. Просто дебаггер висит и все. Если нажать break в этот момент, все равно весит. Поставила точку останова в reset_handler, код там останавливается только в самом начале.
  10. Всем привет! Пишу в Atmel Studio (6.2.1153) проект для samd20. Вообще это мой первый опыт работы с 32 разрядными Мк, до этого были только 8-разрядные и не в atmel studio. Использую ASF (3.19) код писался постепенно (точнее переписывался с кода для xmega под iar). На последнем этапе на определенной строчке при отладке перескакивает на начало main. По непонятным причинам. Если строку закоментировать, перескакивает на предыдущей. Если запускать без отладки, то просто код перестает выполнятся после определенного момента. Ума не приложу, как с этим разбираться? Это глюк студии или моего кода? Как понять? Пробовала увеличивать размер стека, размер rstack - все равно вылетает. Игралась со степенью оптимизации - тоже не помогает. Куда копать, подскажите.
  11. Помогите разобраться с ошибкой

    Цитата(lexa12 @ Sep 28 2013, 14:56) Еще вопрос появился по компиляции этого примера - что могут означать эти предупреждения и как от них избавиться? Размер стека определяется наверно в xcl файле. размер стека можно определять двумя способами: в xcl файле или в настройках проекта. Зайдите Project-Options-general options и уберите галочку с пункта configure system using diologs
  12. Проблемы с AT45DB041D

    Цитата(AHTOXA @ Aug 26 2013, 20:45) По-моему, для 256-байтовой страницы вы неправильно формируете адрес. Надо так: старшие 8 бит страницы, младшие 8 бит страницы, смещение на странице. И ещё, проверьте Manufacturer and Device ID. А то мне недавно вполне надёжный поставщик прислал перемаркированные под AT25DF641A чипы совсем другого производителя. Спасибо за подсказку . действительно, проблема была в формировании адреса. Функция была написана для размера страницы 264. А когда я перешла на 256, забыла переписать.
  13. Проблемы с AT45DB041D

    Картинка с осциллографа: [attachment=79025:F0014TEK.JPG] Желтым - два последних считываемых байта на линии MISO на границе страниц. Должно быть 0x88 и 0x11. Как видно из картинки там 0x88 и 0xFF. Голубым показан тактовый сигнал.
  14. Проблемы с AT45DB041D

    Цитата(kovigor @ Aug 26 2013, 11:41) Вы указываете функции считать 9 байт ? А сколько она реально читает ? Смотрели осциллографом ? А если указать, что нужно считать больше ? Например, разумно предположить, что функции удобно читать данные страницами, а никак не по 9 байт. Попробуйте прочитать две или три страницы, выделив соотв. буфер. Тоже так будет ? Осциллографом не смотрела. Это не так просто, потому что плата плотно скомпонована, но попробую. Как это функции удобно?! Она должна работать, как написано в datasheet. Там никаких ограничений на количество байт нет. Если читать две страницы подряд, то все равно первая страница читается правильно, а вторая - 0xff. Цитата(kovigor @ Aug 26 2013, 11:41) А CS вы для чего снимаете ? В даташите четко написано: Может, у вас из-за этого адрес внутри ИС сбивается ... Я снимаю CS, когда заканчиваю считывать нужное мне количество байт. Не вижу противоречия с ds
  15. Проблемы с AT45DB041D

    Цитата(kovigor @ Aug 26 2013, 11:11) Буфер, в который вы читаете данные, не переполняется ? Если увеличить его, допустим, вдвое, что произойдет ? И посмотрите, как объявлены счетчики и проч. Возможно, вы используете 8-разрядный тип там, где нужно использовать 32-разрядный. Все должно работать, т.к. в даташите написано: Буфер, в который читаю, не переполняется. На данный момент он 9 байт, я 9 байт и считываю. Даже, если увеличить буфер в два раза, тоже самое. Т.е. пока считывание идет с одной страницы все ок, а когда переходит на другую - 0xff. Ну, 32-разрядные типы не нужны для моей задачи. Для номера страницы, смещения в байтах и количества считываемых байт использую 16-разрядные типы. При этом номер страницы 280, смещение 255 ( например) и количество байт 9, т.е. нет поводов для переполнения.