[New version CH554 evaluation] --5.2, USB host routine learning and verification--code

yang_alex

[New version CH554 evaluation] --5.2, USB host routine learning and verification--code [Copy link]

Qinheng provides the following two code files for USB HOST application: 1. USBHOST.C: CH554 USB host control transmission function definition, mainly device enumeration part, control transmission part 2. USBHostHUB_KM.C: USB host application example, initialize and enumerate the devices connected to the USB port, support the first-level external HUB, can operate USB keyboard and mouse and HUB, printer, including HID class command processing First, create the project file yourself (refer to my previous evaluation post for the process), compile and burn. Well, everything is normal. First use a wireless mouse receiver to test, and it turns out that after the evaluation board is powered on first, the result is as shown below. Then connect the wireless mouse receiver to the USB female socket of the CH554 evaluation board, everything is normal, and the result is as shown below. When the evaluation board is powered on, unplug the wireless mouse receiver, and "USB dev out" will be output on the debug serial port. But if you first connect the wireless mouse receiver to the USB female socket of the CH554 evaluation board. It turns out that the D1 power indicator lights up before the evaluation board is powered on. When the evaluation board is powered on again, there is no output on the serial port. Even if it is reset or powered on again, there is no output on the serial port. After unplugging the wireless mouse receiver, there is no output on the serial port. But after the evaluation board is reset or powered on again, the serial port output is as follows (the same as when the evaluation board is powered on without the wireless mouse receiver). Try to insert a small-capacity USB disk for testing. After the evaluation board is powered on, connect the small-capacity USB disk to the USB female socket of the CH554 evaluation board, and it will be recognized normally. The result is as shown below. Change the USB keyboard test, after the evaluation board is powered on, connect the USB keyboard to the USB female socket of the CH554 evaluation board, the result is as shown below. Change the USB game remote control test, after the evaluation board is powered on, connect the USB game remote control to the USB female socket of the CH554 evaluation board, the result is as shown below. Analyze the information printed out by the serial port, and finally find the return error status code in USBHOST.H:

1. // Each subroutine returns a status code #define ERR_SUCCESS 0x00 // Operation successful #define ERR_USB_CONNECT 0x15 /* USB device connection event detected, connected*/ #define ERR_USB_DISCON 0x16 /* USB device disconnection event detected, disconnected*/ #define ERR_USB_BUF_OVER 0x17 /* USB transmitted data is incorrect or the buffer overflows due to too much data*/ #define ERR_USB_DISK_ERR 0x1F /* USB storage operation failed. The USB storage may not be supported during initialization. The disk may be damaged or disconnected during read and write operations*/ #define ERR_USB_TRANSFER 0x20 /* NAK/STALL and other more error codes are in 0x20~0x2F */ #define ERR_USB_UNSUPPORT 0xFB /*Unsupported USB device*/ #define ERR_USB_UNKNOWN 0xFE /*Device operation error*/

复制代码

#define ERR_USB_BUF_OVER 0x17 /* USB transmitted data is incorrect or the buffer overflows due to too much data*/ #define ERR_USB_TRANSFER 0x20 /* NAK/STALL and other error codes are in the range of 0x20~0x2F */ It can be seen that the evaluation board encountered problems in obtaining the device description and initializing the device. The debug serial port outputs error number 17. By tracing the output information of the debugging serial port (printing information multiple times to determine the error location), the problem is located in the CtrlGetDeviceDescr() function, and the following sentence: UsbDevEndp0Size = ( (PXUSB_DEV_DESCR)TxBuffer ) -> bMaxPacketSize0; // Endpoint 0 maximum packet length, this is a simplified processing, normally you should get the first 8 bytes first and then update UsbDevEndp0Size immediately before continuing

