zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Mon Apr 01, 2019 5:22 am

Hi,

I am trying to use CSUD usb driver found here https://github.com/Chadderz121/csud.

Current status:
It is able to attach fake root hub.
It is able to detect reat USB Hub 2.0
It is able to detect all the children i.e LAN port which is non removable and other devices connected to 4 ports of raspberry pi 3b.

I am trying to port the HID part where I am facing alignment issues. Basically processor throws exception and halts.

Details for exception:
DFSR : 0001 => Alignment issues.

I checked whenever I am trying to access this https://github.com/Chadderz121/csud/blo ... hid.c#L899

Code: Select all

struct HidDescriptor {
	u8 DescriptorLength; // +0x0
	enum DescriptorType DescriptorType : 8; // +0x1
	u16 HidVersion; // (bcd version) +0x2 
	enum HidCountry {
		CountryNotSupported = 0,
		Arabic = 1,
		Belgian = 2,
		CanadianBilingual = 3,
		CanadianFrench = 4,
		CzechRepublic = 5,
		Danish = 6,
		Finnish = 7,
		French = 8,
		German = 9,
		Greek = 10,
		Hebrew = 11,
		Hungary = 12,
		International = 13,
		Italian = 14,
		Japan = 15,
		Korean = 16,
		LatinAmerican = 17,
		Dutch = 18,
		Norwegian = 19,
		Persian = 20,
		Poland= 21,
		Portuguese = 22,
		Russian = 23,
		Slovakian = 24,
		Spanish = 25,
		Swedish = 26,
		SwissFrench = 27,
		SwissGerman = 28,
		Switzerland = 29,
		Taiwan = 30,
		TurkishQ = 31,
		EnglishUk = 32,
		EnglishUs = 33,
		Yugoslavian = 34,
		TurkishF = 35,
	} Countrycode : 8; // +0x4
	u8 DescriptorCount; // +0x5
	struct {
		enum DescriptorType Type : 8; // +0x0
		u16 Length; // +0x1
	} __attribute__ ((__packed__)) OptionalDescriptors[]; // +0x6 (a number of optional descriptors up to DescriptorCount)
} __attribute__ ((__packed__));

Code: Select all

OptionalDescriptors[0].Length // Accessing this is problem. I checked that DescriptorCount = 1
Whenever I try to access this field it throws alignment fault.

I checked @Ldb comments on alignment issues given here https://github.com/LdB-ECM/Raspberry-Pi ... usb.h#L601

Code: Select all

/*--------------------------------------------------------------------------}
{ 		 USB HID 1.11 descriptor structure as per manual in 6.2.1		    }
{--------------------------------------------------------------------------*/
struct __attribute__((__packed__)) HidDescriptor {
	struct UsbDescriptorHeader Header;								// +0x0 Length of this descriptor, +0x1 DEVICE descriptor type (enum DescriptorType)
	union {															// Place a union over BCD version .. alignment issues on ARM7/8
		struct __attribute__((__packed__, aligned(1))) {
			uint8_t HidVersionLo;									// Lo of BCD version
			uint8_t HidVersionHi;									// Hi of BCD version
		};
		uint16_t HidVersion;										// (bcd version) +0x2 
	};
	enum HidCountry {
		CountryNotSupported = 0,
		Arabic = 1,
		Belgian = 2,
		CanadianBilingual = 3,
		CanadianFrench = 4,
		CzechRepublic = 5,
		Danish = 6,
		Finnish = 7,
		French = 8,
		German = 9,
		Greek = 10,
		Hebrew = 11,
		Hungary = 12,
		International = 13,
		Italian = 14,
		Japan = 15,
		Korean = 16,
		LatinAmerican = 17,
		Dutch = 18,
		Norwegian = 19,
		Persian = 20,
		Poland = 21,
		Portuguese = 22,
		Russian = 23,
		Slovakian = 24,
		Spanish = 25,
		Swedish = 26,
		SwissFrench = 27,
		SwissGerman = 28,
		Switzerland = 29,
		Taiwan = 30,
		TurkishQ = 31,
		EnglishUk = 32,
		EnglishUs = 33,
		Yugoslavian = 34,
		TurkishF = 35,
	} Countrycode : 8;												// +0x4
	uint8_t DescriptorCount;										// +0x5
	enum usb_descriptor_type Type : 8;								// +0x6
	union {															// Place a union over length .. alignment issues on ARM7/8
		struct __attribute__((__packed__, aligned(1))) {
			uint8_t LengthLo;										// Lo of Length
			uint8_t LengthHi;										// Hi of Length
		};
		uint16_t Length;											// +0x7 
	};
};
There is some problem with HidDescriptor. I have tried @Ldb HidDescriptor which doesn't differ much from what given in CSUD still issue persists.



