[Konst_777 0]

...Всего 17КБ вышло...

Это перебор. Если у Вас контроллер 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".

[Serg_Sm 0]

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

[niktagor 0]

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

[Serg_Sm 0]

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

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

[niktagor 0]

Дизассемблер на этом этапе не нужен. Вам нужно изучить раздел "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".

 

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

 

[Konst_777 0]

...Имеется готовое устройство от буржуйских разработчиков, построенное на базе CY7C68013...

Все сходится. Файл 17КБ. В начале - 0xC2. В конце - 0x80 0x01 0xE6 0x00 0x00...

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

 

...

       <ENDPOINT>
                         Type="BULK"
                         Direction="OUT"
                         Address="01h"
                         Attributes="02h"
                         MaxPktSize="512"
                         DescriptorType="5"
                         DescriptorLength="7"
                         Interval="0"
             </ENDPOINT>

...

То есть, в таблице дескрипторов описание эндпоинта 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, то потребуются дополнительные действия.

 

Все сходится. Файл 17КБ. В начале - 0xC2. В конце - 0x80 0x01 0xE6 0x00 0x00...

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

[niktagor 0]

А все таки, Вы проверили, что структура считанного файла соответствует описанной в подразделе "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 идет такая последовательность байт:

07 05 01 02 00 02 00
07 05 82 02 00 02 00
07 05 86 02 00 02 00
07 05 81 02 00 02 00 
09 02 2E 00 01 01 00 80 32 
09 04 00 00 04 FF 00 00 00 
07 05 01 02 40 00 00
07 05 82 02 40 00 00
07 05 86 02 40 00 00
07 05 81 02 40 00 00

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

Завершающая последовательность встречается только один раз, в конце файла.

 

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

Note Serial EEPROM data can be loaded only into these

three on-chip RAM spaces:

■ Program/Data RAM at 0x0000-0x3FFF

■ Data RAM at 0xE000-0xE1FF

■ The CPUCS register (at 0xE600 (only bit 0, 8051RES, is

EEPROM loadable)

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

Чудеса!!!

 

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

 

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

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

Изменено 20 сентября, 2010 пользователем niktagor

[Konst_777 0]

Проверил. Не соответствует. Самый первый байт - 0xС2. Потом идут судя по всему какие-то данные, совсем не то, что написано в мануале.

...

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

Похоже, что используется внешняя память (программы или данных). Тогда в начале файла *.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.

 

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

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

[niktagor 0]

То есть, меняете строку строку "07 05 01 02 00 02 00" на строку "07 05 01 03 40 00 02" и перестает работать?

Я так понял, что Вы используете USB Control Center для загрузки модифицированного файла *.iic во внутреннюю память FX2/FX2LP. Это опасно. Рука дрогнет и перепрограммируете первые 256 байт 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мс, он намеренно ждет. Такой я могу сделать вывод.

 

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

Изменено 21 сентября, 2010 пользователем niktagor

[Konst_777 0]

...

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

Еще рано горевать.

Во-первых, я промахнулся. Мы хотели обеспечить для 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"

 

Еще вопрос:

Устройство сделано так, что я отправляю туда один запрос размером 1 байт. Оно в ответ выплевывает 8 транзакций по 512 байт и одну с sync packet'ом...

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

[niktagor 0]

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

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

Мы хотели обеспечить для EP1OUT: Type="INTERRUPT" и MaxPktSize="1".

...

Во-вторых, пожалуйста, опишите формат байта (назначение битов), который составляет запрос CYUSB_OUT.

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

Я правильно понимаю, что в устройстве буфер 64 байта и он его весь забивает нулями, когда я посылаю команду с MaxPktSize = 64, а мы пытаемся поместить в него несколько команд?

В третьих, опишите алгоритм выдачи массива запросов 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"

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

 

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мкс), поэтому делаю синхронно.

 

[Konst_777 0]

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

...

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

 

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

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

 

Я правильно понимаю, что в устройстве буфер 64 байта и он его весь забивает нулями, когда я посылаю команду с MaxPktSize = 64, а мы пытаемся поместить в него несколько команд?

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

 

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

... Единственная проблема, если после каждого блока нужно слать ответ-подтверждение. В таком случае нормальной скорости не добьешься никак...

Значит получение 4К данных по запросу - это хреново. Чтобы достичь приличной скорости по хорошему нужно выносить всю обработку в драйвер. А так попробуй поднять приоритет процесса до реал-тайм и кидать сразу несколько запросов (точное число проверяется экспериментально) в 1 байт асинхронно приему...

[MSM 0]

Здравствуйте Уважаемые форумчане.

Прочитал внимательно ветку и понял, что среди участников обсуждения большие специалисты по CY7C68013A.

Есть следующая проблема.

Устройство на указанном контроллере загружает прошивку из файла .sys. Прошивка загружается в RAM и по сигнатурам C0 ... 8001E60000 в файле не находится,

т.к. не загружается в EEPROM. Как можно разыскать эту прошивку в файле .sys и преобразовать её в bix или hex для загрузки в контроллер вручную или через скрипт?

Или, возможно, после загрузки её можно скачать из RAM?

Требуется этот ход в связи с устаревшим драйвером .sys в котором кроме прошивки, я так понимаю, ничего полезного нет, т.к. усройство после загрузки прошивки

переподключается с другими VID PID и управляется стандартным драйвером CyUSB.sys.

 

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

 

[jcxz 242]

Вы уверены, что прошивка грузится именно из .sys, а не из флешки подключенной к CY7C68013A?

Давно с ней имел дело, но насколько помню, прошивка ищется по сигнатуре в начале памяти флешки,

сидящей на I2C.

Если да - решение на вскидку: взять USBTrace (или другой сниффер) и захватить процесс загрузки.

Если там имеется загрузка FW, то обнаружить начало и конец думаю - не составит труда (скорей всего

прошивка будет идти большими блоками одинакового размера). Потом можно поискать содержимое

этих блоков в файлах на диске.

Только (насколько мне помнится) при загрузке "на лету" из драйвера, прошивка вроде грузилась

не из .sys-файла, а именно из отдельного файла с прошивкой (лежащего или рядом или где-то).

[MSM 0]

Прошивка точно грузится из файла 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 - проверено.