actually I am on the path of learning usb . so I want to make my own usb stack for stm32f4 mcu. But I got stuck at one point . actually the problem is my framework layer accept and recognise the control request and the request is get descriptor but the wlength is 64 bytes instead of 18(size of device descriptor). And also I transfer the data to in endpoint 0 but the usb host never send the in token after the setup stage completion instead the setup stage is called again and after windows show the prompt message not able to recognise the device
Please help me what is that I am missing in my framework
Related
I want to use the ESP-IDF framework to make a program that will recieve UDP packets via ethernet. I am not using an ESP32-Ethernet-Kit, but an ESP32 alongside a PHY (DP83848) in order to gain access to ethernet.
Pretty much every example I can find about UDP and ESP32 is using Wifi instead of ethernet.
What I want to do is use the basic ethernet example available in the espressif esp-idf git repository as a starting point and then add the functionality to recieve the datagrams.
If I'm not wrong, what I should do is create a new event handler and use the esp_eth_update_input_path API present in the esp_eth_driver.h, but I am not sure about how to use it. Can anyone help me with this?
esp_err_t esp_eth_update_input_path(
esp_eth_handle_t hdl,
esp_err_t (*stack_input)(esp_eth_handle_t hdl, uint8_t *buffer, uint32_t length, void *priv),
void *priv);
I posted almost the same question in the espressif ESP-IDF forum before posting this one here and got an following answer by user ESP_ondrej.
I'm posting it here in case this can help someone.
All protocols examples located in the ESP-IDF supports both Wifi and
Ethernet. You just need to configure it via idf.py menuconfig.
Please check the README at https://github.com/espressif/esp-idf/bl ...
/README.md
If you want to start from scratch with your Ethernet UDP application,
you can do so. You don't need to call esp_eth_update_input_path.
This function is used to direct L2 Ethernet frames to specific
callback function which you don't want since you want to communicate
via IP protocol. Therefore keep it as is, i.e. Ethernet frames are to
be processed by lwIP stack and just use socket API as you might be
used to from other platforms.
I am working on EndPoint Security. I was trying to control and block the USB storage device using the same. I used the event ES_EVENT_TYPE_AUTH_IOKIT_OPEN.
How can I get info about the device? for instance: Name Vendor Type etc...
Also when I just tried to block all the devices in the IOkit by just returning ES_AUTH_RESULT_DENY, still I was able to access the USB storage device after running the code in terminal. Could anyone guide and tell me what am I missing or where am I getting wrong?
I have started with an Atmel Start project:
My goal is to have a usb hub connected to this demo board:
SAM V71 Xplained Ultra Evaluation Kit
The problem is atmel doesn't supply a hub driver, and they haven't responded to our questions about this. So I have been attempting to write one based upon the msc and other drivers they do provide.
Currently I'm having an issue when I connect the USB hub. It is returning a STALL when I send a GET_DESCRIPTOR request with the type DEVICE. This seems odd to me because other USB devices such as a flash drive or USB to serial converter do not reply STALL to the same request. In fact the Flash drive goes through the entire enumeration process and msc installation so that I can successfully read and write to the drive.
I am detecting the stall via a single break point set in the STALL handling section of the pipe handler.
I have been reading the Universal Serial Bus
Specification Rev 2.0 but I can't find any differences between the way to read descriptors from hubs vs other devices. And I don't understand why a STALL would ever be sent in reply to a GET_DESCRIPTOR request.
Thanks
Just in case this is useful for anyone else. The issue I was having was apparently caused by the compiler optimization settings. Specifically I had change this setting to: "None (-O0)", after changing this back to the default I have had no problems enumerating USB devices. Picture of Optimization configuration
My colleague discovered this because of a seemingly unrelated problem which was causing Hard faults and Bus faults on the chip, these were also fixed by switching back to -O1. It seems -O0 needs to be used with a grain a salt or not at all on this chip.
This is a problem that I am trying to solve for years, periodically spending 1-2 months on it.
I am using Metrowerks IDE and ColdFire C compiler MCFCCompiler ver 4.0 to build the embedded code that uses the USB module for communication with the host. The product with this hardware has been out for eight years and pretty successful. However, along these years we were getting complaints from the field that occasionally the communication with the host hangs up and the operation is unrecoverable.
I tracked the bug down using USB sniffer and the Coldfire debug hardware and this is condition and the scenario that I find the code in.
The communication break is on the firmware side and not the driver on the host.
The hang-up happens only when sending USB firmware commands from host (windows 7) in rapid-fire from multiple threads. Every firmware command replies back to the host. So there's maximum traffic through the USB port.
I am using the implementation provided by Motorola that is well documented in USB-STAND-ALONE-DRIVER_V03.pdf (google will find it for you). There are two functions that are in my focus point and they should play nicely together: usb_in_service (called by the interrupt handler) and usb_tx_data (that initiates the transfer, which at some point will generate an interrupt).
The usb_tx_data function is implemented such that it bails out if the USB fifo still has data to send to the host. But waiting on the fifo to clear up takes the code into an infinite loop.
No more interrupt occurs after this although the USB module's registers content tells me the interrupts are enabled.
I checked that the USB module did not get reset event and is not suspended either.
The main question is whether the error is in the USB module hardware or in the code. I don't find any errata pointing to this problem. If it's the code, where is that whole in it that the logic is not accounting for?
The hot pursuit in on because we are making a new line of product based on this same firmware and I cannot release it until this is solved.
I am trying to communicate to my embedded(set-top box) device through this(http://numato.com/8-channel-usb-gpio-module) GPIO. Previously, when i attached this device to my set top box, then in dmesg, it is showing only that new usb device has been attached and by some hook/crook method, i manually created a node with major minor number of recently attached usb device and through my cross compiled c program, i tried to send gpio commands, which throws me the errors of invalid commands. After some more research, i get to know that on my set top box kernel, ACM CDC support is disabled. so i compiled the kernel again with CDC ACM support enabled and USB serial convertor support enabled. after flashing the kernel on BOX, now when i attached the device, in dmesg, it is showing that device is attached, New ACM device detected on ttyACM0, but no node is created in /dev, instead i found the device info in /sys/class/tty/ttyACM0. from here, i get the major and minor number of my device and manually created a node. after that i tried to communicate again, but now, instead of saying invalid command, my program is stuck on the first GPIO command and it is not executing any GPIO commands, but giving me the output of all the printf statements at application layer. please help.
Thanks in advance