Any help is appreciated.
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Mon Apr 01, 2019 9:56 am

Surely you can see the problem the offsets are written

Code: Select all

struct {
		enum DescriptorType Type : 8; // +0x0
		u16 Length; // +0x1
} __attribute__ ((__packed__)) OptionalDescriptors[]; // +0x6 (a number of optional descriptors up to DescriptorCount)
Type is at +0x6
So Length is at +07 ..... so it's a 16bit value reading on an 8 byte offset so it is going to thrown an alignment fault

So either just tell the compiler it's a byte aligned struct

Code: Select all

struct __attribute__((__packed__, aligned(1))) {  /* Tell the compiler it's got a weird byte alignment */
		enum DescriptorType Type : 8; // +0x0
		u16 Length; // +0x1
}  OptionalDescriptors[];
Or do what I did put a union over the length and read the two bytes independently and shift and OR them back together.
That is what this was about and I even commented the alignment issue.

Code: Select all

union {   /* Place a union over length .. alignment issues on ARM7/8 */
		struct __attribute__((__packed__, aligned(1))) {
			uint8_t LengthLo;	// Lo of Length
			uint8_t LengthHi;	// Hi of Length
		};
		uint16_t Length;	// +0x7 
	};
So the length is simply ...... (LengthHi << 8) | LengthLo rather than reading the u16 aka Length
I probably should not have left Length there it would make it more obvious not to use it :-)

Anyhow your offending lines get alignment fixed by longhand writing it like so

Code: Select all

