Это перебор. Если у Вас контроллер FX2, то память программ и данных у него 8К и в третьем файле должен быть повтор содержимого первого.

Дизассемблер на этом этапе не нужен. Вам нужно изучить раздел "3.4 EEPROM Boot-load Data Formats" и особенно подраздел "3.4.3 Serial EEPROM Present, First Byte is 0xC2" из EZ-USB® Technical Reference Manual (EZ-USB_TRM.pdf). Дальше, Вам нужно будет найти в объединенном файле первое появление последовательности байтов "0x80, 0x01, 0xe6, 0x00,0x00". В этом месте (предположительно) заканчиваются данные загрузки. Проверьте, что формат файла, до места завершающей последовательности соответствует формату, описанному в подразделе "3.4.3 Serial EEPROM Present, First Byte is 0xC2".

Кипарисы с буковкой "A" имеют 16Кбайт памяти команд/данных. 8КБайтных уже не производят вроде.

Сегодня хотел попробовать загрузить обратно данные, которые скачал из EEPROM. Но теперь уже сомневаюсь в соответствии скачанного с реальным. Хотя ведь возможно такое, что чип по мере надобности подгружает себе программу из EEPROM в память, если это реализовано программно? В дэйташите не нашел, что объем внешней EEPROM чем-то ограничен. Скорее всего, он ограничен только максимальным размером адреса в чипе. А он обычно 2^8n, то есть не 16КБ.

И программу и данные FX2 грузит при старте одним махом. Но объем EEPROM может быть и 64Кбайта (или может быть несколько микросхем EEPROM) - устройство может хранить в верхней части (либо других) EEPROM дополнительные данные (калибровочные таблицы и т.п.). И доступ к этим данным возможен уже во время работы.

Все сходится. Файл 17КБ. В начале - 0xC2. В конце - 0x80 0x01 0xE6 0x00 0x00. Дизассемблировал программку с помощью IDA Pro (сказал ему, что это Intel 8051). Зацепился нормально, выделил процедурки. Но найти, где эндпоинты конфигурируются, пока не получилось. Сижу, пыхчу.

Значит, таки не CY7C68013 (FX2), а CY7C68013a (FX2LP).


То есть, в таблице дескрипторов описание эндпоинта EP1OUT выглядит так:

High-Speed Bulk Out Endpoint Descriptor
db 07H ; Descriptor length
db 05H ; Descriptor type: Endpoint
db 01H ; Endpoint number, OUT direction
db 02H ; Endpoint type: Bulk
db 00H ; Maximun packet size (LSB)
db 02H ; Max packect size (MSB)
db 00H ; Polling interval

А мы хотим получить такой эндпоинт EP1OUT:

High-Speed Interrupt Out Endpoint Descriptor
db 07H ; Descriptor length
db 05H ; Descriptor type: Endpoint
db 01H ; Endpoint number, OUT direction
db 03H ; Endpoint type: Interrupt
db 40H ; Maximun packet size (LSB)
db 00H ; Max packect size (MSB)
db 02H ; Polling interval = (2^(bInterval-1))*125us = 250us

То есть, нужно в файле *.iic найти следующую последовательность байтов:
07 05 01 02 00 02 00

И заменить ее на такую:
07 05 01 03 40 00 02

Затем нужно научить Вашу программу загружать содержимое отредактированного файла *.iic в память FX2LP. Для C# библиотека CyUsb.dll имеет метод LoadRAM() в классе CyFX2Device (см. "Programmers Reference - C# Library" (файл CyUSB.NET.chm)). Для С++ эту функцию Вам придется писать самому.

Если firmware для FX2LP содержит переподключение к шине USB, то смену типа EP1OUT с Bulk на Interrupt Вы сможете увидеть, например с помощью CyConsole, сразу после загрузки firmware в FX2LP и переподключения FX2LP к шине USB. Если firmware для FX2LP не содержит переподключение к шине USB, то потребуются дополнительные действия.


А все таки, Вы проверили, что структура считанного файла соответствует описанной в подразделе "3.4.3 Serial EEPROM Present, First Byte is 0xC2" EZ-USB® Technical Reference Manual ? То есть, перемещаясь по заголовкам каждой записи благополучно дошли до завершающей (0x80 0x01 0xE6 0x00 0x00) ???

Проверил. Не соответствует. Самый первый байт - 0xС2. Потом идут судя по всему какие-то данные, совсем не то, что написано в мануале. Начиная с адреса примерно 0x2200 идет то, что должно быть с 0x01 (VID,PID...). Чуть подальше, с 0x2290 идет такая последовательность байт:

То есть что-то типа двух разных конфигураций эндпоинтов. Менять только самую первую? Это не повлияет на работу алгоритма считывания данных с прибора?
Завершающая последовательность встречается только один раз, в конце файла.

