Title: TE0300DLL.dll question
Post by: erik on April 16, 2012, 04:44:03 PM
Post by: erik on April 16, 2012, 04:44:03 PM
Dear Sirs,
Me an my colleagues have working with the TE0630 and the TE0300DLL.dll to build a prototype for interaction with a digital image sensor. A custom fx2 core was designed to interface the sensor and stream its data. On the PC side, the application contains a dedicated thread that pools the endpoint 6 register EP6CS and use the GetData function to retrieve available data form Ep6 by means of an ad hoc protocol. By the way, the application is running over the .Net Framework which wraps TE0300DLL.dll.
Our experience has shown that the GetData function is only able to retrieve 512 bytes minimum in one call and to hold internally maximum of 2048 bytes from an internal buffer used inside the TE0300DLL.dll to hold incoming data. The amount sensor's generated data quickly fills this buffer, and then all other incoming packages seem to be discarded/ignored, therefore we experience losses in the transmission.
Is this the normal behavior of the GetData interface?
Thanks in advance
Me an my colleagues have working with the TE0630 and the TE0300DLL.dll to build a prototype for interaction with a digital image sensor. A custom fx2 core was designed to interface the sensor and stream its data. On the PC side, the application contains a dedicated thread that pools the endpoint 6 register EP6CS and use the GetData function to retrieve available data form Ep6 by means of an ad hoc protocol. By the way, the application is running over the .Net Framework which wraps TE0300DLL.dll.
Our experience has shown that the GetData function is only able to retrieve 512 bytes minimum in one call and to hold internally maximum of 2048 bytes from an internal buffer used inside the TE0300DLL.dll to hold incoming data. The amount sensor's generated data quickly fills this buffer, and then all other incoming packages seem to be discarded/ignored, therefore we experience losses in the transmission.
Is this the normal behavior of the GetData interface?
Thanks in advance
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on April 16, 2012, 08:47:16 PM
Post by: Ales Gorkic on April 16, 2012, 08:47:16 PM
Dear Eric,
What you experience is normal.
The driver itself has minimal buffering implemented (probably 2kB as you mention).
First of all: in order to achieve high performance, do not use .net for data buffering. Buld a C dll instead (something like the provided example, but with high priority thread). We used .net for our cameras and were very disappointed about undeterministic behaviour.
Second: you can send smaller packets that 512bytes to PC, but you need to assert PACKET_END pin for one IFCLK cycle after each packet.
Hope this helps.
Best regards,
Ales
What you experience is normal.
The driver itself has minimal buffering implemented (probably 2kB as you mention).
First of all: in order to achieve high performance, do not use .net for data buffering. Buld a C dll instead (something like the provided example, but with high priority thread). We used .net for our cameras and were very disappointed about undeterministic behaviour.
Second: you can send smaller packets that 512bytes to PC, but you need to assert PACKET_END pin for one IFCLK cycle after each packet.
Hope this helps.
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on April 16, 2012, 08:51:35 PM
Post by: Ales Gorkic on April 16, 2012, 08:51:35 PM
And another thing: do not poll EP6CS. Reading status reduces bandwith considerably. Simpy read data from EP6. You get timeout if there is no data, and shorter packet if you requested too large packet and datais not available in the timeout period. Simple and effective.
Best regards,
Ales
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: Hengist on April 17, 2012, 11:36:26 PM
Post by: Hengist on April 17, 2012, 11:36:26 PM
We are currently beta-testing two new libraries:
Coming back to our legacy TE0300DLL.dll, we could successfully
- one based on Cypress CyUSB.dll (managed Microsoft .NET class library)
- one based on Cypress CyAPI.lib (C++ programming interface)
Coming back to our legacy TE0300DLL.dll, we could successfully
- write blocks with arbitrary lengths
- read blocks with length equals to an integer multiple of 512
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 01, 2012, 07:45:45 PM
Post by: gelenkeharald on June 01, 2012, 07:45:45 PM
hi @ all,
I made the same experience with indeterministic datatransfer, but with c++ as well.
I'm generating data every 100µs in FPGA (4 byte packages) and requesting data with a modified read function of TE0300_API_Example.cpp.
With
I wrote some more stuff around this problem in another thread
http://forum.trenz-electronic.de/index.php/topic,213.0.html (http://forum.trenz-electronic.de/index.php/topic,213.0.html)
Maybe you can give me a hint, what to do different? I'm trying to use PACKET_END, maybe it's the problems solution?
best regards GH
I made the same experience with indeterministic datatransfer, but with c++ as well.
I'm generating data every 100µs in FPGA (4 byte packages) and requesting data with a modified read function of TE0300_API_Example.cpp.
With
Code Select
printf("ERROR getdata (Packet: %d) : %d", i, error); I can see the error code and the current packet. But its not deterministic. Sometimes error 995 occurs with packet 80, 59 and so on. Unfortunatly sometimes data transfer is not possible at all and I have to reconnect the device.I wrote some more stuff around this problem in another thread
http://forum.trenz-electronic.de/index.php/topic,213.0.html (http://forum.trenz-electronic.de/index.php/topic,213.0.html)
Maybe you can give me a hint, what to do different? I'm trying to use PACKET_END, maybe it's the problems solution?
best regards GH
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on June 01, 2012, 09:00:36 PM
Post by: Ales Gorkic on June 01, 2012, 09:00:36 PM
Hi GH,
If you want to transfer packets shorter than 512bytes you always need to assert packet end pulse after the packet has been written to th FX2 FIFI.
You will get ERROR code (data received is usually shorter than requested) from the GetData function, but the number of transmitted bytes from GetData will be larger than 0.
Best regards,
Ales
If you want to transfer packets shorter than 512bytes you always need to assert packet end pulse after the packet has been written to th FX2 FIFI.
You will get ERROR code (data received is usually shorter than requested) from the GetData function, but the number of transmitted bytes from GetData will be larger than 0.
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 04, 2012, 10:49:55 AM
Post by: Horsa on June 04, 2012, 10:49:55 AM
With reference to the above announcement, we just released two new libraries on GitHub:
https://github.com/Trenz-Electronic/TE-USB-Suite/
https://github.com/Trenz-Electronic/TE-USB-Suite/
- one based on Cypress CyUSB.dll (managed Microsoft .NET class library)
https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2_CyUSB
https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2_CyUSB_SampleApplication - one based on Cypress CyAPI.lib (C++ programming interface)
https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2_CyAPI
https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2_CyAPI_SampleApplication
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 04, 2012, 01:28:05 PM
Post by: gelenkeharald on June 04, 2012, 01:28:05 PM
I tried to use TE_USB_FX2_SampleApplication.exe but it won't detect the device. Its definitly possible with TE0300_API_Example.exe.
Firmware is: TEFW_2.02.0000.iic
vid: 0547
pid: 1002
--> driver: TE03xx-USB_32-64.old_VID_PID.zip
I tried it also with the new driver (after changing VID and PID of course, but same result) What is wrong?
I'm really interested in sampling data with packagelength smaller than maximum (4 bytes). It's possible to sample data, but I always get bad results (missing data). I'd like to refer again to topic http://forum.trenz-electronic.de/index.php/topic,213.0.html, were I explained my problem more detailed. I'd be so grateful for any help.
best regards GH
Firmware is: TEFW_2.02.0000.iic
vid: 0547
pid: 1002
--> driver: TE03xx-USB_32-64.old_VID_PID.zip
I tried it also with the new driver (after changing VID and PID of course, but same result) What is wrong?
I'm really interested in sampling data with packagelength smaller than maximum (4 bytes). It's possible to sample data, but I always get bad results (missing data). I'd like to refer again to topic http://forum.trenz-electronic.de/index.php/topic,213.0.html, were I explained my problem more detailed. I'd be so grateful for any help.
best regards GH
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on June 04, 2012, 02:18:53 PM
Post by: Ales Gorkic on June 04, 2012, 02:18:53 PM
Hi GH,
Do you see the device in the device manager (to exclude driver problems)?
Best regards,
Ales
Do you see the device in the device manager (to exclude driver problems)?
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 04, 2012, 02:27:25 PM
Post by: gelenkeharald on June 04, 2012, 02:27:25 PM
hi
TE_USB_FX2-drivers.zip with changes vid&pid: yes I can see the device, but not under usb-controllers (see picture). Status: The device is working properly.
TE03xx-USB_32-64.old_VID_PID.zip: yes I can see the device under usb-controllers
best regards
TE_USB_FX2-drivers.zip with changes vid&pid: yes I can see the device, but not under usb-controllers (see picture). Status: The device is working properly.
TE03xx-USB_32-64.old_VID_PID.zip: yes I can see the device under usb-controllers
best regards
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 04, 2012, 03:14:40 PM
Post by: Horsa on June 04, 2012, 03:14:40 PM
Quote from: gelenkeharaldAre you using TEFW_2.02.0000.iic and you get VID/PID = 0547/1002? Then we shall release a new binary firmware file with the current Trenz Electronic PID/VID for USB FX" devices: 0x0BD0/0x0300. The source firmware files in our GitHub repository
Firmware is: TEFW_2.02.0000.iic
vid: 0547
pid: 1002
https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2.firmware
are instead up to date.
Quote from: gelenkeharaldThat is normal. Instead of "%TE-class-name%", the new Trenz Electronic USB device class name should appear.
TE_USB_FX2-drivers.zip with changes vid&pid: yes I can see the device, but not under usb-controllers (see picture). Status: The device is working properly.
Quote from: gelenkeharaldThat is normal.
TE03xx-USB_32-64.old_VID_PID.zip: yes I can see the device under usb-controllers
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 04, 2012, 03:33:13 PM
Post by: gelenkeharald on June 04, 2012, 03:33:13 PM
Quote from: Horsa on June 04, 2012, 03:14:40 PM
Are you using TEFW_2.02.0000.iic and you get VID/PID = 0547/1002?
yes I do get it.
Can you please provide the new files? Because I want to test your new libraries. Hope to solve my datatransfer problems...
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 04, 2012, 04:11:50 PM
Post by: Horsa on June 04, 2012, 04:11:50 PM
Yes, here you are:
- current Trenz Electronic USB FX2 firmware (VID/PID = 0x0BD0/0x0300, version 3.0) working with Trenz Electronic drivers and APIs
https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2.iic - legacy Trenz Electronic USB FX2 firmware (VID/PID = 0x0547/0x1002, version 3.0) working with DEWESOFT driver and API
https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2_DW.iic
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 04, 2012, 04:21:34 PM
Post by: gelenkeharald on June 04, 2012, 04:21:34 PM
Quote from: Horsa on June 04, 2012, 04:11:50 PM
https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2.iic[/li][/list]
sry but this file is wrong, because fx2 provides then the same VID=04B4&PID=8613 as Cypres Generic Device and not VID/PID = 0x0BD0/0x0300
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 04, 2012, 05:14:42 PM
Post by: Oleksandr Kiyenko on June 04, 2012, 05:14:42 PM
I just updated the large EEPROM on one of my modules with https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2.iic and saw VID 0x0BD0 and PID 0x0300.
Please synchronize your local repository or download the file again to be sure that you are using the latest version. The previous version was with DEWEsoft VID/PID).
Regards
Alex
Please synchronize your local repository or download the file again to be sure that you are using the latest version. The previous version was with DEWEsoft VID/PID).
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 10:50:14 AM
Post by: gelenkeharald on June 05, 2012, 10:50:14 AM
this file https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2.iic is 100% providing old VID & PID
I tried it with http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/firmware/TE_USB_FX2-v03.00.iic and this is the right one! driver installation also works (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/drivers/TE_USB_FX2-drivers.zip)
cool one problem solved, but there are some new ones with the APIs, let me summarize
old TE0300_API_Example: works!
TE_USB_FX2_CyUSB_SampleApplication: compiling possible, but detects no devices!
TE_USB_FX2_CyAPI_SampleApplication: win32 compilation failes error in winnt.h and Winbase.h
I want to especially point out that all the files I've downloaded are the newest from github (5.6. 9:50) and my microsoft visual studio was installed yesterday. I unpacked the zip file and opened the projects...
I tried it with http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/firmware/TE_USB_FX2-v03.00.iic and this is the right one! driver installation also works (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/drivers/TE_USB_FX2-drivers.zip)
cool one problem solved, but there are some new ones with the APIs, let me summarize
old TE0300_API_Example: works!
TE_USB_FX2_CyUSB_SampleApplication: compiling possible, but detects no devices!
TE_USB_FX2_CyAPI_SampleApplication: win32 compilation failes error in winnt.h and Winbase.h
I want to especially point out that all the files I've downloaded are the newest from github (5.6. 9:50) and my microsoft visual studio was installed yesterday. I unpacked the zip file and opened the projects...
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 05, 2012, 11:22:20 AM
Post by: Horsa on June 05, 2012, 11:22:20 AM
Quote from: gelenkeharald on June 05, 2012, 10:50:14 AM
this file https://github.com/Trenz-Electronic/TE-USB-Suite/blob/master/TE_USB_FX2.firmware/TE_USB_FX2.iic is 100% providing old VID & PID
I tried it with http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/firmware/TE_USB_FX2-v03.00.iic and this is the right one! driver installation also works (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/drivers/TE_USB_FX2-drivers.zip)
I personally downloaded the second file from GitHub, renamed it as the first one, and uploaded to our download area. They must be the same. As a double check, I just downloaded both files and made a binary compare: they match. Again: "Please synchronize your local repository or download the file again to be sure that you are using the latest version. "
Quote from: gelenkeharald on June 05, 2012, 10:50:14 AMThat is strange, we never experienced this problem before release under multiple combinations of conditions: operating system, host computer, TE USB FX2 module. Can you please document more into details your Device Manager output? Such as VID, PID, device class, ...
old TE0300_API_Example: works!
TE_USB_FX2_CyUSB_SampleApplication: compiling possible, but detects no devices!
Quote from: gelenkeharald on June 05, 2012, 10:50:14 AMThis is a known issue for 32 bit version. We are investigating. Does anyone have a clue? Then please share.
TE_USB_FX2_CyAPI_SampleApplication: win32 compilation failes error in winnt.h and Winbase.h
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 11:47:11 AM
Post by: gelenkeharald on June 05, 2012, 11:47:11 AM
Quote from: Horsa on June 05, 2012, 11:22:20 AM
That is strange, we never experienced this problem before release under multiple combinations of conditions: operating system, host computer, TE USB FX2 module. Can you please document more into details your Device Manager output? Such as VID, PID, device class, ...
I'm giving you as much details as I can:
operating system: windows 7
TE USB FX2 module: TE0300-01BM
hardware-ids: USB\VID_0BD0&PID_0300&REV_0000 and USB\VID_0BD0&PID_0300
device class: Trenz_Electronic_USB (but as I posted before it occurs in device manager like picture)
device class GUID: {80419720-177a-4ed0-97c0-0996a12a1f4f}
driver key: {80419720-177a-4ed0-97c0-0996a12a1f4f}\0002
If you need more, let me know. I'm not sure if the names are right translated because my windows is in german ;-)
I only wanna have datatransfer with small packages through fifos, I didn't expect that this would be exhausting like this...
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 05, 2012, 12:10:06 PM
Post by: Horsa on June 05, 2012, 12:10:06 PM
Quote from: gelenkeharald on June 05, 2012, 11:47:11 AMPlease more info: 32 or 64 bit?
operating system: windows 7
Quote from: gelenkeharald on June 05, 2012, 11:47:11 AMHow did you install the driver? I can remember that you installed "TE_USB_FX2-drivers.zip with changes vid&pid". This might have altered your system.
device class: Trenz_Electronic_USB (but as I posted before it occurs in device manager like picture)
device class GUID: {80419720-177a-4ed0-97c0-0996a12a1f4f}
driver key: {80419720-177a-4ed0-97c0-0996a12a1f4f}\0002
Can you try to uninstall the driver? Then allow online/automatic install ("Search automatically for updated driver software").
Can you please try on
- a fresh system
- an alternate host computer
- a Windows 7 with an alternate number of (32/64) bit?
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 01:26:57 PM
Post by: gelenkeharald on June 05, 2012, 01:26:57 PM
Quote from: Horsa on June 05, 2012, 12:10:06 PM
Please more info: 32 or 64 bit?
32 bit system
Quote from: Horsa on June 05, 2012, 12:10:06 PM
How did you install the driver? I can remember that you installed "TE_USB_FX2-drivers.zip with changes vid&pid". This might have altered your system.
Can you try to uninstall the driver? Then allow online/automatic install ("Search automatically for updated driver software").
Can you please try on
- a fresh system
- an alternate host computer
- a Windows 7 with an alternate number of (32/64) bit?
I deinstalled all the old drivers, then allowed online install, but system couldn't find a driver. Then I searched manually in ../TE_USB_FX2-drivers/MS-Windows-Vista+7 and tried to install. But now even this is not working :-/
this is the error msg (translated from german [see picture] to english):
"in the driver installation file is missing a decent entry"
I'm now driving home and making a system restore, if then the error occurs again, I don't know what to do.
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 02:07:33 PM
Post by: gelenkeharald on June 05, 2012, 02:07:33 PM
update: system restore done (at this timepoint, one monath ago, there was no driver for VID_0BD0&PID_0300 on the system)
online driver search: couldn't find driver
local driver search in ..\TE_USB_FX2-drivers\MS-Windows-Vista+7 or \TE_USB_FX2-drivers: couldn't find driver
I'm waiting with manually installing *.inf for more instructions of you, to not alter system
update: the new driver doesn't work on a fresh system, too!
online driver search: couldn't find driver
local driver search in ..\TE_USB_FX2-drivers\MS-Windows-Vista+7 or \TE_USB_FX2-drivers: couldn't find driver
I'm waiting with manually installing *.inf for more instructions of you, to not alter system
update: the new driver doesn't work on a fresh system, too!
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 04:35:44 PM
Post by: gelenkeharald on June 05, 2012, 04:35:44 PM
Quote from: Hengist on April 17, 2012, 11:36:26 PM
Coming back to our legacy TE0300DLL.dll, we could successfully(obviously excluding the assertion of PACKET_END pin).
- write blocks with arbitrary lengths
- read blocks with length equals to an integer multiple of 512
have you ever tried package generation in fpga with fixed time interval? e.g. every 100µs? and read them successfully?
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on June 05, 2012, 05:49:49 PM
Post by: Ales Gorkic on June 05, 2012, 05:49:49 PM
Hi GH,
We still use the old driver and we do send packets of 5 words (20bytes) at arbitrary time interval. And it works if the PACKET_END is asserted.
Best regards,
Ales
We still use the old driver and we do send packets of 5 words (20bytes) at arbitrary time interval. And it works if the PACKET_END is asserted.
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 05, 2012, 06:40:07 PM
Post by: gelenkeharald on June 05, 2012, 06:40:07 PM
Hi Ales,
ok this is very interesting, is that maybe possible that you can send me your project, please? This would be so helpful.
I'd like to compare yours and mine and hope to find out what is wrong in my project (vhdl and c++). If you want I can inform you about my progress.
best regards,
GH
ok this is very interesting, is that maybe possible that you can send me your project, please? This would be so helpful.
I'd like to compare yours and mine and hope to find out what is wrong in my project (vhdl and c++). If you want I can inform you about my progress.
best regards,
GH
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 05, 2012, 11:49:52 PM
Post by: Horsa on June 05, 2012, 11:49:52 PM
Quote from: gelenkeharald on June 05, 2012, 01:26:57 PM
I deinstalled all the old drivers, then allowed online install, but system couldn't find a driver.
to change Device Installation Settings do as follows:
- Click Control Panel
- Click System
- Click Advanced System Settings
- Click Hardware Tab
- Click Device Installation Settings
http://answers.microsoft.com/en-us/windows/forum/windows_7-hardware/windows-7-device-driver-upgrade-search/1d675250-3b33-42d3-8416-a9e5f3674375
I wonder why Microsoft overwhelm us with any kind of messages but "If you cannot download driver automatically, check whether you granted permission first."
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 06, 2012, 12:12:07 AM
Post by: Horsa on June 06, 2012, 12:12:07 AM
Quote from: gelenkeharald on June 05, 2012, 02:07:33 PM
I'm waiting with manually installing *.inf for more instructions of you, to not alter system
update: the new driver doesn't work on a fresh system, too!
We just performed even more tests on a TE0300-01 under the following conditions:
- TEFW_2.02.0000.iic, TE_USB_FX2-v03.00.iic
- WIndows 7 (32 bit) fresh install, Windows 7 (64 bit) fresh install
- automatic installation, manual installation
Key questions:
A) what .NET version is installed on your system(s)?
B) when uninstalling the driver(s), do you select "Delete the driver software for this device."?
C) As an extreme redundancy check, with what VID/PID does the module enumerate before and after driver installation?
D) Could you tell us your side DIP-switch settings?
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 06, 2012, 10:02:31 AM
Post by: gelenkeharald on June 06, 2012, 10:02:31 AM
Quote from: Horsa on June 06, 2012, 12:12:07 AM
We just performed even more tests on a TE0300-01 under the following conditions:Everything (driver installation and test application) flew simply as intended.
- TEFW_2.02.0000.iic, TE_USB_FX2-v03.00.iic
- WIndows 7 (32 bit) fresh install, Windows 7 (64 bit) fresh install
- automatic installation, manual installation
Key questions:
A) what .NET version is installed on your system(s)?
B) when uninstalling the driver(s), do you select "Delete the driver software for this device."?
C) As an extreme redundancy check, with what VID/PID does the module enumerate before and after driver installation?
D) Could you tell us your side DIP-switch settings?
A) .NET 4
B) yes of course
C) its the same VID/PID
D) all DIP-switches are at the left position (if you look at the module and usb-miniport ist left)
As I asked in a post before, is there a possibility that you could forward your project with small package length and arbitary time intervall? Please I really need datatransfer for my diplomathesis project!
Thank you
best regards
GH
Title: Re: TE0300DLL.dll question
Post by: Ales Gorkic on June 06, 2012, 12:47:48 PM
Post by: Ales Gorkic on June 06, 2012, 12:47:48 PM
Hi GH,
The project with arbitrary packets is a part of large automotive data acqusition system. I cannot give it away.
It seems to me that you got into serius trouble. I simply cannot understand why do you want to do everyhing in the FPGA from a scratch. You have two possibilities: start with Microblaze reference design or take fx2_core.vhd attach FIFO to it and use it in your ISE design. Otherwise your diploma might take much longer than you can afford.
Best regards,
Ales
The project with arbitrary packets is a part of large automotive data acqusition system. I cannot give it away.
It seems to me that you got into serius trouble. I simply cannot understand why do you want to do everyhing in the FPGA from a scratch. You have two possibilities: start with Microblaze reference design or take fx2_core.vhd attach FIFO to it and use it in your ISE design. Otherwise your diploma might take much longer than you can afford.
Best regards,
Ales
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 06, 2012, 01:02:24 PM
Post by: gelenkeharald on June 06, 2012, 01:02:24 PM
hi ales,
sry as you might noticed my english is not the best, what does scratch in this context mean?
This is what I've done. And here is my problem, no one can help me. Simulation works, but on hardware not satisfactory! Because of datalosses...
best regards,
GH
Quote from: Ales Gorkic on June 06, 2012, 12:47:48 PM
I simply cannot understand why do you want to do everyhing in the FPGA from a scratch.
sry as you might noticed my english is not the best, what does scratch in this context mean?
Quote from: Ales Gorkic on June 06, 2012, 12:47:48 PM
fx2_core.vhd attach FIFO to it and use it in your ISE design
This is what I've done. And here is my problem, no one can help me. Simulation works, but on hardware not satisfactory! Because of datalosses...
best regards,
GH
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 06, 2012, 01:05:47 PM
Post by: Horsa on June 06, 2012, 01:05:47 PM
I just released the documentation of our new APIs for pubic preview here:
http://www.trenz-electronic.de/download/d0/Trenz_Electronic/d1/TE-USB-Suite/d2/documents.html
Please note directions on minimum packet sizes in standard implementations (without asserting PACKET_END).
Fine. Which ones?
S1, S2 and S4 are OK. Please make a couple of trials with S3 switched towards the FPGA (FX2_PON).
http://www.trenz-electronic.de/download/d0/Trenz_Electronic/d1/TE-USB-Suite/d2/documents.html
Please note directions on minimum packet sizes in standard implementations (without asserting PACKET_END).
Quote from: gelenkeharald on June 06, 2012, 10:02:31 AMWhat version exactly? The reference manual requires .NET Framework version ≥ 4.0.30319
A) .NET 4
Quote from: gelenkeharald on June 06, 2012, 10:02:31 AM
C) its the same VID/PID
Fine. Which ones?
Quote from: gelenkeharald on June 06, 2012, 10:02:31 AM
D) all DIP-switches are at the left position (if you look at the module and usb-miniport ist left)
S1, S2 and S4 are OK. Please make a couple of trials with S3 switched towards the FPGA (FX2_PON).
Title: Re: TE0300DLL.dll question
Post by: Thorsten Trenz on June 06, 2012, 01:20:26 PM
Post by: Thorsten Trenz on June 06, 2012, 01:20:26 PM
Hi,
Did you setup your timing constraints correctly, and do you have zero timing errors?
best regards
Thorsten Trenz
Quote from: gelenkeharald on June 06, 2012, 01:02:24 PM
This is what I've done. And here is my problem, no one can help me. Simulation works, but on hardware not satisfactory! Because of datalosses...
Did you setup your timing constraints correctly, and do you have zero timing errors?
best regards
Thorsten Trenz
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 06, 2012, 01:40:24 PM
Post by: gelenkeharald on June 06, 2012, 01:40:24 PM
Quote from: Thorsten Trenz on June 06, 2012, 01:20:26 PM
Hi,
Did you setup your timing constraints correctly, and do you have zero timing errors?
best regards
Thorsten Trenz
Thank you for the hint, Thorsten Trenz.
I used these timing contraints as I found in your latest reference design:
Code Select
# FX2 timing constrains
NET "USB_FD_pin<*>" OFFSET = IN 9 ns BEFORE "USB_IFCLK_pin" RISING;
TIMESPEC TS_B2P = FROM RAMS TO PADS 10 ns;
NET "USB_FLAGB_pin" OFFSET = IN 10 ns BEFORE "USB_IFCLK_pin" RISING;
NET "USB_FLAGD_pin" OFFSET = IN 10 ns BEFORE "USB_IFCLK_pin" RISING;
NET "USB_SLWR_pin" OFFSET = OUT 9 ns AFTER "USB_IFCLK_pin" RISING;
# USB_SLRD_pin drived from flip-flop in OPAD, so there is maximum that you can get from this device
#NET "USB_SLRD_pin" OFFSET = OUT 7.4 ns AFTER "USB_IFCLK_pin" RISING; # If you don't use DCM
NET "USB_SLRD_pin" OFFSET = OUT 5.7 ns AFTER "USB_IFCLK_pin" RISING; # If you use DCM
NET "USB_SLOE_pin" OFFSET = OUT 9 ns AFTER "USB_IFCLK_pin" RISING;
NET "USB_PKTEND_pin" OFFSET = OUT 9 ns AFTER "USB_IFCLK_pin" RISING;
NET "USB_FIFOADR_pin<*>" OFFSET = OUT 9.5 ns AFTER "USB_IFCLK_pin" RISING;
I don't use DCM for USB_IFCLK_pin. I receive one Failing Constraint for USB_SLRD_pin, maybe this is the problem? What do I have to do different?
best regards
GH
update: I'm now using DCM for USB_IFCLK_pin and all contraints now met, but the result on hardware is the same...
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 06, 2012, 02:36:28 PM
Post by: Oleksandr Kiyenko on June 06, 2012, 02:36:28 PM
Hi gelenkeharald,
Small constrain error you got is not critical for this interface.
To help you we should know more details about your project.
1) Which module type you use ?
2) Is reference project working without losses on your module ?
3) Packet size and period ?
4) How you checking data while sending and while receiving ?
Also if you describe your project, sure that we can help you to find right way to implement it.
Regards
Alex
Small constrain error you got is not critical for this interface.
To help you we should know more details about your project.
1) Which module type you use ?
2) Is reference project working without losses on your module ?
3) Packet size and period ?
4) How you checking data while sending and while receiving ?
Also if you describe your project, sure that we can help you to find right way to implement it.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 06, 2012, 03:12:32 PM
Post by: gelenkeharald on June 06, 2012, 03:12:32 PM
hi,
ok let me describe my project again ;-) (old thread http://forum.trenz-electronic.de/index.php/topic,213.0.html (http://forum.trenz-electronic.de/index.php/topic,213.0.html))
I attached a structure, so maybe its easier to understand what I've done. In short there are 3 different types of analog-digital-converter and I want to interface these ADC and send data to PC. The interfaces to the ADCs are working perfect. The whole system is working in simulation in right way, too. But I got some errors with transferring data from FPGA to PC. For that reason I built up an minimum project. This minimum project contains fx2_core, usb_input_observer and package generator. With c++ I can successfully set LED, sample_en or chan_en through usb_input_observer. sample_en initiates package generation for the minimum project. 4 bytes long packages after every 50µs. The packages have a special structure for transferring data from ADC. They contain 5bit sensor id, 2bit data length, 9bit timestamp (simple counter) and 16bit adc_data. For testing I fixed adc_data to striking value. The timestamp counter is counting every 50µs.
So I expect for datatransfer:
TX_PACKET_LEN = 64 and packets=10
1. "0A 01 00 93"
2. "0A 02 00 93"
3. "0A 03 00 93"
4. "0A 04 00 93"
5. "0A 05 00 93"
6. "0A 06 00 93"
7. "0A 07 00 93"
8. "0A 08 00 93"
9. "0A 09 00 93"
10. "0A 0A 00 93"
you can see the counter at 3rd and 4th position!
BUT my problem is now, that I receive e.g.
1. "0A 01 00 93"
2. "0A 02 00 93"
3. "0A 05 00 93"
4. "0A 0A 00 93"
5. "0A 0F 00 93"
6. "0A 14 00 93"
7. "0A 19 00 93"
8. "0A 1E 00 93"
9. "0A 23 00 93"
10. "0A 22 00 93"
So there are some packages lost in outer space;-). Conspicuous is, that the result always differs and is indeterministic.
to your questions:
1) I'm using TE0300-01BM and fx2_core/fx2_engine (from xps_fx2_v1_50_a)
2) yes it works perfekt with reference project
3) minimum project: packet size = 4 bytes, periode = 50µs
4) hope I have answered in project description?!
best regards
GH
ok let me describe my project again ;-) (old thread http://forum.trenz-electronic.de/index.php/topic,213.0.html (http://forum.trenz-electronic.de/index.php/topic,213.0.html))
I attached a structure, so maybe its easier to understand what I've done. In short there are 3 different types of analog-digital-converter and I want to interface these ADC and send data to PC. The interfaces to the ADCs are working perfect. The whole system is working in simulation in right way, too. But I got some errors with transferring data from FPGA to PC. For that reason I built up an minimum project. This minimum project contains fx2_core, usb_input_observer and package generator. With c++ I can successfully set LED, sample_en or chan_en through usb_input_observer. sample_en initiates package generation for the minimum project. 4 bytes long packages after every 50µs. The packages have a special structure for transferring data from ADC. They contain 5bit sensor id, 2bit data length, 9bit timestamp (simple counter) and 16bit adc_data. For testing I fixed adc_data to striking value. The timestamp counter is counting every 50µs.
So I expect for datatransfer:
TX_PACKET_LEN = 64 and packets=10
1. "0A 01 00 93"
2. "0A 02 00 93"
3. "0A 03 00 93"
4. "0A 04 00 93"
5. "0A 05 00 93"
6. "0A 06 00 93"
7. "0A 07 00 93"
8. "0A 08 00 93"
9. "0A 09 00 93"
10. "0A 0A 00 93"
you can see the counter at 3rd and 4th position!
BUT my problem is now, that I receive e.g.
1. "0A 01 00 93"
2. "0A 02 00 93"
3. "0A 05 00 93"
4. "0A 0A 00 93"
5. "0A 0F 00 93"
6. "0A 14 00 93"
7. "0A 19 00 93"
8. "0A 1E 00 93"
9. "0A 23 00 93"
10. "0A 22 00 93"
So there are some packages lost in outer space;-). Conspicuous is, that the result always differs and is indeterministic.
to your questions:
1) I'm using TE0300-01BM and fx2_core/fx2_engine (from xps_fx2_v1_50_a)
2) yes it works perfekt with reference project
3) minimum project: packet size = 4 bytes, periode = 50µs
4) hope I have answered in project description?!
best regards
GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 06, 2012, 04:20:27 PM
Post by: Oleksandr Kiyenko on June 06, 2012, 04:20:27 PM
Hi gelenkeharald,
Pretty clear now :)
First point to check I see it's FIFOADDR control. Can you try to check this pins during work to be sure that you send all packets to right endpoint.
Also as you have missed packets, but not missed bytes there is also can be software issue.
Did you try to use ChipScope to check if all packets are sent right ?
Regards
Alex
Pretty clear now :)
First point to check I see it's FIFOADDR control. Can you try to check this pins during work to be sure that you send all packets to right endpoint.
Also as you have missed packets, but not missed bytes there is also can be software issue.
Did you try to use ChipScope to check if all packets are sent right ?
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 07, 2012, 03:42:52 PM
Post by: gelenkeharald on June 07, 2012, 03:42:52 PM
Hi,
How can I check pins, if they are not routed to an external pin?
Until now I programmed the device always with usb flash. Today I organized a JTAG cable. But I made the experience that I need a licence for using chipscope? I only have the chance to use the webpack, f***. Is there another possibilty to use chipscope for debugging?
regards
GH
ah I used chipscope pro, but there are some chipscope ip cores they are free to use, I asuem? I'm going to try it!
How can I check pins, if they are not routed to an external pin?
Until now I programmed the device always with usb flash. Today I organized a JTAG cable. But I made the experience that I need a licence for using chipscope? I only have the chance to use the webpack, f***. Is there another possibilty to use chipscope for debugging?
regards
GH
ah I used chipscope pro, but there are some chipscope ip cores they are free to use, I asuem? I'm going to try it!
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 07, 2012, 04:08:38 PM
Post by: Oleksandr Kiyenko on June 07, 2012, 04:08:38 PM
Hi gelenkeharald,
If you going to debug your project in hardware, you can try 30 days evaluate license for "Logic Edition" which include ChipScope. (Of course you will need Xilinx cable for using Chipscope.) Or you should write good testbench which cover your project behavior and try to find problem by simulation. As for me simulation is right way because you will use this testbench many times while your project growing.
Regards
Alex
If you going to debug your project in hardware, you can try 30 days evaluate license for "Logic Edition" which include ChipScope. (Of course you will need Xilinx cable for using Chipscope.) Or you should write good testbench which cover your project behavior and try to find problem by simulation. As for me simulation is right way because you will use this testbench many times while your project growing.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 08, 2012, 09:58:16 AM
Post by: gelenkeharald on June 08, 2012, 09:58:16 AM
post deleted
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 08, 2012, 11:00:46 AM
Post by: gelenkeharald on June 08, 2012, 11:00:46 AM
ok I now know my problem:
tx fifo is full after 2 packages as you can see in the attached picture, so this means its a pc side software fault, because the data is not collected fast enough?
how do I have to change the parameters of TE0300_GetData?
now I set:
packets = 20
TX_PACKET_LEN = 64
TIMEOUT_MS = 1000
best regars
GH
tx fifo is full after 2 packages as you can see in the attached picture, so this means its a pc side software fault, because the data is not collected fast enough?
how do I have to change the parameters of TE0300_GetData?
now I set:
packets = 20
TX_PACKET_LEN = 64
TIMEOUT_MS = 1000
best regars
GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 08, 2012, 02:33:25 PM
Post by: Oleksandr Kiyenko on June 08, 2012, 02:33:25 PM
Hi gelenkeharald,
It's not exact software problem, looks like you got FX2 buffers limitation. Let me explain. FX2 have internal FIFOs (buffers) which configured to receive packet and then go to processing. FX2 firmware you using have 2 buffers by 512 bytes for each EP. So when you send 2 packets both buffers will be used and you will get full FIFO flag till one buffer will be send to host. To solve it you can try to use bigger packets (activate PKTEND after N small packets not after each). Or not drive PKTEND at all - in this case buffer will commited to host when it filled to configured limit (can be changed in FX2 firmware). This solution will increase latency but you will get faster transfers.
I just finish new project which use Cypress Virtual COM driver to communicate with TE modules, COM port interface much easier to communicate and write software port. Think that this project will be more suited for your purposes.
Regards
Alex
It's not exact software problem, looks like you got FX2 buffers limitation. Let me explain. FX2 have internal FIFOs (buffers) which configured to receive packet and then go to processing. FX2 firmware you using have 2 buffers by 512 bytes for each EP. So when you send 2 packets both buffers will be used and you will get full FIFO flag till one buffer will be send to host. To solve it you can try to use bigger packets (activate PKTEND after N small packets not after each). Or not drive PKTEND at all - in this case buffer will commited to host when it filled to configured limit (can be changed in FX2 firmware). This solution will increase latency but you will get faster transfers.
I just finish new project which use Cypress Virtual COM driver to communicate with TE modules, COM port interface much easier to communicate and write software port. Think that this project will be more suited for your purposes.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 08, 2012, 03:28:29 PM
Post by: gelenkeharald on June 08, 2012, 03:28:29 PM
hi Alex,
debbuging is so much better with chipscope, why didn't I used it before? ;-)
I remember that you already gave me the hint not to drive pktend. With chipscope I can see this must be the right way, because signals were send right. But in software there are still problems:
I wanna use EP2 so packagelength must be 64bytes (cause by not driving pktend)?!
But I always receive Error: 995
Where can I get this new project and driver, you mentioned?
best regards
GH
debbuging is so much better with chipscope, why didn't I used it before? ;-)
I remember that you already gave me the hint not to drive pktend. With chipscope I can see this must be the right way, because signals were send right. But in software there are still problems:
I wanna use EP2 so packagelength must be 64bytes (cause by not driving pktend)?!
But I always receive Error: 995
Where can I get this new project and driver, you mentioned?
best regards
GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 08, 2012, 03:57:55 PM
Post by: Oleksandr Kiyenko on June 08, 2012, 03:57:55 PM
Hi gelenkeharald,
> debbuging is so much better with chipscope, why didn't I used it before? ;-)
Yes, but it's last fronteer, better to fix problems before it :)
>I remember that you already gave me the hint not to drive pktend. With chipscope I can see this must be the right way, because signals were send right. But in software there are still problems:
PKTEND it's good control, but you should know how it's work.
> I wanna use EP2 so packagelength must be 64bytes (cause by not driving pktend)?!
> But I always receive Error: 995
You can use any packet length less than 512 bytes (size of buffer and also limit for USB 2.0), but you should know that smaller packets = low latency but also low bandwidth usage, but bigger packets = high bandwidth but also high latency. If your project just collect data from ADCs and send it to PC and don't require fast response, so better choose big packet length (something around 500 bytes) and commit this packets by PKTEND signal.
I also know more ways to increase transfer speed but it's require FX2 firmware modifications.
> Where can I get this new project and driver, you mentioned?
It's ready, I just going to write some description and commit it to Github today evening (if I'll have time) or more possible tomorrow. Will write to this topic when done.
Regards
Alex
> debbuging is so much better with chipscope, why didn't I used it before? ;-)
Yes, but it's last fronteer, better to fix problems before it :)
>I remember that you already gave me the hint not to drive pktend. With chipscope I can see this must be the right way, because signals were send right. But in software there are still problems:
PKTEND it's good control, but you should know how it's work.
> I wanna use EP2 so packagelength must be 64bytes (cause by not driving pktend)?!
> But I always receive Error: 995
You can use any packet length less than 512 bytes (size of buffer and also limit for USB 2.0), but you should know that smaller packets = low latency but also low bandwidth usage, but bigger packets = high bandwidth but also high latency. If your project just collect data from ADCs and send it to PC and don't require fast response, so better choose big packet length (something around 500 bytes) and commit this packets by PKTEND signal.
I also know more ways to increase transfer speed but it's require FX2 firmware modifications.
> Where can I get this new project and driver, you mentioned?
It's ready, I just going to write some description and commit it to Github today evening (if I'll have time) or more possible tomorrow. Will write to this topic when done.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 08, 2012, 09:25:22 PM
Post by: gelenkeharald on June 08, 2012, 09:25:22 PM
Hi Alex,
I wanted to tell you, that I made some progress. I'm using pktend signal after 504bytes (126 of my packages) to transfer. In Simulation and Chipscope pktend signal goes high after 504 bytes for one clock period.
If I set trigger to pktend rising edge and using my c++ programm, data is transfered well and listed in console. This works several times in succession until first time error 995 occurs. Then no data is listed in console --> no data transfer from fx2 to pc, this is undesirable!
BUT and now comes a very strange thing: If I don't use Chipscope then data transfer is never successful? I tried it several times. What's that now? Any suggestions? It really makes me angry, because I think I'm so close to the solution.
best regards
GH
update: this morning I tried again something to figure out where this Chipscope influence is comming from
1. running programm without setting chipscope trigger: not successful (several times)
then without disconnecting the device, setting chipscope trigger: and it works, as it should...
2. fpga configuration without chipscope cores: datatransfer not successful
this is so weird :-(
I wanted to tell you, that I made some progress. I'm using pktend signal after 504bytes (126 of my packages) to transfer. In Simulation and Chipscope pktend signal goes high after 504 bytes for one clock period.
If I set trigger to pktend rising edge and using my c++ programm, data is transfered well and listed in console. This works several times in succession until first time error 995 occurs. Then no data is listed in console --> no data transfer from fx2 to pc, this is undesirable!
BUT and now comes a very strange thing: If I don't use Chipscope then data transfer is never successful? I tried it several times. What's that now? Any suggestions? It really makes me angry, because I think I'm so close to the solution.
best regards
GH
update: this morning I tried again something to figure out where this Chipscope influence is comming from
1. running programm without setting chipscope trigger: not successful (several times)
then without disconnecting the device, setting chipscope trigger: and it works, as it should...
2. fpga configuration without chipscope cores: datatransfer not successful
this is so weird :-(
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 09, 2012, 01:33:11 PM
Post by: Oleksandr Kiyenko on June 09, 2012, 01:33:11 PM
Hi gelenkeharald,
Strange behavior... Chipscope cores can affect to FPGA routing, but if your constrains meet it should be no problem.
When you write that transfer is stop, what do you mean ? Reason ? Is FIFO full or software don't see transferred data ?
About situations 1 and 2 you describe - I don't know what cause such situation if you use Chipscope only for monitoring, without control signals. Don't saw such problems in my practice.
Think that you should debug your project software and hardware part in complex to solve this problem. Your project come far away from reference so now only you can debug it.
I just upload Virtual COM example for USB equipped modules, you can get it from Github https://github.com/Trenz-Electronic/TE03XX-Reference-Designs/tree/master/vcom-TE0300
Regards
Alex
Strange behavior... Chipscope cores can affect to FPGA routing, but if your constrains meet it should be no problem.
When you write that transfer is stop, what do you mean ? Reason ? Is FIFO full or software don't see transferred data ?
About situations 1 and 2 you describe - I don't know what cause such situation if you use Chipscope only for monitoring, without control signals. Don't saw such problems in my practice.
Think that you should debug your project software and hardware part in complex to solve this problem. Your project come far away from reference so now only you can debug it.
I just upload Virtual COM example for USB equipped modules, you can get it from Github https://github.com/Trenz-Electronic/TE03XX-Reference-Designs/tree/master/vcom-TE0300
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 09, 2012, 05:26:43 PM
Post by: gelenkeharald on June 09, 2012, 05:26:43 PM
hi alex,
yes strange...:-(
software don't see transferred data
I've got another idea: maybe I configured the reg_in registers wrong...
Reg_in_0 is explained in XPS_FX2_v1_20_a User Manual v1.3 so I set usb_fifoadr, but how did you use pktend_timeout?
what is reg_in_1 for? it's not explained in manual! Is this the Threshold Register? how would you set up this?
by the way my project isn't far away from reference, just fx2-module and package_generator process and TE0300_api_example
best regards
GH
yes strange...:-(
Quote from: Alexander Kienko on June 09, 2012, 01:33:11 PM
When you write that transfer is stop, what do you mean ? Reason ? Is FIFO full or software don't see transferred data ?
software don't see transferred data
I've got another idea: maybe I configured the reg_in registers wrong...
Reg_in_0 is explained in XPS_FX2_v1_20_a User Manual v1.3 so I set usb_fifoadr, but how did you use pktend_timeout?
what is reg_in_1 for? it's not explained in manual! Is this the Threshold Register? how would you set up this?
by the way my project isn't far away from reference, just fx2-module and package_generator process and TE0300_api_example
best regards
GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 09, 2012, 07:39:30 PM
Post by: Oleksandr Kiyenko on June 09, 2012, 07:39:30 PM
Hi gelenkeharald,
If you use fx2_core from xps_fx2_v1_50 you just have to define Reg_in_0(26 to 27) to your endpoint write address, others bits are not needed for you.
pktend_timeout is obsolete parameter (was used till xps_fx2_v1_30).
xps_fx2_v1_50 designed mostly for "stream" transfers (not packet oriented) so it drive PKTEND signal when send last byte from FIFO. If you need other behavior you should modify fx2_engine.vhd or write your own core which will know packet structure you use and will be able to drive PKTEND at the end of packet(s).
Reg_in_1 used to control interrupts in microblaze/ppc system, (yes it's threshold register)- you don't need it if you don't use processor.
Regards
Alex
If you use fx2_core from xps_fx2_v1_50 you just have to define Reg_in_0(26 to 27) to your endpoint write address, others bits are not needed for you.
pktend_timeout is obsolete parameter (was used till xps_fx2_v1_30).
xps_fx2_v1_50 designed mostly for "stream" transfers (not packet oriented) so it drive PKTEND signal when send last byte from FIFO. If you need other behavior you should modify fx2_engine.vhd or write your own core which will know packet structure you use and will be able to drive PKTEND at the end of packet(s).
Reg_in_1 used to control interrupts in microblaze/ppc system, (yes it's threshold register)- you don't need it if you don't use processor.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 10, 2012, 12:12:27 PM
Post by: gelenkeharald on June 10, 2012, 12:12:27 PM
hi Alex,
ok so I made everything right in this direction, modified core for asserting pktend...
I've got another question: I postet the problem to another forum and they suggested me to decrease the usb_if_clk. In the ucf file you are using 48 Mhz for usb_if_clk, but in the scematic file I saw that the osscilator is running with 24 Mhz (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0300_series/TE0300/documents/SCH-TE0300-01.pdf) isn't that a contradiction?
best regards
GH
ps: bye the way I just discoverd 50 Mhz for sys_clk_pin, maybe it's another source of error
pps: no just a thing how I set up the dcms, now they are right (usb_clk_in 24 MHz, sys_clk_in 50 Mhz, I used these frequencies for system and usb), but unfortunatly behaviour is the same (c++programm works with chipscope trigger and without not :-/)
ok so I made everything right in this direction, modified core for asserting pktend...
I've got another question: I postet the problem to another forum and they suggested me to decrease the usb_if_clk. In the ucf file you are using 48 Mhz for usb_if_clk, but in the scematic file I saw that the osscilator is running with 24 Mhz (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0300_series/TE0300/documents/SCH-TE0300-01.pdf) isn't that a contradiction?
best regards
GH
ps: bye the way I just discoverd 50 Mhz for sys_clk_pin, maybe it's another source of error
pps: no just a thing how I set up the dcms, now they are right (usb_clk_in 24 MHz, sys_clk_in 50 Mhz, I used these frequencies for system and usb), but unfortunatly behaviour is the same (c++programm works with chipscope trigger and without not :-/)
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 10, 2012, 12:32:24 PM
Post by: Oleksandr Kiyenko on June 10, 2012, 12:32:24 PM
Hi gelenkeharald,
There is no contradiction between oscillator and usb_if_clk, FX2 have internal PLL which can multiply external 24MHz clock source. Please read FX2 documentation for more details.
Regards
Alex
QuoteI've got another question: I postet the problem to another forum and they suggested me to decrease the usb_if_clk. In the ucf file you are using 48 Mhz for usb_if_clk, but in the scematic file I saw that the osscilator is running with 24 Mhz (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0300_series/TE0300/documents/SCH-TE0300-01.pdf) isn't that a contradiction?Don't sure that it help you. But if you really want to do it you have to rebuild FX2 firmware with new clock settings. You can get firmware from https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2.firmware
There is no contradiction between oscillator and usb_if_clk, FX2 have internal PLL which can multiply external 24MHz clock source. Please read FX2 documentation for more details.
Quoteps: bye the way I just discoverd 50 Mhz for sys_clk_pin, maybe it's another source of errorTE0300 have 100 MHz or 125 MHz main clock source and 48 MHz for FX2 interface, where you found 50 MHz ? Which "source of error" you mean ?
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 10, 2012, 12:38:00 PM
Post by: gelenkeharald on June 10, 2012, 12:38:00 PM
Hi Alex,
I found it here (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0300_series/TE0300/documents/SCH-TE0300-01.pdf) page 4, really wondering about that!
regards GH
I found it here (http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE0300_series/TE0300/documents/SCH-TE0300-01.pdf) page 4, really wondering about that!
regards GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 10, 2012, 01:18:22 PM
Post by: Oleksandr Kiyenko on June 10, 2012, 01:18:22 PM
Hi gelenkeharald,
It was 50 MHz in early TE0300 versions, now it have only 100 MHz and 125 MHz variants. Your module have 125 MHz main clock source.
To use this clock with USB 48MHz clock you should carry about passing clock domains (use FIFO with independent read and write clock).
Regards
Alex
It was 50 MHz in early TE0300 versions, now it have only 100 MHz and 125 MHz variants. Your module have 125 MHz main clock source.
To use this clock with USB 48MHz clock you should carry about passing clock domains (use FIFO with independent read and write clock).
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 12, 2012, 05:56:03 PM
Post by: gelenkeharald on June 12, 2012, 05:56:03 PM
Hello guys,
this is me again...I'm still working at this problem and didn't found a solution :-(. I just builded up a new project, with just the fresh fx2_cores, ucf file form reference design, fifos, dcms and a connection from rx_fifo to tx_fifo. So the system should receive the same data as sent to fpga (it is very close to the reference). But even this is not working. I receive not the same bytes as I sent, but always the same trash:
in: various 4 bytes --> out: d f0 ad ba
this is my loop function in c++
I uploaded my minimum design: I ask you friendly to have a short look over it, please. It would really really help me. I absolutly don't know how to proceed.
http://www.4shared.com/zip/1F3uZLGg/fx2_engine.html
(http://www.4shared.com/zip/1F3uZLGg/fx2_engine.html)
some more information:
I'm using this firmware: http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/firmware/version_3/TE_USB_FX2-v03.00.iic
and this driver: http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/drivers/version_2/TE03xx-USB_32-64.zip
in addition: here is an very detailed instruction what I've done
-create new project
-add fx2_core.vhd and fx2_core.ucf (from latest reference design)
-add libraries proc_common_v3_00_a and xps_fx2_v1_50_a
-add dcm_sys with clkin 125 Mhz and clkfx 100 Mhz
-add dcm_usb with clkin 24 Mhz and clkfx 48 Mhz
-change parameter C_RX_FIFO_KBYTE = 2 to have rx fifo
-add tx_fifo: independent clocks, block ram, first-word-fall-through, write_width: 32, read_width: 8, write_depth: 8192, flags, write_data_count: 13
-add rx_fifo: independent clocks, block ram, first-word-fall-through, write_width: 8, read_width: 32, write_depth: 4096, flags, read_data_count: 10
-create system.vhd: adding all components, instantiating all components, connecting FIFO_IN_din with FIFO_OUT_dout
Many thanks in advance
best regards GH
this is me again...I'm still working at this problem and didn't found a solution :-(. I just builded up a new project, with just the fresh fx2_cores, ucf file form reference design, fifos, dcms and a connection from rx_fifo to tx_fifo. So the system should receive the same data as sent to fpga (it is very close to the reference). But even this is not working. I receive not the same bytes as I sent, but always the same trash:
in: various 4 bytes --> out: d f0 ad ba
this is my loop function in c++
Code Select
void Loop(unsigned int handle)
{
byte * data_in;
data_in = new byte [4]; //allocate memory
byte * data_out;
data_out = new byte [4]; //allocate memory
int error;
int packetlen;
data_in[0] = 0xFF;
data_in[1] = 0xFF;
data_in[2] = 0xFF;
data_in[3] = 0xFF;
packetlen = 4;
if (error=TE0300_SetData(handle, data_in, 4, PI_EP8))
{
printf("ERROR SetData: %d\n", error);
}
if (error = TE0300_GetData(handle, data_out, &packetlen, PI_EP6,TIMEOUT_MS))
{
printf("ERROR GetData: %d\n", error);
}
printf("1: %x --> %x \n", data_in[0], data_out[0]);
printf("2: %x --> %x \n", data_in[1], data_out[1]);
printf("3: %x --> %x \n", data_in[2], data_out[2]);
printf("4: %x --> %x \n", data_in[3], data_out[3]);
delete data_in;
delete data_out;
}
I uploaded my minimum design: I ask you friendly to have a short look over it, please. It would really really help me. I absolutly don't know how to proceed.
http://www.4shared.com/zip/1F3uZLGg/fx2_engine.html
(http://www.4shared.com/zip/1F3uZLGg/fx2_engine.html)
some more information:
I'm using this firmware: http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/firmware/version_3/TE_USB_FX2-v03.00.iic
and this driver: http://www.trenz-electronic.de/fileadmin/docs/Trenz_Electronic/TE-USB-Suite/drivers/version_2/TE03xx-USB_32-64.zip
in addition: here is an very detailed instruction what I've done
-create new project
-add fx2_core.vhd and fx2_core.ucf (from latest reference design)
-add libraries proc_common_v3_00_a and xps_fx2_v1_50_a
-add dcm_sys with clkin 125 Mhz and clkfx 100 Mhz
-add dcm_usb with clkin 24 Mhz and clkfx 48 Mhz
-change parameter C_RX_FIFO_KBYTE = 2 to have rx fifo
-add tx_fifo: independent clocks, block ram, first-word-fall-through, write_width: 32, read_width: 8, write_depth: 8192, flags, write_data_count: 13
-add rx_fifo: independent clocks, block ram, first-word-fall-through, write_width: 8, read_width: 32, write_depth: 4096, flags, read_data_count: 10
-create system.vhd: adding all components, instantiating all components, connecting FIFO_IN_din with FIFO_OUT_dout
Many thanks in advance
best regards GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 13, 2012, 10:10:37 PM
Post by: Oleksandr Kiyenko on June 13, 2012, 10:10:37 PM
Hi gelenkeharald,
I check your project and see several design mistakes:
1) you assigning LE vectors to BE vectors
2)
3) your code is wrong !
only last word will go to tx_fifo
In future please SIMULATE your project BEFORE ask somebody to help you.
P.S. Please don't use sharing services which require registration to download - nobody like it.
Regards
Alex
I check your project and see several design mistakes:
1) you assigning LE vectors to BE vectors
Quote...It's not good practice. Xilinx ISE allow such assignments but other synthesis tools not (there is no considerations for such assignment).
constant EP6ADR : STD_LOGIC_VECTOR( 1 downto 0) := "10";
...
Reg_in_0(26 to 27) <= EP6ADR;
..
2)
Quoteadd tx_fifo: independent clocks, block ram, first-word-fall-through, write_width: 32, read_width: 8, write_depth: 8192, flags, write_data_count: 13in reference project tx_fifo type - Standard FIFO
3) your code is wrong !
Quoteobserve_usb_input: process(SYS_Clk)if you will have received data packet in rx_fifo (not a single word)
begin
if(SYS_Clk'event and SYS_Clk = '1') then
rx_fifo_rst <= '0';
if(FIFO_OUT_valid = '1') then
if(initialize = '0') then
initialize <= '1';
if(FIFO_OUT_dout /= X"FFFFFFFF") then --initializing command
rx_fifo_rst <= '1';
end if;
else
FIFO_IN_din <= FIFO_OUT_dout;
FIFO_OUT_ready <= '1';
end if;
elsif(FIFO_OUT_ready = '1' and FIFO_IN_ready = '1') then
FIFO_IN_valid <= '1';
FIFO_OUT_ready <= '0';
else
FIFO_IN_valid <= '0';
end if;
end if;
end process;
only last word will go to tx_fifo
In future please SIMULATE your project BEFORE ask somebody to help you.
P.S. Please don't use sharing services which require registration to download - nobody like it.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: Horsa on June 14, 2012, 12:38:56 PM
Post by: Horsa on June 14, 2012, 12:38:56 PM
Quote from: Horsa on June 05, 2012, 11:22:20 AM
This is a known issue for 32 bit version. We are investigating.
With the kind support of a Cypress engineer, we could fix the problem, due to includes issues we could not find any official documentation for.
http://www.cypress.com/?app=forum&id=167&rID=64182
We will push the fixes by tomorrow in GitHub.
Title: Re: TE0300DLL.dll question
Post by: gelenkeharald on June 19, 2012, 05:37:36 PM
Post by: gelenkeharald on June 19, 2012, 05:37:36 PM
hi alex,
thank you for checking my project, please excuse for my design mistakes and sharing service problem.
I made some progress. Can send data to fpga and receive the same packages. But I still have some understanding problems. I guess there are some timing problems in the project.
I only wanna ask you some understanding questions:
First: TIMESPEC TS_USB_IFCLK_pin = PERIOD USB_IFCLK_pin 20833 ps; from fx2_core.ucf
how does that fit together with the oscillator frequency? I remember I asked you the same questions some weeks ago, but it still doesn't make sense for me.
Let me explain what I understand and please correct me, if I'm wrong.
oscillator frequency: 24 Mhz
is routed to fpga USB_IFCLK_pin and fx2 (the pin name is not important), so that means fx2 and fx2_core module are running with the same clock
24 Mhz or 48 Mhz?
24 Mhz: I don't need a dcm in fpga for USB_IFCLK_pin, but then constrain is wrong!
48 Mhz: I have to use a dcm in fpga for USB_IFCLK_pin to double 24 Mhz external clock! contrain is right!
So what is right?
Second: Another thing is reaching the contraints:
I clocked OUT all the signals from fpga to fx2
the result, deterministic behaviour of data transfer, but the problem with 1 byte shifted packages
Then I tried to clock in the other signals from fx2 to fpga, but I get inadmissible signal assignment (X) in behavioral simulation
Do I have to clock in these signals? Is it right to clock USB_FD_I, USB_FD_O, USB_FD_T, too? Did I clocked them right?
the addition temp is to show that this signal isn't synchronized to USB_CLK ( USB_FD_T_temp and USB_FD_O_temp from fx2_core; USB_FD_I_temp from iobuf)
Thank you
best regards
GH
thank you for checking my project, please excuse for my design mistakes and sharing service problem.
I made some progress. Can send data to fpga and receive the same packages. But I still have some understanding problems. I guess there are some timing problems in the project.
I only wanna ask you some understanding questions:
First: TIMESPEC TS_USB_IFCLK_pin = PERIOD USB_IFCLK_pin 20833 ps; from fx2_core.ucf
how does that fit together with the oscillator frequency? I remember I asked you the same questions some weeks ago, but it still doesn't make sense for me.
Let me explain what I understand and please correct me, if I'm wrong.
oscillator frequency: 24 Mhz
is routed to fpga USB_IFCLK_pin and fx2 (the pin name is not important), so that means fx2 and fx2_core module are running with the same clock
24 Mhz or 48 Mhz?
24 Mhz: I don't need a dcm in fpga for USB_IFCLK_pin, but then constrain is wrong!
48 Mhz: I have to use a dcm in fpga for USB_IFCLK_pin to double 24 Mhz external clock! contrain is right!
So what is right?
Second: Another thing is reaching the contraints:
I clocked OUT all the signals from fpga to fx2
Code Select
process(USB_CLK)
begin
if(USB_CLK'event and USB_CLK = '1') then
USB_SLRD_pin <= USB_SLRD;
USB_SLWR_pin <= USB_SLWR;
USB_SLOE_pin <= USB_SLOE;
USB_PKTEND_pin <= USB_PKTEND;
USB_FIFOADR_pin <= USB_FIFOADR;
USB_FD_I <= USB_FD_I_temp;
USB_FD_T <= USB_FD_T_temp;
USB_FD_O <= USB_FD_O_temp;
end if;
end process;
the result, deterministic behaviour of data transfer, but the problem with 1 byte shifted packages
Then I tried to clock in the other signals from fx2 to fpga, but I get inadmissible signal assignment (X) in behavioral simulation
Code Select
process(USB_CLK)
begin
if(USB_CLK'event and USB_CLK = '1') then
USB_FLAGA <= USB_FLAGA_pin;
USB_FLAGB <= USB_FLAGB_pin;
USB_FLAGC <= USB_FLAGC_pin;
USB_FLAGD <= USB_FLAGD_pin;
end if;
end process;
Do I have to clock in these signals? Is it right to clock USB_FD_I, USB_FD_O, USB_FD_T, too? Did I clocked them right?
the addition temp is to show that this signal isn't synchronized to USB_CLK ( USB_FD_T_temp and USB_FD_O_temp from fx2_core; USB_FD_I_temp from iobuf)
Thank you
best regards
GH
Title: Re: TE0300DLL.dll question
Post by: Oleksandr Kiyenko on June 19, 2012, 07:43:10 PM
Post by: Oleksandr Kiyenko on June 19, 2012, 07:43:10 PM
Hi gelenkeharald,
You don't need to clock USB interface input or output signals - it's already done inside fx2_engine.vhd when needed. Adding this clocking you shift control signals timing. As core made to reach maximum possible bandwidth, it don't have wait states so your code destroy internal logic. The same right for FD pins. Just connect it to external pins - no extra logic required.
Regards
Alex
QuoteLet me explain what I understand and please correct me, if I'm wrong.24MHz from clock oscillator -> FX2 (inside FX2 chip PLL module multiply this frequency x2) -> 48 MHz at USB_IFCLK_pin -> FPGA
oscillator frequency: 24 Mhz
is routed to fpga USB_IFCLK_pin and fx2 (the pin name is not important), so that means fx2 and fx2_core module are running with the same clock
24 Mhz or 48 Mhz?
24 Mhz: I don't need a dcm in fpga for USB_IFCLK_pin, but then constrain is wrong!
48 Mhz: I have to use a dcm in fpga for USB_IFCLK_pin to double 24 Mhz external clock! contrain is right!
So what is right?
You don't need to clock USB interface input or output signals - it's already done inside fx2_engine.vhd when needed. Adding this clocking you shift control signals timing. As core made to reach maximum possible bandwidth, it don't have wait states so your code destroy internal logic. The same right for FD pins. Just connect it to external pins - no extra logic required.
Regards
Alex
Title: Re: TE0300DLL.dll question
Post by: Hengist on April 11, 2014, 06:32:46 PM
Post by: Hengist on April 11, 2014, 06:32:46 PM
The release of the third generation Trenz Electronic USB FX2 Suite made this post obsolete. Please access current documentation and resources here: TE USB FX2 Suite (https://wiki.trenz-electronic.de/display/TEUSB/).