if ((reportDescriptor = MemoryAllocate(descriptor->OptionalDescriptors[0].LengthHi << 8 | descriptor->OptionalDescriptors[0].LengthLo)) == NULL) {
They will both translate to exactly the same thing, once the compiler works out the u16 is byte aligned it's going to read it as bytes and join them back up just like the manual longhand version

The reason I chose the long version is because CSUD only deals with array entry [0] but if you notice it is an array of 3 bytes so the alignment goes in and out along the array and I don't trust the compiler on the short form to get each array element right.

Chose one or the other but just don't read u16 off a byte alignment and problem solved.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 02, 2019 1:43 am

@Ldb thank you sir. This is the first time I got into real arm level alignment issue. While setting up paging and dma I could read the manual explicitly talking about aligned addresses.

This was the new learning. I am very close to completing CSUD. It was my dream to write/understand USB driver 😂.

@Ldb you and your experience in embedded keep inspiring me to continue my stupid os. Next is hardware accelerated graphics.

Thanks,

Prakash
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 02, 2019 1:18 pm

Yes the problem only comes up with things like the packed structures to meet a specification.

The lesson to drilled into yourself is the moment you deal with a packed struct record write the offset alongside each entry and check each base type is loading off it's natural alignment

uint16_t must be loading off 2 byte boundaries
uint32_t must be loading off 4 byte boundaries
uint64_t must be loading off 8 byte boundaries

If they are not read/write them using the longhand expansions

Aside from USB if you do a FAT32 or TTF fonts there are a couple in those as well.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 02, 2019 3:13 pm

Thanks I will keep this in mind.
Let there be some light .../\...

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Sat Apr 06, 2019 12:04 pm

@Ldb

I got keyboard working. I can read the characters and set leds

But I am facing some issue with mouse. It is detected and configured.

But when I try to read HIDReport host controller throws error like this:


Code: Select all

MOUSE: Mouse report index: 0 
1 Platform: malloc(8) = 23e78. (11320/32768)
Getting report from report type: 1 report id:0 interface:0 size: 4 buffer:23e78 
HCD: Stall error in transfer.
HCD: Control message to 40608: a1010001 00000400.
HCD: Request split completion to USB Mouse failed.
HCD: Could not send DATA to USB Mouse.
USBD:device->Error & ~Processing.
USBD: Verifying USB Mouse is still connected.
HUB: PORT STATUS OK for :4.
USBD: Yes, USB Mouse is still connected.
HID: Could not read USB Mouse report 147096
I have already checked that I am converting physical address to bus address by ORing 0xC0000000.
Any idea what could be the reason? I have check mouse attach function is called. I am not able to debug this.

Here is link to my code.
https://github.com/zeoneo/rpi3b-bare-me ... use.c#L166
Let there be some light .../\...

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Sun Apr 07, 2019 4:22 am

I tried use Circle USB library and it works.

Although this code doesn't work https://github.com/LdB-ECM/Raspberry-Pi ... m32_64_USB
for the same mouse.

I am still trying to find what's going wrong. Is it related split transactions?
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Sun Apr 07, 2019 5:59 am

yeah something on the split transaction let me have a look .. it was working .. played with something I shouldn't have :-)

StevoD
Posts: 28
Joined: Tue Aug 29, 2017 11:37 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Sun Apr 07, 2019 9:47 am

zeoneo wrote:
Sun Apr 07, 2019 4:22 am
I tried use Circle USB library and it works.

Although this code doesn't work https://github.com/LdB-ECM/Raspberry-Pi ... m32_64_USB
for the same mouse.
A lesson for those getting started, once you get beyond the basics those simple examples don't cut it.

Spend your precious time learning from the projects that have already done the hard yards to get it working properly.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Sun Apr 07, 2019 10:55 am

StevoD wrote:
Sun Apr 07, 2019 9:47 am
zeoneo wrote:
Sun Apr 07, 2019 4:22 am
I tried use Circle USB library and it works.

Although this code doesn't work https://github.com/LdB-ECM/Raspberry-Pi ... m32_64_USB
for the same mouse.
A lesson for those getting started, once you get beyond the basics those simple examples don't cut it.

Spend your precious time learning from the projects that have already done the hard yards to get it working properly.


Look it's not correct to say I am not spending time. Checkout code in CSUD repo(c) and circle(cpp). It's tough to correlate and debug. Host controller is throwing stall error in split transaction I tried logging everything I could. I am stuck that's why I asked @Ldb because he migrated the same code. I checked his code too. I have gone through all the docs. I am not able to find what is causing input request to stall.

Anyway thanks for encouraging me.
Let there be some light .../\...

StevoD
Posts: 28
Joined: Tue Aug 29, 2017 11:37 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Mon Apr 08, 2019 10:13 am

zeoneo wrote:
Sun Apr 07, 2019 10:55 am
Look it's not correct to say I am not spending time. Checkout code in CSUD repo(c) and circle(cpp). It's tough to correlate and debug. Host controller is throwing stall error in split transaction I tried logging everything I could. I am stuck that's why I asked @Ldb because he migrated the same code. I checked his code too. I have gone through all the docs. I am not able to find what is causing input request to stall.

Anyway thanks for encouraging me.
Wow, I think you took that the wrong way.

I was trying to save you from wasting time on examples that haven't proven they can do any more than the basics.

To be clearer, linux is a great reference, if it's too complex then circle, xinu, ultibo and a couple of others are good projects that have sorted out how to do stuff so you can learn from it.

CSUD, BakingPi, ldbecm, bztsrc, dwelch67 and so on are just examples and tutorials, they only show you an idea, don't be surprised if lots of other stuff doesn't work.

Anyway good luck!

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Mon Apr 08, 2019 12:00 pm

Thanks for clarifying. Indeed I mistook your thoughts. I am reading circle code to debug this issue.
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 1:34 am

Ok I assume you have an optical mouse from either MS or logitech because it took me a while to find a mouse that has the problem.

The issue looks like it is not the transmission at all it is the enumeration which obviously has not completed as far as the mouse is concerned and it hasn't brought it's config online so you can't get HID reports. That is why you can get all the config and interfaces from the mouse but not the reports. Underlining it is not a communication issue.

Xinu doesn't have any drivers for mice only keyboard and there is no support for it so that is a waste of time looking at that. So try circle if it can get reports out of the mouse just look at the HID enumeration sequence on circle.

I will have a look tonight but I am guessing it needs us to select a config rather than just relying on the default being active.

So it is basically the EnumerateHID function is reading all the config and interface but it does not set the HID config to use, on most device the default HID config is auto engaged but not these by looks.

Update:
Looking at circle HID enumeration
https://github.com/rsta2/circle/blob/3a ... bmouse.cpp
It basically does the same thing reads the HID configs and interfaces but then calls to HID Configure

Code: Select all

if (!CUSBHIDDevice::Configure ())   /* THIS IS WHAT IS MISSING on CSUD */
	{
		CLogger::Get ()->Write (FromUSBMouse, LogError, "Cannot configure HID device");

		return FALSE;
}
So it brings a HID configuration online manually ... that step that is missing in CSUD and my port of it assumes there is an active default HID interface. Look at the HID enumerate function all the reads are there but no set config function.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 6:04 am

Ohh great. I will add it in my code and check if it works. My focus was there is something wrong with split transaction implementation of CSUD. Clearly that is not the case as it is working for keyboard. Also while fetching device configuration for usb/kbd it uses split transaction and that step is working.

@Ldb good debugging skills. I was going through uspi(c version of circle). I could have taken a month to find this out. I will let you know after trying your fix.
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 1:32 pm

https://wiki.osdev.org/USB_Human_Interface_Devices

Should just require this which is all Circles HID config really does
"SetProtocol" request

Assuming a USB HID device supports the boot protocol, as explained in the section above, where is has a class value of 3 and a sub-class value of 1, the driver software can select the protocol to use. It uses the "SetProtocol" request to tell the device whether it wants to use the report protocol or the boot protocol. For simplicity's sake, this article will describe the boot protocol only, for now. To send the "SetProtocol" request, software sends a regular SETUP transaction to the device's control endpoint zero. The SETUP packet's request type would contain 0x21, the request code for "SetProtocol" is 0x0B, and the value field of the SETUP packet should contain 0 to indicate boot protocol, or 1 to indicate report protocol. The index and length fields both must be zero, as the index is unused and this request has no data stages. This command is only supported on device that support the boot protocol at all. After this command has been used, all reports sent from the device to the host will be either boot reports or regular reports, depending on the type the software requests.
So like circle you are going to need to either extend the HID record to include endpoints and read them or simply search for the first class 3 and if you find it then Set the protocol because it is one of these boot protocol mice. Reading and saving them is shown below

So currently the HID structure is

Code: Select all

struct HidDevice {
	struct HidDescriptor Descriptor[MaxHIDPerDevice];	// HID descriptor of this device
	uint8_t HIDInterface[MaxHIDPerDevice];				// The interface the HID descriptor is on
	uint8_t MaxHID ALIGN4;								// Maxiumum HID in array (usually less than the max array size) .. align it for ARM7/8
};
You will need to add endpoints descriptors and read them

Code: Select all

#define MaxEndPointPerHID 8    // Some max number of endpoints per HID
struct HidDevice {
	struct HidDescriptor Descriptor[MaxHIDPerDevice];	// HID descriptor of this device
	struct UsbEndpointDescriptor EndpointDesc [MaxEndPointPerHID];  // <<<<<< NEW and read them
	uint8_t HIDInterface[MaxHIDPerDevice];				// The interface the HID descriptor is on
	uint8_t MaxHID ALIGN4;								// Maxiumum HID in array (usually less than the max array size) .. align it for ARM7/8
};

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 5:06 pm

You meant problem here is the particular mouse I am trying get it working doesn't support REPORT protocol?

In circle keyboards and mice with

Code: Select all

 class= 3 and subclass == 1
are supported only in BOOT protocol mode.
https://github.com/rsta2/circle/blob/3a ... e.cpp#L113

Code: Select all

// Protocol IDs
#define BOOT_PROTOCOL		0x00
#define REPORT_PROTOCOL		0x01
While in CSUD hid devices are always reverted to use REPORT protocol. https://github.com/Chadderz121/csud/blo ... hid.c#L847

Doesn't all the keyboards, mice support REPORT mode?
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 6:09 pm

Yes but they won't communicate properly until they are fully enumerated.
The device is enumerated that is why you can talk to device but the HID has not finished enumeration it is like a device on a device.
No HID no HID reports !!!!!

There are steps required to enumerate you notice on the device you had to read configuration and descriptors which currently you never use and I simplified CSUD by throwing lots of them away. We did not read them for fun they are mandatory steps in enumerating the device.
In EnumerateDevice there are clearly marked enumeration steps 1..7 try not reading a device descriptor for example and watch what happens, you don't use the descriptor and it doesn't seem important but your device will never come online :-).

