Raven

Готовое на ум не приходит. Можно использовать в качестве базы (хотя бы для прототипа) такое вот решение: RP2040-ETH (RP2040 + CH9020) Функционал USB-Blaster хорошо известен (есть исходники на Verilog для CPLD имплементации, исходники для микроконтроллерного варианта тоже попадались) - его можно запилить в RP2040.

Надо начать с проверки драйверов. Какие подробности в части драйверов показывает логическое устройство GWU2X (оно видно у вас в правом окне в списке устройств)? И что там за неизвестное устройство до сих пор осталось?

Спасибо за инфу. Для просто интересующегося физ. лица это пока дорого, конечно. Ладно, к нам в контору должен авторский экземпляр придти - буду его смотреть.

А какие-то подробности насчет их доступности есть? Когда, где, как, почем для физ. лица?

Прошу прощения за ламерский вопрос. Если есть полный работоспособный дамп NAND, то что мешает прошивать его в слетевшую NAND?

1. Все крутится вокруг объемов 2GB .. 128GB (характерных для SLC), даже для MLC/TLC, так что при каких условиях они намеряли 10 лет data retention - очень большой вопрос - очень даже возможно, что это было для неполной емкости в режиме pSLC(pseudoSLC). 2. Везде обозначено ухудшение data retention time в процессе службы (1 год к концу срока). Так что никаких чудес нет - здесь работают те же законы физики. 3. Все карты - непростые: Industrial microSDHC / SDXC Memory Card S-50u High reliability series Extended and Industrial Temperature Grade Так что и технология производства и цена у них, скорее всего, несколько отличается от карточек на 1.5 ТБ, которые упоминались.

А если прошивать после сушки?

Для SLC FLASH Data retention time = 10 years @ 25 gradC - это выглядит нормально. Упоминаемые месяцы-1-2года при 25-35 градС - это для MLC/TLC, на которых сделаны терабайтные SSD. Нельзя их слишком надолго без питания оставлять, да еще на солнце или около батареи отопления 🙂 Вы указанную выше статью на Хабре читали?

Собственно, именно это уже делали - 4 строка в поиске: Реализация CORDIC-алгоритма

Вообще-то контроллер карты должен следить за этим. Не экспериментировали - восстанавливается ли скорость, если подержать карту включенной (с подачей питания) 1-2-4-8 суток?

1. Там же на странице Ali, в самом низу, есть схема данной платы расширения. 2. В этой теме раньше были ссылки на ресурсы (Github) с материалами по EBAZ4205. 3. Вот отличный собирательный материал (там в конце еще и все ссылки на другие ресурсы есть): FPGA_Systems.ru : статья "ZYNQ HW: EBAZ4205" А вот еще одна плата расширения: EBAZ4205 adapter board

В семействе плат-компаньонов для EBAZ4205 - пополнение: EBAZ4205 and new companion board on Aliexpress

Значит, могли остаться драйвера от обеих версий квартуса -> возможен конфликт, о котором писал StewartLittle. Посмотрите в Диспетчере Устройств свойства вашего Altera USB-Blaster, а именно вкладку Драйвер. Соответствует ли драйвер вашему квартусу? Также посмотрите свойства службы Altera JTAG Server. Из какого файла запускалась? Той ли версии квартуса? Соответствует ли драйверу из Диспетчера Устройств (см. выше)?

А вы посмотрели получившийся после оптимизации ассемлерный код этого цикла? Это не помогло прояснить ситуацию?

А драйвера USB-Blaster из комплекта Quartus'а вы установили?

Если код оптимитзирован, а пошагово пройти все-таки нужно, то нужно переключиться в другое View/отображение кода - в ассемблерное. И будете проходить его без всяких непонятных скачков по коду. Обычно нормальные IDE здесь же показывают куски исходного C кода, соответствующие показанным оттранслированным ассемблерным. Так что все хорошо видно и понятно.

https://www.pribor.ru/product/promyshlennaya-mebel/

А все нормально с питаниями на проблемной плате? Далее, возможно, на ней по-другому, неудачно проходит подача питаний (в отличие от удачливой платы), и чип после этого в непонятном состоянии. Но вообще, это плохая практика - не удерживать в ресете чип в процессе подачи питания. Проверьте питания и попробуйте все же правильный ресет. Если на проблемной плате нет супервизора, можно проимитировать поведение ресета вручную.

И сверьтесь с толерантностью к напряжениям питания, а то вы как-то лихо XRS# с 1.8V Pull-up переключили на 3.3V Pull-Up.

Обычно залочивают только специфический функционал TAPC, реализуемый через Private Instructions (and their DRs). А весь public-функционал, в первую очередь Boundary Scan, остается доступным. А на нормальной плате как ресет подключен? И почему вы не попробовали его подключить на выход супервизора питания, чтобы чип все-таки гарантированно удерживался в ресете в процессе устаканивания напряжений питания, и затем стартовал бы из известного состояния?

Да, пока выглядит так, что ни в одно из этих состояний TAP не попадает - если судить по диаграммам процесса энумерации в первом посте. Предлагаю следующее: 1) Сразу исключить теоретически возможное удержание TAP в ресете - проверьте, что на пине reset чипа. 2) Если с п.1 все ОК - посмотреть сигналы непосредственно на ножках TCK и TMS (да и TRST на ножке заодно перепроверить).

Еще проверьте, что с сигналом Reset чипа. Если он по какой-то причине активен, и внутри используется как Power-Up Reset, то он может удерживать JTAG TAPC в состоянии сброса.

Да, Cortex-M3 (не армовод я, прошу извинить). Управление этим битом не поднято куда-нибудь наверх, в видимые пользователю опции отладки?

А что - в ARM Cortex-M1 разве нет опции разрешить прерывания на время шага при отладке? В RISC-V такая есть, наверняка и в ARM'ах имеется.

А зачем вам здесь "кузнец" (т.е. Picoprobe)? 🙂 При наличии J-Link v8 надо использовать последний для коннекта OpenOCD с ядром Cortex M0 (разве что поискать правильный cfg-file, или самому его написать). В интернетах полно инструкций, как настроить конструктор VS-Code + GCC + OpenOCD.