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

SM

Свой
  • Постов

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

  • Посещение

Репутация

0 Обычный

2 Подписчика

Информация о SM

  • Звание
    Гуру
    Гуру
  • День рождения 25.03.1974

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array

Посетители профиля

11 061 просмотр профиля
  1. XC8 2.45

    Так удалось кому нибудь запустить XC8 2.45 в полном виде?
  2. Таймер всегда генерирует TCK, а прерывание от его фронта умеет: "ничего не делать" N раз, если загружен счетчик. Иначе, если есть в большом буфере данное, то достает его оттуда, и согласно битам этого данного, если битом разрешено, то принимает бит с TDO со сдвигом в переменную, затем выдает TMS/TDO из других бит этого данного, и потом, если разрешено четвертым битом, грузит счетчик неактивности из того же буфера. Ну и совсем иначе - прерывание вообще ничего не делает. А основная программа интерпретирует SVF, набирает массив данных для прерывания согласно командам SVF (не одной, а сколько влезет, либо до требующей чтения-проверки), и потом быстро этот массив перекидывает в буфер для прерывания, и интерпретирует дальше. Прерывание заоптимизировано на ассемблере вусмерть, и использует аппаратное переключение контекста для сохранения регистров. Остальное на С. вот как-то так. Лишние такты в RUN-TEST/IDLE ничему не мешают, да и не должны по спецификации жтага.
  3. Для нее, согласно документации, вообще некорректно создавать SVF.
  4. без них тоже шьет. То есть "как на блок-схеме" тоже работает. Прям сейчас попробовал стереть их из свф и прогнать его. То есть, это косяк генерации SVF, ни на что не влияющий. Теперь именно на 100% соответствует документации, за исключением задержек. Про 9С я не знаю, где косяк... У меня нет на ней ничего, проверить не могу. И еще - Noop между 0x3A и 0x11 - тоже ни на что не влияет, без него работает. Это уже видимо унификация с "H" технологией, где этот Noop нужен. А задержки с запасом - так это так и должно быть. У тактовой все таки разброс есть, TCK все таки не на OCXO генерируют.
  5. Так у меня же GW1NSR-4C, там IDCODE виден, она относится GW1N-4 и этот шаг ей нужен. В тексте есть ошибка - "Send the "0x03” instruction of Reprogram" - инструкция "Reprogram" имеет код 0x3C А вот да, "лишнюю пару" инструкций 0x3A и 0x02 после 0x11 я не заметил, действительно, имеется небольшое расхождение. Тут можно их удалить, и поглядеть, сохранится ли работоспособность. Проверю. Как это нет??? Целый скриншот, где 0x15, 0x02, 0x71, и потом толпа SDR с данными, и таких кусков там 2.5 мегабайт
  6. Теперь сравнил ради интереса. 100% соответствие с описанием программирования. Сначала Flash Erase - в полном соответствии с "Figure 6-17 The Embedded Flash Erasing process of T Technology", включая "серые" блоки алгоритма. Только первая пауза не 500 мкс, а целая секунда. Потом программирование - в полном соответствии с "Figure 6-19 Process of Programming Internal Flash View", только перед инструкцией 0x3A в самом конце прошивки добавлена пауза на 999 TCK. 1) Config Erase 2) Flash erase + Reprogram 3. Шьем страницы 4. ЗАкончили, config disable, reprogram, проверили статус.
  7. XC8 2.45

    У кого нибудь есть доступ на сонсиври? Переложите пожалуйста вот эту таблетку на местный фтп http://www.sonsivri.to/forum/index.php?topic=44014.msg205173#msg205173
  8. XC8 2.45

    Хорошо. Не ожидал, что я говорю как-то непонятно... Тогда прямо скажу - привычное лечение не работает на 2.45, но работает на всех до нее. Пишет "nothing to do" там, где должно патчить. Это только у меня такая проблема? Есть ли свежая таблетка?
  9. XC8 2.45

    Чтобы узнать, есть ли преимущества, нужно сначала чтобы он в принципе заработал. По "старой системе" он не запускается (с 2.41 она еще работала).
  10. XC8 2.45

    У кого нибудь XC8 2.45 работает в условиях "параллельного импорта"? У меня что-то не срастается с этой версией.
  11. Нет, не сравнивал. Зачем, если работает? Но могу точно сказать, что частота TCK должна соответствовать той, что задана при генерации SVF, и быть постоянной без пауз, равномерной - иначе всё ломается. При этом паузы между SVF-инструкциями, если они заполнены TCK, не маешают. Скорее всего OpenOCD не дает той частоты, что указана в SVF, или делает паузы в ней. Могу сказать еще то, что SVF плеер от моих SAU510USB тоже всё шьет, если тактовая верная, а она в этом эмуляторе также непрерывная. Ну и конечно, не забываем, что в SVF все данные перевернуты задом наперед - младший бит в конце строки, а передается он первым - вся строка интерпретируется как одно многобитное число. Но в данном конкретном случае все просто, там нет сканов больше 32 бит, поэтому можно считывать число просто как uint32_t
  12. Добавлю в старую тему, на будущее кому-то, может, понадобится. Сделал тоже прошивку через JTAG, благо тому, что микроконтроллер быстрый, не было проблем в том, что бы запустить автомат полностью на 1.3 МГц (формирование TCK с этой частотой таймером, а прием с TDO и формирование TDI/TMS в прерывани). Просто реализовал SVF-плеер. Могу добавить, наверное, полезного - ПЛИС у меня GW1NS[R]-4C, то есть с ARM. Для прошивки оного девайса нужно сначала сформировать SVF-файл, содержащий и конфигурацию ПЛИС, и код для ARM. Для этого в программаторе говина надо сначала зайти в "Tools – Gowin files management", и там объединить конфигурацию ПЛИС .fs и фирмвейр арма .bin. Затем, сделать SVF файл в режиме прошивки "Embedded flash mode" с этим комбинированным .fs файлом. Ну и этот SVF "проиграть". Эта вся функциональность на сегодня доступна только в "бетах" говинного софта - то есть в этих бетах они не только отлаживают GW5, а и делают что-то для старых семейств. Спасибо, как всегда, Stewart Little Что заметил - для GW1NS[R]4, в документации для которого минимальная частота JTAG заявлена 1 МГц. Конвертер SVF файлов не дает дать её ниже 1.3 МГц. Если я работаю на 1 МГц, с файлом, сделанным для 1.3 МГц, то часто (не всегда) получаю в конце в статусе 0x39020 вместо 0x1F020 - некое недокументированное состояние. А на правильных 1.3 МГц проблем нет никаких.
  13. Предыдущая проблема тоже решилась. Надо потанцевать с бубном - поменять via на одиночную, потом обратно на MVO, и все начинает двигаться и без ПКМ-move. Зато нарвался на неразрешимую (вроде) проблему. Я сделал мелкие источники питания через группы повторного использования, как это было описано в видео (physical reuse circuits). С одной стороны все, как бы, получилось. А с другой стороны результат категорически не проходит DRC, все MVO в экземплярах блока DRC объявляет как "Dangling via", а соответствующую цепь - неразведенной. Хотя де факто все там соединено, глядя и на графику, и в гербер. При этом в "родительском" блоке с DRC все ОК. Частично можно полечить, добавив к MVO еще просто VIA. Вот так. После этого MVO остается как "dangling", но при этом соединение с точки зрения DRC появляется. Криво... Не везде можно лишнюю VIA подсунуть... Чем эти чертовы MVO такие "сами по себе", то одно с ними не так, то другое. Если заменить все MVO на via array, сделанный через keyin "pv" и вкладку "array" - все хорошо. Но жутко неудобно. И еще одна проблема с ними. Если такой "physical reuse block" протолкнуть на обратную сторону платы, то часть via отваливаются от плейнов, непонятно по какому принципу без закономерностей. Единственный найденный тут выход - это flatten, чуть подвинуть "отвалившуюся" via и она тот час же подключается к своему плейну. В общем эти "physical reuse block" довольно сырые, глюк на глюке.
  14. Предыдущий вопрос решился. Выделить обе via, потом ПКМ-Move, и потом ПКМ-Rotate 90 или keyin "r". Зато второй вопрос. А что это за фигня "Via cannot be moved", если я его пытаюсь перетащить (не зависит от онлайн-дрц вкд/выкл)? При этом оно же через ПКМ-Move двигается только в путь... Из-за чего такое бывает? При этом не все виа такие, а только некоторые, и не только MVO, а с разными бывает.
  15. Я не сколько спорю... Лишь из соображений того, что, может быть, есть потенциальная возможность намекнуть сименсам об "очевидности", если высшие силы посчитают это возможным 😄
×
×
  • Создать...