The optical mouse obviously has a more complex interface and it is wanting you to read all the endpoints etc (you can throw them away if you like .... but you must read them). Then do a set protocol and the HID enumeration will complete and it will come online.

On Circle rst is not reading all that junk for kicks it is because it is mandatory .. if it wasn't mandatory he would not bother reading them because he only ever uses the default.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 6:30 pm

Got it. I should first read all the descriptors mentioned in HID manual 1.11.

I am wondering how come keyboard is working in REPORT mode with the same code which is not reading all the descriptors and hence not fully enumerating device?

Btw I printed debug report for mouse mentioned here https://github.com/Chadderz121/csud/blo ... hid.c#L336

It looks like this:

Code: Select all

HID: Usage Page(1)
HID: Usage(2)
HID: Collection(1)
HID:  Usage(1)
HID:  Collection(0)
HID:   Usage Page(9)
HID:   Usage Minimum(1)
HID:   Usage Maximum(3)
HID:   Logical Minimum(0)
HID:   Logical Maximum(1)
HID:   Report Count(8)
HID:   Report Size(1)
HID:   Input(002)
HID:   Usage Page(1)
HID:   Usage(48)
HID:   Usage(49)
HID:   Usage(56)
HID:   Logical Minimum(-127)
HID:   Logical Maximum(127)
HID:   Report Size(8)
HID:   Report Count(3)
HID:   Input(006)
HID:  End Collection
HID: End Collection