Самое забавное - то, что я считал всякие данные с адресов 0x4000 - 0x43FF, хотя в мануале написано:

Считываю 0xE000 - 0xEFFF, там совсем пусто.
Чудеса!!!

Так ведь я ж не стал сначала проверять. Я сразу давай загружать прошивку обратно, чтобы проверить возможность совершения этого действия. И вот парадокс - работает! Причем при изменении чего-нибудь, работать перестает. То есть оно реально загружает то, что я ему подсовываю.


Как Вы определили? У меня TRM на них один и тот же, и про EEPROM там для них одинаково написано.

Сообщение отредактировал niktagor - Sep 20 2010, 18:35

Похоже, что используется внешняя память (программы или данных). Тогда в начале файла *.iic помещается загрузчик, цель которого, преодолеть ограничения загрузки программы или данных только во внутреннюю память контроллера (см. .hex working, .iic not working). В этом случае контроллер может быть и FX2 (CY7C68013), хотя файл *.iic имеет объем больше 8К. То есть, нужно уточнить, какой контроллер используется (Distinction between FX2 and FX2LP by firmware).


Да, два набора дескрипторов для режимов High Speed и Full Speed.
Менять только строку "07 05 01 02 00 02 00" на строку "07 05 01 03 40 00 02". В режиме Full Speed не будет обеспечена нужная Вам скорость обмена. Поэтому для дескрипторов режима Full Speed и не нужны изменения.
Не повлияет.


То есть, меняете строку строку "07 05 01 02 00 02 00" на строку "07 05 01 03 40 00 02" и перестает работать?
Я так понял, что Вы используете USB Control Center для загрузки модифицированного файла *.iic во внутреннюю память FX2/FX2LP. Это опасно. Рука дрогнет и перепрограммируете первые 256 байт EEPROM.


С этой страницы можно скачать EZ-USB® Technical Reference Manual для FX2. В FX2 8K внутренней памяти программ и данных, в FX2LP - 16K. Я полагал, что firmware использует только внутреннюю память контроллера FX2/FX2LP. Поэтому, когда узнал, что файл *.iic занимает 17К, то посчитал, что 17К просто не поместятся в FX2. Serg_Sm совершенно справедливо указал, что на самом деле, объем EEPROM может и превышать объем внутренней памяти контроллера.

Изготовитель предоставляет программатор с одной кнопочкой "зашить", и прошивки раньше тоже были доступны. Скачивать он не умеет. Новую прошивку, которая у меня, не дают.
Строку поменял, все нормально переконфигурировалось. Определяется как interrupt. Массив запросов с CYUSB_OUT он не хочет воспринимать. То есть сколько бы я ему их не посылал, после срабатывания "CYUSB_IN", он информацию перестает выдавать. Скорее всего, такой код. Зато с ситуации 2.1мс+- 0.1мс все изменилось на очень стабильные 2мс +- 0.001мс. И это очень радует. У родной программы было хуже(2.5мс +- 0.5мс и иногда несколько отсчетов выпадало вообще), так что работа не впустую проделана.
Не радует вот что. У датчика время измерения можно менять. 1мс - это я писал самое минимальное, т.к. только в этом режиме будем работать с прибором.
Так вот,со старой конфигурацией время цикла было примерно равно времени измерения + 1мс. А теперь оно равно t измерения для t>2мс. А при t<2мс оно все равно равно 2мс.
То есть получается, что прибор умеет параллельно передавать данные и делать измерение, но это только для t>2мс. А в моем случае, при t=1мс, он намеренно ждет. Такой я могу сделать вывод.

И скорее всего, выход один - копать ассемблерный код...

Сообщение отредактировал niktagor - Sep 21 2010, 17:56

Еще рано горевать.
Во-первых, я промахнулся. Мы хотели обеспечить для EP1OUT: Type="INTERRUPT" и MaxPktSize="1". А сделали:Type="INTERRUPT" и MaxPktSize="64". Так что, если массив запросов с CYUSB_OUT у Вас меньше 64, то Вы и получите в ответ один формуляр CYUSB_IN. Чтобы сделать MaxPktSize="1", нужно в измененном файле *.iic заменить последовательность байт "07 05 01 03 40 00 02" на "07 05 01 03 01 00 02".
Во-вторых, пожалуйста, опишите формат байта (назначение битов), который составляет запрос CYUSB_OUT.
В третьих, опишите алгоритм выдачи массива запросов CYUSB_OUT и прием массива ответов CYUSB_IN. Насколько он отличается от такого алгоритма:
1) BeginDataXfer() c "CYUSB_IN" на прием массива размером N*4.5 Кбайт, N=1000
2) BeginDataXfer() c "CYUSB_OUT" на выдачу массива N байт, N=1000
3) WaitForXfer() и FinishDataXfer() для "CYUSB_OUT"
4) WaitForXfer() и FinishDataXfer() для "CYUSB_IN"

