Author Topic: TE0300DLL.dll question  (Read 38669 times)

erik

  • Active Member
  • *
  • Posts: 1
TE0300DLL.dll question
« 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

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #1 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
Assumption is a mother of all fuck-ups.

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #2 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
Assumption is a mother of all fuck-ups.

Hengist

  • Global Moderator
  • Jr. Member
  • *****
  • Posts: 54
Re: TE0300DLL.dll question
« Reply #3 on: April 17, 2012, 11:36:26 PM »
We are currently beta-testing two new libraries:
  • one based on Cypress CyUSB.dll (managed Microsoft .NET class library)
  • one based on Cypress CyAPI.lib (C++ programming interface)
both based on the latest Cypress drivers. With them you can modify two parameters (XferSize and PacketSize). This should help when experiencing packet drop. As Ales wrote, this issue is worsened by the indeterministic behavior of the managed Microsoft .NET class library.

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
(obviously excluding the assertion of PACKET_END pin).
« Last Edit: April 18, 2012, 10:07:25 AM by Hengist »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #4 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
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

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

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #5 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
Assumption is a mother of all fuck-ups.

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #6 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/
You need to install the new Trenz Electronic USB FX2 driver. As we got Window Hardware Logo (formerly: WHQL, WinQual), our drivers are automatically distributed by Microsoft. Just follow the automatic installation procedure available on Windows 7. Preliminary extended documentation is available.

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #7 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

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #8 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
Assumption is a mother of all fuck-ups.

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #9 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

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #10 on: June 04, 2012, 03:14:40 PM »
Quote from: gelenkeharald
Firmware is: TEFW_2.02.0000.iic
vid: 0547
pid: 1002
Are 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
  https://github.com/Trenz-Electronic/TE-USB-Suite/tree/master/TE_USB_FX2.firmware
are instead up to date.

Quote from: gelenkeharald
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.
That is normal. Instead of "%TE-class-name%", the new Trenz Electronic USB device class name should appear.

Quote from: gelenkeharald
TE03xx-USB_32-64.old_VID_PID.zip: yes I can see the device under usb-controllers
That is normal.
« Last Edit: June 04, 2012, 03:17:42 PM by Horsa »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #11 on: June 04, 2012, 03:33:13 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...
« Last Edit: June 04, 2012, 03:39:00 PM by gelenkeharald »

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #12 on: June 04, 2012, 04:11:50 PM »
Yes, here you are:

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #13 on: June 04, 2012, 04:21:34 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

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #14 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
« Last Edit: June 04, 2012, 05:47:00 PM by Hengist »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #15 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...

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #16 on: June 05, 2012, 11:22:20 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. "

old TE0300_API_Example: works!
TE_USB_FX2_CyUSB_SampleApplication: compiling possible, but detects no devices!
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, ...

TE_USB_FX2_CyAPI_SampleApplication: win32 compilation failes error in winnt.h and Winbase.h
This is a known issue for 32 bit version. We are investigating. Does anyone have a clue? Then please share.
« Last Edit: June 05, 2012, 11:25:44 AM by Horsa »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #17 on: June 05, 2012, 11:47:11 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...




Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #18 on: June 05, 2012, 12:10:06 PM »
operating system: windows 7
Please more info: 32 or 64 bit?

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
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?

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #19 on: June 05, 2012, 01:26:57 PM »
Please more info: 32 or 64 bit?

32 bit system
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.

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #20 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!
« Last Edit: June 05, 2012, 03:55:40 PM by gelenkeharald »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #21 on: June 05, 2012, 04:35:44 PM »
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
(obviously excluding the assertion of PACKET_END pin).

have you ever tried package generation in fpga with fixed time interval? e.g. every 100µs? and read them successfully?

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #22 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
Assumption is a mother of all fuck-ups.

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #23 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

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #24 on: June 05, 2012, 11:49:52 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."

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #25 on: June 06, 2012, 12:12:07 AM »
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
Everything (driver installation and test application) flew simply as intended.

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?

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #26 on: June 06, 2012, 10:02:31 AM »
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
Everything (driver installation and test application) flew simply as intended.

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

Ales Gorkic

  • Jr. Member
  • **
  • Posts: 80
    • Optomotive Cameras
Re: TE0300DLL.dll question
« Reply #27 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
Assumption is a mother of all fuck-ups.

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #28 on: June 06, 2012, 01:02:24 PM »
hi ales,

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?

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

Horsa

  • Full Member
  • ***
  • Posts: 145
  • Trenz Electronic GmbH
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #29 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).

A) .NET 4
What version exactly? The reference manual requires .NET Framework version ≥ 4.0.30319

C) its the same VID/PID

Fine. Which ones?

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).
« Last Edit: June 06, 2012, 01:16:23 PM by Horsa »

Thorsten Trenz

  • Administrator
  • Full Member
  • *****
  • Posts: 154
    • Trenz Electronic GmbH
Re: TE0300DLL.dll question
« Reply #30 on: June 06, 2012, 01:20:26 PM »
Hi,

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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #31 on: June 06, 2012, 01:40:24 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...
« Last Edit: June 06, 2012, 02:08:53 PM by gelenkeharald »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #32 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #33 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)
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

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #34 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #35 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!
« Last Edit: June 07, 2012, 04:01:22 PM by gelenkeharald »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #36 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #37 on: June 08, 2012, 09:58:16 AM »
post deleted
« Last Edit: June 08, 2012, 10:19:14 AM by gelenkeharald »

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #38 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

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #39 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #40 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

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #41 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #42 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 :-(
« Last Edit: June 09, 2012, 10:17:06 AM by gelenkeharald »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #43 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #44 on: June 09, 2012, 05:26:43 PM »
hi alex,

yes strange...:-(

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
« Last Edit: June 09, 2012, 05:54:39 PM by gelenkeharald »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #45 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #46 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 :-/)
« Last Edit: June 10, 2012, 12:29:59 PM by gelenkeharald »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #47 on: June 10, 2012, 12:32:24 PM »
Hi gelenkeharald,
Quote
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?
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.

Quote
ps: bye the way I just discoverd 50 Mhz for sys_clk_pin, maybe it's another source of error
TE0300 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

gelenkeharald

  • Active Member
  • *
  • Posts: 43
Re: TE0300DLL.dll question
« Reply #48 on: June 10, 2012, 12:38:00 PM »

Oleksandr Kiyenko

  • Global Moderator
  • Sr. Member
  • *****
  • Posts: 404
Re: TE0300DLL.dll question
« Reply #49 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