But HID manual says otherwise

Code: Select all

0x05, 0x01,                    // USAGE_PAGE (Generic Desktop)
0x09, 0x02,                    // USAGE (Mouse)
0xa1, 0x01,                    // COLLECTION (Application)
0x09, 0x01,                    //   USAGE (Pointer)
0xa1, 0x00,                    //   COLLECTION (Physical)
0x05, 0x09,                    //     USAGE_PAGE (Button)
0x19, 0x01,                    //     USAGE_MINIMUM (Button 1)
0x29, 0x03,                    //     USAGE_MAXIMUM (Button 3)
0x15, 0x00,                    //     LOGICAL_MINIMUM (0)
0x25, 0x01,                    //     LOGICAL_MAXIMUM (1)
0x95, 0x03,                    //     REPORT_COUNT (3)
0x75, 0x01,                    //     REPORT_SIZE (1)
0x81, 0x02,                    //     INPUT (Data,Var,Abs)
0x95, 0x01,                    //     REPORT_COUNT (1)
0x75, 0x05,                    //     REPORT_SIZE (5)
0x81, 0x03,                    //     INPUT (Cnst,Var,Abs)
0x05, 0x01,                    //     USAGE_PAGE (Generic Desktop)
0x09, 0x30,                    //     USAGE (X)
0x09, 0x31,                    //     USAGE (Y)
0x15, 0x81,                    //     LOGICAL_MINIMUM (-127)
0x25, 0x7f,                    //     LOGICAL_MAXIMUM (127)
0x75, 0x08,                    //     REPORT_SIZE (8)
0x95, 0x02,                    //     REPORT_COUNT (2)
0x81, 0x06,                    //     INPUT (Data,Var,Rel)
0xc0,                          //   END_COLLECTION
0xc0                           // END_COLLECTION

