Xmega lufa and usb 3.0 problem.

Go To Last Post
53 posts / 0 new

Pages

Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Experts,
I write a program based on LUFA for xmega32a4u device.
It sends and receives data from USB Port of computer.

It works perfect with USB 2.0 Ports, but when I connect it to USB port 3.0, enumeration phase passes but sending and receiving packets are not successful.

Is there any issue about USB 3.0 and xmega devices.

Xmega devices work in USB full speed mode.
Thanks for help.

This topic has a solution.
Last Edited: Thu. Aug 13, 2020 - 03:35 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The 'L' in "LUFA" stands for Lightweight.

 

http://www.fourwalledcubicle.com/LUFA.php

 

So I wouldn't be surprised if it (and/or your code) is missing something which you can get away with on USB 2, but breaks compatibility on USB 3.

 

You're probably going to need some proper USB debug tools for this ...

 

EDIT

 

Free USB analyser mentioned here: https://www.avrfreaks.net/commen...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Wed. Jul 15, 2020 - 04:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Awneil

The analyzer was great.

I used it and find that only downstream packets are sent toward device I can not get upstream packets,

FYI, both downstream and upstream endpoints are isochronous and I send and receive real time data with device. 

Now question changed,

Why I can send downstream packets while I can not receive upstream packets?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have also another Question.

My design has 2 isochronous endpoints.

One IN endpoint.

One OUT endpoint.

IN endpoint receives 64 KB of data per second.

OUT endpoint sends 32 KB of data per second.

I need to inform this information to windows and linux OS in enumeration phase to reserve bandwidth for it.

What I am suppose to do?

 

As you see my design is a bit complicated. 

It is also possible to send 64KB of data downstream instead of 32KB and send 32KB of garbage data with 32KB or real data.

In this way both IN and OUT endpoints will have equal bandwidth.

 

Size of IN endpoint is 32 bytes and I receive 1000 packets per second now.

Size of  OUT endpoint is 64 bytes  and I send 1000 packets per second now. 

 

XMEGA32A4U device is setup as USB 1.1 full speed mode which is capable of handling 12 Mbps of data.

 

Everything is OK with USB 2.0 ports

I do not receive IN packets in USB 3.0 ports.

 

Thanks Experts,

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

There is a bug in the USB hardware.  USB 3 is somewhat slower during the setup phase and that activates the bug.   I sent a trouble report to Microchip a year ago.

 

This problem only happens when you use USB SOF (start of frame) as the "gold standard" clock for the DFLL.  It's the same problem that happens when the host PC awakens from sleep.  

 

The hardware detects the bus suspend condition and disables the DFLL.  That works.  When the hardware detects the resume, it immediatelly enables the DFLL.  We don't get the SOF until some time after the resume.  If it starts within 11 milliseconds, the DFLL works.  If it starts 50 milliseconds after resume, the DFLL goes nuts.  The fix is to disable and then enable DFLL after we start getting SOF.

 

I have USB code that works, but it's written in C++.  It could be adapted to work with C code.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

Could you please share the code here.

Or explain more what is supposed to change in code.

I use LUFA library.

As today's computers are full of USB 3 ports, it is really vital for this micro controller to work with it.

I also have a MKII device programmer which contains a AVR processor and it also does not work with USB 3 port.

I think its good idea to ask Dean Camera to come and see this discussion, it this way LUFA gets updated and stronger when working with USB 3.0 ports.

 

Thanks

 

Last Edited: Thu. Jul 16, 2020 - 02:04 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58 wrote:
... it this way LUFA gets updated and stronger ...
Consider creating a LUFA issue or posting on its list

Four Walled Cubicle - LUFA (Formerly MyUSB)

(bottom, right column)

Project Links

mehrdad_58 wrote:
... when working with USB 3.0 ports.
https://github.com/abcminiuser/lufa/issues?q=USB3

 

 

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Thu. Jul 16, 2020 - 04:39 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

mehrdad_58 wrote:
As today's computers are full of USB 3 ports, it is really vital for this micro controller to work with it.

I'm sure Dean will be happy to refund the full price you paid if it doesn't meet your requirements ...

 

cheeky

 

I think its good idea to ask Dean Camera to come and see this discussion

Sure - you can do that.

 

You might gain attention by making a donation:

 

 

If you want priority support, there's a commercial licence available:  http://www.fourwalledcubicle.com/PurchaseLUFA.php

 

EDIT

 

The project is on Github - you could raise an Issue there:

 

http://www.github.com/abcminiuse...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
Last Edited: Thu. Jul 16, 2020 - 05:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Experts,

 