Еще вопрос:

Вот этот последний sync packet тоже содержит 512 байт или меньше? Если меньше 512 байт, то тогда понятно почему Вы получаете один формуляр CYUSB_IN в ответ на массив запросов с CYUSB_OUT.

Почему? Мне не понятно. Он один байт всего содержит. И я посылаю массив запросов на 4097 байт.

Там нет назначений битов. Просто байт запроса данных. Все конфигурирование типа установки скорости датчика происходит заранее, с помощью других команд. Размеры некоторых больше одного байта. Можно ли в этом случае делать MaxPktSize=1?
Я правильно понимаю, что в устройстве буфер 64 байта и он его весь забивает нулями, когда я посылаю команду с MaxPktSize = 64, а мы пытаемся поместить в него несколько команд?

Сейчас с таким работает:

0)BeginDataXfer() c "CYUSB_IN" на прием 4097 байт
while(i<1000)
{
1) BeginDataXfer() c "CYUSB_IN" на прием 4097 байт
2) XferData() для "CYUSB_OUT"
3) WaitForXfer() и FinishDataXfer() для "CYUSB_IN"
i++
}
5)WaitForXfer() и FinishDataXfer() для "CYUSB_IN"

Причем WaitForXfer вызывается для того запроса, который был послан раньше. Массив запросов ни в ту ни в другую сторону он не хочет воспринимать. XferData() выполняется совсем быстро (5мкс), поэтому делаю синхронно.

Universal Serial Bus Revision 2.0 specification раздел "5.8.3 Bulk Transfer Packet Size Constraints".


Нет, MaxPktSize должен быть не меньше числа байт для самой длинной команды.


Не понял предложения.

В целом выводы такие - правильные советы были даны Serg_Sm:

Здравствуйте Уважаемые форумчане.
Прочитал внимательно ветку и понял, что среди участников обсуждения большие специалисты по CY7C68013A.
Есть следующая проблема.
Устройство на указанном контроллере загружает прошивку из файла .sys. Прошивка загружается в RAM и по сигнатурам C0 ... 8001E60000 в файле не находится,
т.к. не загружается в EEPROM. Как можно разыскать эту прошивку в файле .sys и преобразовать её в bix или hex для загрузки в контроллер вручную или через скрипт?
Или, возможно, после загрузки её можно скачать из RAM?
Требуется этот ход в связи с устаревшим драйвером .sys в котором кроме прошивки, я так понимаю, ничего полезного нет, т.к. усройство после загрузки прошивки
переподключается с другими VID PID и управляется стандартным драйвером CyUSB.sys.

Извиняюсь, если обратился не в ту ветку форума. Если решение тривиально - ткните носом. Большого опыта работы с CY7C68013A нет.

Вы уверены, что прошивка грузится именно из .sys, а не из флешки подключенной к CY7C68013A?
Давно с ней имел дело, но насколько помню, прошивка ищется по сигнатуре в начале памяти флешки,
сидящей на I2C.
Если да - решение на вскидку: взять USBTrace (или другой сниффер) и захватить процесс загрузки.
Если там имеется загрузка FW, то обнаружить начало и конец думаю - не составит труда (скорей всего
прошивка будет идти большими блоками одинакового размера). Потом можно поискать содержимое
этих блоков в файлах на диске.
Только (насколько мне помнится) при загрузке "на лету" из драйвера, прошивка вроде грузилась
не из .sys-файла, а именно из отдельного файла с прошивкой (лежащего или рядом или где-то).

Прошивка точно грузится из файла AD9957LD.sys
В 15 версии cy3681_ez_usb_fx2_development_kit_15 есть даже исходники для компиляции драйвера с прошивкой
и программа для конвертации прошивки в C код для сборки с драйвером. Прошивка в файле записывается блоками
по 16 байт с указанием перед каждым блоком 1 байт - от 0 до 16 - кол-во ненулевых байт прошивки в блоке, далее
двухбайтный адрес - я так думаю, далее 1 байт - 00. Сравнивая пример скомпилированного из исходников драйвера
ezloader.sys с прилагаемым файлом прошивки и ezloader.c, как мне кажется я нашёл нужные блоки прошивки в AD9957LD.sys,
но проблема в том, что в этих блоках нет VID PID, которые прописываются после Ренумерации. Нужные VID PID в AD9957LD.sys
присутсвуют только в одном месте, но далеко от тех блоков, что я считаю прошивкой. Как и где обычно прописываются VID PID
при загрузке прошивки с хоста? Кроме того прошивки в EEPROM точно нет, т.к. единственная EEPROM на плате - 16 байт, в которой
зашита стандартная комбинация C0 VID PID DID - проверено.