Should it be same as mentioned in manual ?? Manual and every other web sources says its sample report.
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Tue Apr 09, 2019 11:30 pm

zeoneo wrote:
Tue Apr 09, 2019 6:30 pm
I am wondering how come keyboard is working in REPORT mode with the same code which is not reading all the descriptors and hence not fully enumerating device?
Remember a device is allowed to have multiple HID's on the single device and they will all queue up to be enumerated at endpoint 0 just like all the USB devices and Hubs. Enumeration is not just a word it is a STATE of the device and it goes from enumeration to CONFIGURED.

I have seen some devices just the act of setting the address will bring them into configuration mode but the only way to guarantee ALL devices is to do it by the book. So if you don't do the full proper enumeration by the specification some devices may complete enumeration some may not depending what the device internally wants. Your keyboard HID enumeration only requires a partial specification the mouse is playing hardball it is nothing more than that.

BTW CSUD has the same issue with some hard drives it doesn't read all the endpoint descriptors and they won't come out of enumeration mode and again we are talking about the STATE of the device not a process we are calling enumeration. If you have a USB hard drive around plug it in and see if CSUD enumerates it is like 50% chance it will, depends on the model.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Wed Apr 10, 2019 6:22 am

I checked mouse has only 1 configuration , 1 interface and only 1 endpoint (that should be endpoint 0).

I tried fetching interface descriptor and it was successful.
I tried fetching endpoint descriptor for endpoint 0 and again it resulted in stall error.


Here in circle code https://github.com/rsta2/circle/blob/ma ... e.cpp#L210
complete DEVICE_CONFIGURATION is read at once by using totalLength of configuration found earlier(using same get config descriptor)

and here https://github.com/rsta2/circle/blob/ma ... ce.cpp#L65
it is simply checking for report endpoint so that they can always query this endpoint for reports.

Now as you said I don't see any GET_ENDPOINT_DESCRIPTOR call to mouse. Endpoints are read by fetching full CONFIGURATION_DESCRIPTOR.

Although I noticed they circle has set_interface step in between that CSUD doesn't have.
Let there be some light .../\...

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Wed Apr 10, 2019 8:32 am

You need to be careful
https://docs.microsoft.com/en-us/window ... heir-pipes
Every USB device must provide at least one control endpoint at address 0 called the default endpoint or Endpoint0. This endpoint is bidirectional. that is, the host can send data to the endpoint and receive data from it within one transfer. The purpose of a control transfer is to enable the host to obtain device information, configure the device, or perform control operations that are unique to the device.
I am not sure that endpoint counts as 1 and I also am not sure that endpoint has to be guaranteed to be able to give you the HID reports check the standard. I have a feeling simple USB devices that use endpoint 0 report they have 0 endpoints and 0 interfaces you are reporting 1 endpoint.

Usually on a HID there is Interrupt IN endpoint ... that is the one the reports are guaranteed to be available on.

In USB terminology IN always refers to transfers to the host from a device so that is the one I can guarantee you the reports will be available on. You are allowed to poll interrupt endpoints so that is the one I would go for.

So do some checking in the full configuration is the Interrupt IN endpoint number 0 or something different. That alone may answer the question whether endpoint 0 counts as 1 endpoint but you can check the specification.

Anyhow I will have a chance to have a quick look in a few hours and see if I can help you out.

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Wed Apr 10, 2019 5:54 pm

You are correct. It's INTERRUPT IN type endpoint. This check is present in CSUD HID section.
Let there be some light .../\...