I create an issue in github site.

https://github.com/abcminiuser/lufa/issues/165

 

I hope Dean can resolve this bug. 

 

Thanks for your support especially Steve17 for sharing his useful experiences.  

 

I am one of the fans of C and C++ open source projects.

 

LUFA is one of those projects.

LIBSDL is second one (www.LIBSDL.org

POCO is another one which makes it possible to write web servers by using C++. (www.pocoproject.org)

and also a lot of other projects which I used previously.

 

But my connection to AVR micro controllers and hardware projects started by using LUFA. 

 

I hope if I can implement some commercial projects based on it.

 

Thanks, 

 

 

 

 

 

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Sure Awneil,

Sure,

LUFA is my connection to HARDWARE world.

It is more that an open source project to me. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can come up with something.  I guess you want the CDC thing that creates a virtual serial port. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thinking about it now, the fix seems simple.  If it's not simple, sue me. 

 

1.  Enable resume interrupts at startup.

 

2.  When a resume interrupt occurs, enable SOF interrupts.

 

3 When an SOF interrupt occurs, disable, wait for disable, then enable the DFLL.

      Disable SOF interrupts.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

My design is based on 2 IN and OUT isochronous endpoints, It is a dedicated hardware which I have to write a dedicated driver for it under windows OS.

CDC is based on BULK and interrupt endpoints as far as I know.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You are right about CDC.  It is used because it creates a serial port (virtual) that any program can easily open.

 

I'm guessing you are using WinUSB or the similar LibUSB.  These can be used for just about any USB device.  Windows splits it's driver for these into 2 parts.  Windows supplies the kernel mode driver and we supply the user mode driver.

 

I have WinUSB but only bulk endpoints.  I don't know how easy it would be to add isochronous.  It might be easy.

 

abcminiuser (Dean Camera) has code for WinUSB on GitHub.  I don't know if he implements isochronous endpoints.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 I don't know if he implements isochronous endpoints.

 

Please look at AudioInput and AudioOutput samples of LUFA which use isochronous endpoints.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I could probably fix Dean's code (LUFA) if it won't work with USB 3.  He writes code that is easy to read.

 

Point me to the code you use.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

 

Please have a look at following link:

 

http://www.fourwalledcubicle.com/LUFA.php

 

Scroll to the end of page and in download section you will see:

 

LUFA_170418.

 

 

 

It is the latest version of it. 

 

Thanks in advance,

 

Last Edited: Sat. Jul 18, 2020 - 04:04 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Holy cows.  That's a lot of stuff.  I was hoping for a USB project ready to build.  Preferably An Atmel studio project.  Is there one?

 

I should only need the USB bus event ISR.  I looked around a bit and I didn't see any ISRs except one for a timer.  I noticed in lufa-LUFA-170418\Demos\Device\ClassDriver\AudioOutput  there is a file named asf.xml.  Maybe the ISR is in the ASF stuff.  I know nothing about ASF nor how to see the source. 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,
I use bulkvendor sample program.

I changed bulk endpoints to isoc and start to work with it.

Let me share source code in next message.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

I share a simplified version of my project here.

It just reads and write to endpoints.

all other stuff are deleted for simplicity.

I use version 7 of atmel studio to compile it.

Attached file is phase#7.rar

 

 

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am surfing the code and find that there is an interrupt here 

 

Phase#07\VENDOR\VENDOR\src\LUFA\LUFA\Drivers\USB\Core\XMEGA\USBInterrupt_XMEGA.c

 

Please also have a look at other files in above folder.

All stuff about XMEGA USB is handled there.

 

Good Luck Steve.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Yes that file handles the various buss events.  It can handle a bunch of them including the ones I want.  Resume and SOF.  I'll need to make sure the configuration enables those.

 

The way the LUFA is set up may allow it to handle many devices and protocols but it's way to complicated for me.  The files are in directories nested 10 deep.  I think I can fix the problem though.

 

When I built the bulkvendor program, it built okay but it also produced a lot of messages and warnings.  Is this supposed to happen?

 

How do I tell if the program is running?

 

I don't see it in device manager, but I don't know where to look.  When I run my own WinUSB program, it shows up at the bottom of the Device Manager list.

 

 

Last Edited: Sat. Jul 18, 2020 - 08:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually, when I plug in the board or reset my xmega128a4u, I should hear the ding dong or dong ding, but I hear nothing.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


When I run with the debugger, it doesn't stop at main or any breakpoint.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


As soon as it starts it sits at 10000.  Maybe it's trying to tell me something.  I did change the device to 128a4u. 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It is very nice that you have a debugger.
But I do not have.
Thus I compile the code and upload hex file and test by device.
The program is developed to work with xmega32a4u device.
I am afraid when you change the type of micro something bad happens
Lufa has a self config file for micro definition.
Let me find and tell you.
Please tell me your current version of atmel studio.

Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Steve,

We can also do it in another way. 

Is it possible that you just update the interrupt vector and let me compile and test it by my device?

You know I do not have any experience with debugger tool thus I can not help with it. 

I use ancient way of code development by producing Hex file and uploading it to device to check the result of program by real hardware. 

 

 

I make another project based on LUFA library and BulkVendor sample program for xmega128a4u micro controller which uses bulk endpoints.

Please check attached version.

I hope if this one works.

Thanks  

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi again Steve,

Those warnings that you see in code are safe.

I also see those warnings.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I will try your phase 8.  Here's the Studio I'm using.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I am making good progress.  The phase 8 stuff builds cleanly.  No warnings or messages.  The program is installed on the AVR and seems to be running.  I see the LUFA Buld Vendor Demo in the Device Manager list.

 

It needs a driver.  I found a driver .inf here:

 

When I right click on it and click "install", I get this:

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


I tried Win7.  It's not as particular as Win10.  It let me install the driver.  It seems to be working, just not doing anything. Surprisingly it seems to work the same when plugged into USB3 as when plugged into USB2.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Steve
But driver installation is not the sign of bug removal.
My firmware also leds to successful driver installation.
But when working with endpoints, only out packets are sent.
Could you please share the changes, in this way I can test if bug is removed or not.
Thanks

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI
If you bring windows 10 into test mode, then drivers like bunkvendor will install easily.
Google " how to bring win 10 to test mode" please

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I don't like the idea of using test mode.  It would be strange if LUFA required that.  I searched the internet for Windows 10 test mode.  I got dozens of hits for disabling it but none for enabling it.

 

I'm guessing Win7 is okay with the LUFA thing on USB3 or Device Manager would show something wrong.  Is there a PC test program to see if it is working?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Phase#8 uses bulk endpoints.
Mine uses isoc endpoints.
Are you a Visual C++ programmer?
In this way you can write some simple program to test it.
You can also leave it to me.
I share the result here.
I am in need of getting answer from isoc endpoints.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58 wrote:

Phase#8 uses bulk endpoints.
Mine uses isoc endpoints.
Are you a Visual C++ programmer?
In this way you can write some simple program to test it.
You can also leave it to me.
I share the result here.
I am in need of getting answer from isoc endpoints.

Yes I use Visual C++ and I use avr-gcc C++ on the Xmega.  I cuss and swear when I have to use C.  angry

 

If you can give me the test program, that would be good.

 

I also think there is a way for me to test this LUFA thing on Win7 with a few changes for debugging purposes.  I can enable SOF interrupts and count them.  If it is working on Win7 I will see the count increment.  If it does increment, that is a pretty good sign it is working.  I can then put my fix in, and if that works, the SOF count should show it increasing.

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

OK Steve,

 

Because my sample program uses isoc endpoints, it is not useful for this test now.

I share libusb here.

 

I find a sample  from this link which I uploaded by the name of sample.cpp. it needs to be changed in following way.

 

1. change the EP address of IN and OUT endpoints in line 7 and 8.

2. change vendor ID and Device ID of program in line 171 of sample.cpp to support phase#8 vendor ID and device ID.

2. change the end part of program in a way that it reads and writes consecutively like following. It needs some minor changes to read and write exactly equal to endpoint sizes.

 

 

	while(true)
	{
		e = libusb_bulk_transfer(handle, BULK_EP_IN, my_string, length, &transferred, 0);
		if(e == 0 && transferred == length)
		{
			printf("\nWrite successful!");
			printf("\nSent %d bytes with string: %s\n", transferred, my_string);
		}
		else
			printf("\nError in write! e = %d and transferred = %d\n", e, transferred);

		sleep(3);
		i = 0;
        e = libusb_bulk_transfer(handle, BULK_EP_OUT, my_string1, 64, &received, 0);  //64: Max Packet Length
        if(e == 0)
        {
            printf("\nReceived: ");
            //printf("%c", my_string1[i]); //Will read a string from LPC2148
            sleep(1);
        }
        else
        {
            printf("\nError in read! e = %d and received = %d\n", e, received);
            return -1;
        }
	}

 

I also try to make a sample Visual C++ project based on what I told and share it here. 

Although I am sure that you know how to proceed, But I also write the sequences of operation here.

1. unzip libusb tar file.

2. go to msvc folder inside it and open one of those libusb_20**.sln files based on your installed version of Visual Studio.

3. compile libusb-1.0 (dll) to produce necessary library files.

Now you have lib and dll files for libusb inside Win32 folder.

4. create a new console application in visual studio for C++. (32 bit is enough)

5. copy the contents of the sample.cpp to main.cpp of it.

6. apply above mentioned changes for endpoints and vendor id and device id.

7. add necessary lib folder and libusb file in configuration.

8. add necessary header folder to point to the libusb folder

9. compile the program.

10. copy libusb dll file near the produced exe file. 

11. try to debug the program. 

 

 

 

 

 

 

 

Attachment(s): 

Last Edited: Mon. Jul 20, 2020 - 02:12 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I also make a project with visual studio 2013 and upload it here.

It is based on sample.cpp and all lib and dll and header stuff are handled. 

Also Endpoints and vendor id and device id are handled.

only final loop is not handled.

Please change it as you want. 

 

 

 

Attachment(s): 

Last Edited: Mon. Jul 20, 2020 - 02:46 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Okay.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I was busy today but I did spend some time using Win7.  I have a question about doxygen.  I did a "make doxygen" in the LUFA folder and it worked.  It wouldn't work in your phase 8.  That's not a problem, I guess.  What I'm wondering about is all the #if defined(__DOXYGEN__) stuff.  Hopefully that only affects the documentation and not the code.

 

#if !defined(ISR) || defined(__DOXYGEN__)
   /** Macro for the definition of interrupt service routines, so that the compiler can insert the required
    *  prologue and epilogue code to properly manage the interrupt routine without affecting the main thread's
    *  state with unintentional side-effects.
    *
    *  Interrupt handlers written using this macro may still need to be registered with the microcontroller's
    *  Interrupt Controller (if present) before they will properly handle incoming interrupt events.
    *
    *  \note This macro is only supplied on some architectures, where the standard library does not include a valid
    *        definition. If an existing definition exists, the alternative definition here will be ignored.
    *
    *  \ingroup Group_GlobalInt
    *
    *  \param[in] Name  Unique name of the interrupt service routine.
    */
   #define ISR(Name, ...)          void Name (void) __attribute__((__interrupt__)) __VA_ARGS__; void Name (void)
#endif

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lufa was added to Atmel studio recently.
I use atmel studio to generate phase#8.
I do not import src code of LUFA in atmel studio.
Thus phase#8 may not support doxygen

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Miss you Steve 😊

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm making progress.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

 

I have a fix for the USB3 problem, but I can't be sure of it because the LUFA USB seems to work without the fix.  I don't understand that.  My USB will not work with USB3 without the fix.  Windows says "Unknown USB device" when I try to use my USB code without the fix in the AVR with USB3.  LUFA seems to have no problem.

 

 

 

Here's Device Manager without the fix:

 

 

I haven't been able to build the test program yet.

 

My fix is all in USBInterrupt_XMEGA.c, which I've attached.

 

EDIT:  I uploaded a slightly cleaner USBInterrupt_XMEGA.c a few posts after this one.  They both work the same but the later one puts //steve17 on a few lines I missed, and removed a commented out line which could only cause confusion.

 

Attachment(s): 

Last Edited: Sat. Jul 25, 2020 - 10:48 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

steve17 wrote:
I have a fix for the USB3 problem, but I can't be sure of it because the LUFA USB seems to work without the fix.  I don't understand that.
... and I don't comprehend.

What operating system version?

Notebook mode, desktop mode, server mode, ... ? (power mode)

Reason :

What’s The Difference Between USB 2.0 And 3.0 Hubs? | Electronic Design

...

 

USB Power Management

[third paragraph]

In general, a bus driver and/or higher-level driver running on the host CPU implements the overall power management strategy for the USB topology, such as when to put any part of the USB topology into a reduced power state and how deeply to reduce its power, depending on the resume latency that might be needed. 

...

WinUSB underwent a major re-write for Windows 10.

USB3 was an addition to Windows 7; USB3 is a part of Windows 8.

 

edit : Windows lifecycle fact sheet

"Dare to be naïve." - Buckminster Fuller

Last Edited: Sat. Jul 25, 2020 - 06:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem happens when the xmega uses DFLL that uses the USB SOF to get an accurate 48 MHz clock.  When the USB hardware sees a suspend it disables DFLL.  Otherwise the lack of SOF would clobber the frequency.  When the hardware sees a resume, it enables the DFLL.  The delay following the resume before we see the first SOF varies.  The delay using a USB 3 port is so long (50 ms) that the DFLL goes crazy and needs to be "reset".  

 

The same thing happens when the host PC awakens from sleep with both USB 2 and USB 3.

 

I see this on my computers when running Win10 and Win7.

Last Edited: Sat. Jul 25, 2020 - 07:47 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

mehrdad_58.  Here is a slightly cleaner USBInterrupt_XMEGA.c. It's the same code as before, but I put the // steve17 comment on a few lines I missed before.  I also deleted a commented out line that existed in the first post.  Either one would work the same, but this one can make it easier to see my changes.

 

I should mention my changes are just 2 chunks of code plus the three lines at the top that added 2 counters and 1 flag.  I didn't remove any of the original code.

 

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks Steve
Let me test it

My Problem with USB 3.0 is that when I try to work with my device which has an IN isoc endpoints  and an OUT isoc endpoint, I find that only OUT transactions work.

If the changes result in both endpoints to work concurrently, then issue is over.

I will report soon.

 

Last Edited: Sun. Jul 26, 2020 - 04:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I test it,

It can not read data from IN endpoint yet.

But let me test more.
I have to debug deeper.

 

Last Edited: Sun. Jul 26, 2020 - 11:42 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I find something weird in my project.

By reading more, I find that reading and writing to ISOC endpoints with USB 3.0 has no problem in LUFA. 

But my design has a dip switch that at the beginning of program I read it. 

I use a bulk IN endpoint to read the data of that dip switch.

and at the beginning of the program I read it once.

But problem is that when I read it when the port is connected to USB 2.0 port, I can immediately get the contents of it. 

But when I read it when the device is connected to USB 3.0 port. Program halts and I can not read from it. 

 

This is the code that I read from bulk endpoint in windows OS.

 

 


	UCHAR Buffer[34];
	UINT BufferLength = 34;
	UINT LengthTransferred;
        int  gle;

	UsbK_ResetPipe(m_usbHandle, (UCHAR)0x84);
	if (UsbK_ReadPipe(m_usbHandle, 0x84, &Buffer[0], BufferLength, &LengthTransferred, NULL) == FALSE)
	{
		gle = GetLastError();
	}

 

when I comment above code, reading and writing from isoc endpoints are done without any problem. 

But when I read from bulk endpoint by using above code from USB 3.0 port, program halts. 

 

Thus it seems working with both isoc and bulk endpoints may face some problems when working with USB 3.0 ports. 

 

following is the main loop of firmware that I shared.

 

Please tell me where I go wrong.

 

	for (;;)
	{

		USB_USBTask();
		//////////////////////////////////////////////////////////
		Endpoint_SelectEndpoint(VENDOR_CONFIG_EPADDR); // bulk endpoint
		if(Endpoint_IsINReady())
		{
			memset(tempBuffer,0,VENDOR_IO_EPSIZE);
			tempBuffer[0] = ProcessSwitch();

			Endpoint_Write_Stream_LE(tempBuffer, VENDOR_IO_EPSIZE, NULL);
			if(!Endpoint_IsReadWriteAllowed())
			{
				Endpoint_ClearIN();
			}
		}
		////////////////////////////////////////////////////////
		if(true)
		{
			Endpoint_SelectEndpoint(VENDOR_OUT_EPADDR); // isoc endpoint
			if (Endpoint_IsOUTReceived())
			{
				if(!Endpoint_IsReadWriteAllowed())
				{
					Endpoint_ClearOUT();
				}
			}
		}
		USB_USBTask();
		if(GetSendQSize() >= CHUNK )		
		{
			Endpoint_SelectEndpoint(VENDOR_IN_EPADDR); // isoc endpoint.
			if(Endpoint_IsINReady())
			{
				Endpoint_Write_Stream_LE(tempBuffer, VENDOR_IN_EPSIZE, NULL);
				if(!Endpoint_IsReadWriteAllowed())
				{
					Endpoint_ClearIN();
				}
			}
		}
	}

 

 

 

 

 

 

 

 

 

 

 

 

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

Hi Experts,

Finally I find what was the reason that I can not read data from BULK endpoint.

The size of my BULK endpoint was set to 34 bytes because I have another endpoint with that size and I use the constants variables of it for that.

After testing a lot and not getting answer, I say to myself lets change the size of bulk endpoint because I just only need one byte for it to read dip switch values.

By decreasing the size to 8 bytes, I could read data from that BULK endpoint.

I do not get why it worked finally but it works now.

Thanks to all who helped me in this bug. especially Steve17 for his invaluable help and support.

Best wishes,

Pages