1. /*********************************************************************************** * Function Name : CtrlGetDeviceDescr * Description : Get device descriptor and return it in TxBuffer * Input : None * Output : None * Return : ERR_USB_BUF_OVER Descriptor length error ERR_SUCCESS Success Others *************************************************************************************/ UINT8 CtrlGetDeviceDescr( void ) { UINT8 s; UINT8 len; UsbDevEndp0Size = DEFAULT_ENDP0_SIZE; CopySetupReqPkg( SetupGetDevDescr ); s = HostCtrlTransfer( TxBuffer, (PUINT8)&len ); // Execute control transfer if ( s != ERR_SUCCESS ) { return( s ); } #if DE_PRINTF printf( "CtrlGetConfigDescr3\n" ); #endif UsbDevEndp0Size = ( (PXUSB_DEV_DESCR)TxBuffer ) -> bMaxPacketSize0; // Endpoint 0 maximum packet length, this is simplified processing,Normally, you should get the first 8 bytes first and then update UsbDevEndp0Size immediately before continuing if ( len < ( (PUSB_SETUP_REQ)SetupGetDevDescr ) -> wLengthL ) { return( ERR_USB_BUF_OVER ); // Descriptor length error } #if DE_PRINTF printf( "CtrlGetConfigDescr4\n" ); #endif return( ERR_SUCCESS ); }

复制代码

It can be seen that Qinheng's code is simplified and not processed according to the USB specification. So some unexpected situations will go wrong. The correct way should be as mentioned in the previous post: Note (6), (7), and (8) steps. The host first obtains the device descriptor of part of the slave device through address 0, obtains the maximum data packet length, and then resets the bus to notify the slave device to switch the communication address. Next, use the new address to obtain the complete device descriptor of the slave device. Please ask Qinheng's technical support to help modify the specific code. This content is created by EEWORLD forum user yang_alex, if you want to reprint or use it for commercial purposes, you must obtain the author's consent and indicate the source Analyze the information printed by the serial port, and finally find the error status code returned in USBHOST.H:

yang_alex

Please help me. Thank you! In addition, can the Qinheng USB analyzer check the communication between the microcontroller as the host and the slave (such as a USB mouse)? There are many softwares that can monitor the communication between the PC as the host and the slave, but there is no way to monitor the microcontroller as the host. Maybe this is the value of the Qinheng USB analyzer and network analyzer.

yang_alex

Another problem is that the receiver of my USB wireless mouse does not seem to be recognized as a mouse device or HID device, and the following code in the sample program cannot be executed. ———————————— This problem is solved, and the receiver of the USB wireless mouse is recognized as a composite device. But there is still a problem with the data. It seems to be the same problem as in the post.

沁恒USB单片机

1. The example provided is for operating the keyboard and mouse, and other devices need to be debugged specifically. Including composite devices, handles, etc. all need to be debugged specifically. If you need assistance, you can directly contact Qinheng's technical support at 025-89692393. 2. Qinheng's USB analyzer can obtain USB communication data between USB hosts and devices, and is not limited to the type of host or device, whether it is Windows, Linux, Mac or MCU. 3. In the above picture, the VCC and GND of the two USB ports P1 and P2 are connected, so after P1 is plugged into the USB, there will also be voltage on the P2 port.

yang_alex

Qinheng USB MCU published on 2018-5-29 09:17 1. The example provided is for operating the keyboard and mouse, and other devices need to be debugged specifically. Including composite devices, handles, etc., all need to be debugged specifically...

But when I connect the mouse or keyboard, there will be errors. Therefore, the current code is not robust enough.

SuiBianLiuLiu

The device descriptor is fixed at 18 bytes. The specification you mentioned is not a standard specification. A normal PC will also take fixed data. What is really useful is to take the configuration descriptor, first get the length, and then take the complete one. You can see it by looking at this function, so I can only say that you look at it very carefully but not carefully enough. Regarding the problem of not being recognized when plugging in first, if it does not print at all, it is very likely that your device is not standardized. When powered on, a high level is detected on D+ and enters BOOT. Examples are examples after all. It is impossible to identify all devices in the examples, but the enumeration problem should be solvable. If you only need to print the start information when plugging in first and cannot detect the device connection, you can add another detection method to detect whether D+ or D- has a high level to indicate whether the device is connected.

yang_alex

SuiBianLiuLiu posted on 2018-5-29 09:54 The device descriptor is fixed at 18 bytes. The specification you mentioned is not a standard specification. Normal PCs will also take fixed data. What is really useful is to get the configuration descriptor. First get...

I changed the wired USB mouse and wired USB keyboard and plugged them in, and the error message still appeared. After tracing and analyzing the code, it seems that an error occurred in the process of obtaining the device descriptor. You can try this program with several wired mice and keyboards.