User avatar
Ultibo
Posts: 158
Joined: Wed Sep 30, 2015 10:29 am
Location: Australia
Contact: Website

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Thu Apr 11, 2019 12:30 am

zeoneo wrote:
Wed Apr 10, 2019 6:22 am
I checked mouse has only 1 configuration , 1 interface and only 1 endpoint (that should be endpoint 0).

I tried fetching interface descriptor and it was successful.
I tried fetching endpoint descriptor for endpoint 0 and again it resulted in stall error.


Here in circle code https://github.com/rsta2/circle/blob/ma ... e.cpp#L210
complete DEVICE_CONFIGURATION is read at once by using totalLength of configuration found earlier(using same get config descriptor)

and here https://github.com/rsta2/circle/blob/ma ... ce.cpp#L65
it is simply checking for report endpoint so that they can always query this endpoint for reports.

Now as you said I don't see any GET_ENDPOINT_DESCRIPTOR call to mouse. Endpoints are read by fetching full CONFIGURATION_DESCRIPTOR.

Although I noticed they circle has set_interface step in between that CSUD doesn't have.
I haven't read this thread line by line but from what I can see there is quite a bit of confusion, as far as I can see your current issue is that you get a stall error when trying to do split read from a USB mouse. Originally you seem to be getting the error while trying to read the HID report and now you are getting errors while reading descriptors etc.

Without seeing your code I can't really offer any specific input but I will say the following,

If you are doing a split transaction then the device must be either full speed or low speed, high speed devices don't require them. Split transactions require a lot of extra handling and precise timing in order to complete successfully so unless you are sure the code fully covers those cases you might need some serious debugging to work out the cause of the error.

A typical USB mouse will have 1 interface and 1 endpoint with that being an interrupt IN endpoint to receive the HID reports from the device. Normally that endpoint would be numbered endpoint 1 but for the purpose of reading descriptors, setting report protocol or other configuration then you normally always communicate with endpoint 0 which is the default control endpoint.

I'd recommend reading something like USB in a NutShell which covers a lot of the details of USB without the overhead of the full specification.
Ultibo.org | Make something amazing
https://ultibo.org

Threads, multi-core, OpenGL, Camera, FAT, NTFS, TCP/IP, USB and more in 3MB with 2 second boot!

LdB
Posts: 1177
Joined: Wed Dec 07, 2016 2:29 pm

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Thu Apr 11, 2019 2:24 am

AFAIK the reason for the stall from device for that last case was the descriptor asked for was invalid.
Ask for any valid descriptor and from what has been said the device will give it to you .. so can you confirm that zeoneo.
I believe we can confirm that you also have another low speed device (Kbd) and that is actually running so the low speed transfers work with at least one device as well as the HID on that low speed device.

The problem as far as I can still see is as it was the HID on one device won't communicate but the device itself will enumerate properly. I found an optical mouse that seemed to do that on CSUD, it enumerated and even gave up all it's vendor descriptor but the HID appeared down.

Have you actually tested circle does it actually work with the mouse .. no use looking at circle code if it doesn't :-)

I will have time tomorrow to look if you need a hand, or do you want to push thru and solve it yourself?

zeoneo
Posts: 62
Joined: Sun Sep 30, 2018 6:54 am

Re: Alignment issues in porting CSUD for RPI 3B (32 Bit) with minimal changes

Thu Apr 11, 2019 2:45 am

@Ldb

I have tested that mouse=1.5Mb/s using circle and USPI and it works using both libraries. But circle and USPI always set BOOT protocol and in CSUD we set REPORT protocol.

Also keyboard works just fine which supports speed of 1.5 Mb/s.

I am using USPI to debug this issue, I have checked it is fetching full configuration properly in CSUD when compared to USPI/CIRCLE.

What you have said is correct. Mouse is able to enumerate properly even it responds to set address, set config, set protocol properly. But when I request HID report it just stalls.

I will further compare USPI reportEndpoint/interface numbers and what CSUD is using to query hid report.
Let there be some light .../\...

Return to “Bare metal, Assembly language”