hathach / tinyusb Goto Github PK
View Code? Open in Web Editor NEWAn open source cross-platform USB stack for embedded system
Home Page: https://www.tinyusb.org
License: MIT License
An open source cross-platform USB stack for embedded system
Home Page: https://www.tinyusb.org
License: MIT License
should mock/fake anything from DCD and below
Porting layer
The README lists the following supported toolchains;
I'm guessing that GCC probably already works but isn't included in the list? What about clang?
Porting layer
Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.
The nrf_drv_usbd_errata.h file included with your package has lots of clauses that contradict your project's MIT license, such as:
* 4. This software, with or without modification, must only be used with a
* Nordic Semiconductor ASA integrated circuit.
Can you use nrfx_usb_errata.h instead, which has a more permissive license?
Describe the bug
From what I can gather looking at the WebUSB example, running the example on Windows should associate the WebUSB interface with the WinUSB driver automatically and without user intervention. Windows fails to find a driver on my machine.
Set up (please complete the following information):
To Reproduce
Steps to reproduce the behavior:
webusb_serial
example. In my case, I used: make -C examples/device/webusb_serial BOARD=stm32h743nucleo
.Expected behavior
Windows would find the magic "WinUSB" descriptors and automatically load the WinUSB driver.
Additional context
On Windows 7, the CDC driver is not normally loaded automatically; I used the provided inf file, and loading the driver has been automatic ever since. Perhaps the same should be done for vendor devices as a workaround?
unit test is obsolete, fix and include it in travis build
Porting layer
Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.
Porting layer
Description
A clear and concise description of what you want to happen.
Porting layer
Describe the bug
When computing time intervals care must be taken with wrap around. Eg:
static inline void board_delay(uint32_t ms)
{
uint32_t start_ms = board_millis();
while( board_millis() < start_ms + ms) {}
}
If start_ms
is close to 0xffffffff
such that adding ms
wraps it around then the function will most likely return straightaway.
This is on atmel-samd; haven't tested yet on nrf. As described in adafruit/circuitpython#1681, a CDC-writing routing in CircuitPython (https://github.com/adafruit/circuitpython/blob/master/supervisor/shared/serial.c#L54) calls tud_cdc_connected()
to check whether it's OK to write to CDC. That routine returns true
if CDC was connected at one time but then disconnected. I used a USB data/power-only cable to check. The tud
CDC write routines never write anything, and so this routine never exits.
Can tud_cdc_connected()
test more accurately for a connection? Maybe the only way to check is to try to do a write? If that's true, the write routine could set a "not connected" flag that overrides the DTR check that tud_cdc_n_connected()
does.
Hi,
May I know by what time, xHCI driver will be available in tinyUSB?
Thanks for your code and looking for xHCI driver support for Bare Metal.
Thanks!
It would be great to have a sample app/target that included tinyusb and mynewt on a NRF52840 (or STM32?)
this include all host layers: HCD, USBH, and class driver
We are working on a project with Xilinx ZYNQ ZC706 board, which requires baremetal working with USB in the host mode (actually with FreeRTOS).
Unfortunately, the Xilinx baremetal USB drivers does not support the host mode. Moreover, this driver implements only up to the EHCI layer, however, we need the USB stack to communicate with HID devices.
Thus, we decided to port the TinyUSB project to ZYNQ 7000 series. As mentioned earlier, the plaform is a ZYNQ board; thus we modified TinyUSB code in initializations, etc. so that it becomes compatible with this board. We have also modified the timer and used the Xilinx general purpose timer for USB instead.
After we plug the USB, the board receives an interrupt (that is "port change detect bit flips"). Then the device is reset.
The problem we are facing right now is that when it attempts to read the descriptor of the device (by transfering the appropriate request), no interrupt is raised indicating a successful transfer. Hence, there is a timeout and the code hits an assert in line 217 of "usbh.c" file (in "usbh_control_xfer_subtask" function), stating that the transfer was not successful.
Could anyone help us with this issue? Thanks in advance for your response.
I'm trying to handle feature reports, but it doesn't look like that's implemented. Or am I missing something? Thank you!
Here is my question
should be used with dfu-util
Describe the bug
Enumeration doesn't show any issue, but the board didn't send any input report
Set up (please complete the following information):
Here is my question
i wanna refine my usb host stack now ,cause the cache refresh code is very violence ,so i was finding some elegant solution or data structure to solve this question ! do you have any ideas ?
The documentation says "you need to continuously and/or periodically call tud_task()/tuh_task() function." Exactly how often does it need to be called?
I'm trying to build a keyboard using an nrf52840 that is sometimes a USB keyboard and sometimes a BLE keyboard. A low idle power usage is very important. Looking at the code, it appears that tud_task is only reading items from a queue and processing them. I don't see any timeout processing in tud_task
. So the only way events could end up in the queue is from interrupt handlers.
Is it safe for my application to sleep indefinitely using __WFE
, then call tud_task
once after every wake up (due to an interrupt)? Could I just run tud_task
from the interrupt handlers?
When building circuitpython with arm-none-eabi-gcc 8.2.1 (arm toolchain 8-2018-q4), I get this fatal warning:
../../lib/tinyusb/src/class/msc/msc_device.c: In function 'proc_builtin_scsi':
../../lib/tinyusb/src/class/msc/msc_device.c:273:7: error: 'strncpy' output truncated before terminating nul copying 8 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy((char*) inquiry_rsp.vendor_id , CFG_TUD_MSC_VENDOR , sizeof(inquiry_rsp.vendor_id));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/tinyusb/src/class/msc/msc_device.c:274:7: error: 'strncpy' output truncated before terminating nul copying 16 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy((char*) inquiry_rsp.product_id , CFG_TUD_MSC_PRODUCT , sizeof(inquiry_rsp.product_id));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
I tried a few ways to fix it, first using memcpy()
and I think I remember that CFG_TUD_MSC_PRODUCT
and VENDOR
are not the same length as inquiry_rsp.product_id
and .vendor_id
correspondingly, which causes various issues.
Only gcc version 8 is catching this issue. We haven't moved up to gcc 8 yet, but we will sooner or later.
see like:
https://github.com/conorpp/u2f-zero
low priority but wanted to put it down :)
In CircuitPython, I got this while trying to debug adafruit/circuitpython#1686.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0002d6c4 in process_control_request (p_request=0x2003f2d0, rhport=0 '\000')
at ../../lib/tinyusb/src/device/usbd.c:407
407 TU_BREAKPOINT();
(gdb) bt
#0 0x0002d6c4 in process_control_request (p_request=0x2003f2d0, rhport=0 '\000')
at ../../lib/tinyusb/src/device/usbd.c:407
#1 tud_task () at ../../lib/tinyusb/src/device/usbd.c:245
#2 usb_background () at ../../supervisor/shared/usb/usb.c:78
[...]
(gdb) p *p_request
$2 = {{bmRequestType_bit = {recipient = 0 '\000', type = 0 '\000', direction = 1 '\001'},
bmRequestType = 128 '\200'}, bRequest = 0 '\000', wValue = 0, wIndex = 0, wLength = 2}
Does the p_request look completely unreasonable, or is there request there that should be handled or ignored? I believe the computer went to sleep and then this happened; I was out of the room.
Describe the bug
I'm attempting to use TinyUSB with an STM32F412ZG. dcd_stm32F4.c
uses the USB_OTG_GCCFG_VBUSBSEN
flag for usb power detection. However, it looks like the F412 has different names set up for the USB_OTG_GCCFG
register that stores this information; I had to replace this with USB_OTG_GCCFG_VBDEN
.
Should this be made conditional? It's the only incompatibility I've encountered thus far, and I'm not intimately familiar with why this name change exists between the F412 and other F4s like the F411.
Set up (please complete the following information):
Board: NUCLEO-F412ZG
MCU: STM32F412ZG
file: portable/st/stm32f4/dcd_stm32f4.c
To Reproduce
Occurs on build.
Expected behavior
../../lib/tinyusb/src/portable/st/stm32f4/dcd_stm32f4.c:163:24: error: 'USB_OTG_GCCFG_VBUSBSEN' undeclared (first use in this function); did you mean 'USB_OTG_GCCFG_VBDEN'?
I was wondering if bi-directional HID is already working and if you tested or have an example for raw HID?
It's a feature I'm desperately missing and the current state of the Arduino USB stack is really not helpful in implementing it, so I was hoping tinyusb might be finally the fix for the sad state of USB on Arduino :)
I'm suspecting a wrong state of p_csw->status in some cases in this function :
tinyusb/src/class/msc/msc_device.c
Line 317 in e4be6dd
This occurs when reading a sector after an another (unknown for now) msc query returns p_csw->status = MSC_CSW_STATUS_FAILED
Setting p_csw->status = MSC_CSW_STATUS_PASSED at the top of the function solved my issue.
I do not have to much time to do a proper PR nor tests for now, so I provide only the raw information. Maybe in a week or two.
Describe the bug
@CedarGroveStudios reported that in Circuitpython, Windows was having trouble receiving "program change" messages. In particular, "midi tools" sees a spurious Program Change 0 before a correct Program Change 33 using a test Python program. (different OSes seem to treat this differently, I didn't see the problem on Linux but did reproduce it on Windows 10)
Set up (please complete the following information):
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Only a single Program Change message should be recorded in each repetition.
Screenshots
Additional context
adafruit/circuitpython#2057
I have a fix for the problem, pull request incoming.
Porting layer
Description
A clear and concise description of what you want to happen.
tinyusb/src/portable/nordic/nrf5x/dcd_nrf5x.c
Line 281 in 0748980
Doesn't this not do anything since the len is 0? This is dropped if it's on EP0.
Hi Hathach,
We are trying to port TinyUSB stack with FreeRTOS on NIOS platform. We do have HAL driver of USB ready to be integrated with TInyUSB stack. We need information about which API are required to map with our HAL drivers. Do you have any porting guide?
Thanks,
Vasu.
finish custom device support
I'm working on a project that needs about 1.2 mb/s of bandwidth over USB in circuitpython which uses this USB layer. I am not very experienced with all the ins and outs of USB. I am fairly certain I can implement the bindings between circuit python and tinyusb.
As such it would be very nice if the custom_device support was finished
https://arm-software.github.io/CMSIS_5/RTOS2/html/rtos_api2.html
Note: Will test with cmsis-rtos for freertos
I need to be able to write to the USB vendor device when I know the FIFO has room for the data I'd like to send. "tud_cdc_write_available" is a great solution for the CDC device, I'd like something similar for vendor writes. If there is a different way to achieve this, I wasn't able to figure it out.
When building circuitpython with arm-none-eabi-gcc 7.3.1 doing:
make BOARD=metro_m0_express DEBUG=1
I get this fatal warning in tinyusb:
../../lib/tinyusb/src/portable/microchip/samd21/dcd_samd21.c: In function 'maybe_transfer_complete':
../../lib/tinyusb/src/portable/microchip/samd21/dcd_samd21.c:324:24: error: 'total_transfer_size' may be used uninitialized in this function [-Werror=maybe-uninitialized]
if (epnum == 0 && total_transfer_size == 0) {
~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
../../py/mkrules.mk:55: recipe for target 'build-metro_m0_express/lib/tinyusb/src/portable/microchip/samd21/dcd_samd21.o' failed
make: *** [build-metro_m0_express/lib/tinyusb/src/portable/microchip/samd21/dcd_samd21.o] Error 1
If DEBUG=1
is not set, it works fine.
A generic uf2 example that implement uf2 specs for reference. For simplicity, example doesn't do actual flashing, but only print out the addres + binary contents.
Porting layer
Description
A clear and concise description of what you want to happen.
Here is my question
when i test the usb host code with msc class ,and use the fatfs stack write data to the usb stick
when test write arbitrary size data the host controller seemed deal with the reclamation bit always 1
but the IOC not be triggered never
typical log is here:
f_write return code:1, 8865(espect size), 409(actual write size)
register status
USBCMD: 0x00000b21
USBSTS: 0x0000a088
USBINTER: 0x000c0026
FRINDEX: 0x00002a1f
CTRLDSSEGMENT: 0x00000000
PERIODICBASE: 0x04cfe000
TT_CONTROL: 0x00000000
CONFIGFLAG: 0x00000001
PORTSC: 0x88001205
qhd list print (error bit is marked with bold style):
--ASYNC Head
[QH Node] 0x0x4cfe120 -->
QH 0x0x4cfe120
DWord 0: QH Horizontal Pointer 0x0x4cfe220, Type 1 , T 0
DWord 1: RL 5, C 0, MaxPckLen 8, H 1, DTC 1, EPS 2, EndPt 0,I 0, DevAddr 0
DWord 2: Mult 1,PortNum 0, HubAddr 0, C-Mask 0, S-Mask 0
DWord 3: Cur qTD Pointer 0x0x4cfe160
qTD Overlay
DWord 0: Nxt qTD Pointer 0x0x0, T 1
DWord 1: Alt Nxt qTD Pointer 0x0x20, T 1
DWord 2: DT 0, Total bytes 0, IOC 1, C_Page 0, Cerr 3, PID 1,
active 0, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 1
DWord 3: Buffer 0: 0x0
DWord 4: Buffer 1: 0x1002
DWord 5: Buffer 2: 0x2002
DWord 6: Buffer 3: 0x3000
DWord 7: Buffer 4: 0x4000
@ Extra Info -
used 1,removing 0,pid 0,interval_ms 0,total_xferred_bytes_ms 0
p_qtd_list_head 0x0x0,p_qtd_list_tail 0x0x0
@ qtd list print -
[QH Node] 0x0x4cfe220 -->
QH 0x0x4cfe220
DWord 0: QH Horizontal Pointer 0x0x4cfe1e0, Type 1 , T 0
DWord 1: RL 5, C 0, MaxPckLen 512, H 0, DTC 0, EPS 2, EndPt 2,I 0, DevAddr 1
DWord 2: Mult 1,PortNum 0, HubAddr 0, C-Mask 0, S-Mask 0
DWord 3: Cur qTD Pointer 0x0x4cfe280
qTD Overlay
DWord 0: Nxt qTD Pointer 0x0x0, T 1
DWord 1: Alt Nxt qTD Pointer 0x0x4000020, T 1
DWord 2: DT 1, Total bytes 512, IOC 0, C_Page 0, Cerr 3, PID 0,
active 1, halted 0, buffer 1,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 0
DWord 3: Buffer 0: 0x9bc399
DWord 4: Buffer 1: 0x9bd010
DWord 5: Buffer 2: 0x9be018
DWord 6: Buffer 3: 0x9bf000
DWord 7: Buffer 4: 0x9c0000
@ Extra Info -
used 1,removing 0,pid 0,interval_ms 0,total_xferred_bytes_ms 10562
p_qtd_list_head 0x0x4cfe260,p_qtd_list_tail 0x0x4cfe280
@ qtd list print -
DWord 0: Nxt qTD Pointer 0x0x4cfe280, T 0
DWord 1: Alt Nxt qTD Pointer 0x0x1f0020, T 1
DWord 2: DT 0, Total bytes 0, IOC 0, C_Page 0, Cerr 3, PID 0,
active 0, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 0
DWord 3: Buffer 0: 0xa12048
DWord 4: Buffer 1: 0xa13000
DWord 5: Buffer 2: 0xa14000
DWord 6: Buffer 3: 0xa15000
DWord 7: Buffer 4: 0xa16000
DWord 0: Nxt qTD Pointer 0x0x0, T 1
DWord 1: Alt Nxt qTD Pointer 0x0x4000020, T 1
DWord 2: DT 0, Total bytes 1024, IOC 0, C_Page 0, Cerr 3, PID 0,
active 1, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 0
DWord 3: Buffer 0: 0x9bc199
DWord 4: Buffer 1: 0x9bd000
DWord 5: Buffer 2: 0x9be000
DWord 6: Buffer 3: 0x9bf000
DWord 7: Buffer 4: 0x9c0000
[QH Node] 0x0x4cfe1e0 -->
QH 0x0x4cfe1e0
DWord 0: QH Horizontal Pointer 0x0x4cfe180, Type 1 , T 0
DWord 1: RL 5, C 0, MaxPckLen 512, H 0, DTC 0, EPS 2, EndPt 1,I 0, DevAddr 1
DWord 2: Mult 1,PortNum 0, HubAddr 0, C-Mask 0, S-Mask 0
DWord 3: Cur qTD Pointer 0x0x4cfe2a0
qTD Overlay
DWord 0: Nxt qTD Pointer 0x0x0, T 1
DWord 1: Alt Nxt qTD Pointer 0x0xd0020, T 1
DWord 2: DT 0, Total bytes 13, IOC 1, C_Page 0, Cerr 3, PID 1,
active 1, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 0
DWord 3: Buffer 0: 0xa12048
DWord 4: Buffer 1: 0xa13010
DWord 5: Buffer 2: 0xa14018
DWord 6: Buffer 3: 0xa15000
DWord 7: Buffer 4: 0xa16000
@ Extra Info -
used 1,removing 0,pid 1,interval_ms 0,total_xferred_bytes_ms 0
p_qtd_list_head 0x0x4cfe2a0,p_qtd_list_tail 0x0x4cfe2a0
@ qtd list print -
DWord 0: Nxt qTD Pointer 0x0x0, T 1
DWord 1: Alt Nxt qTD Pointer 0x0xd0020, T 1
DWord 2: DT 0, Total bytes 13, IOC 1, C_Page 0, Cerr 3, PID 1,
active 1, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 0
DWord 3: Buffer 0: 0xa12048
DWord 4: Buffer 1: 0xa13000
DWord 5: Buffer 2: 0xa14000
DWord 6: Buffer 3: 0xa15000
DWord 7: Buffer 4: 0xa16000
[QH Node] 0x0x4cfe180 -->
QH 0x0x4cfe180
DWord 0: QH Horizontal Pointer 0x0x4cfe120, Type 1 , T 0
DWord 1: RL 5, C 0, MaxPckLen 64, H 0, DTC 1, EPS 2, EndPt 0,I 0, DevAddr 1
DWord 2: Mult 1,PortNum 0, HubAddr 0, C-Mask 0, S-Mask 0
DWord 3: Cur qTD Pointer 0x0x4cfe1c0
qTD Overlay
DWord 0: Nxt qTD Pointer 0x0x4cfe1c0, T 0
DWord 1: Alt Nxt qTD Pointer 0x0x10020, T 1
DWord 2: DT 0, Total bytes 0, IOC 1, C_Page 0, Cerr 3, PID 1,
active 0, halted 0, buffer 0,babble err 0, xact err 0, non-hs-missed_uframe 0, non hs split stat 0, Ping err 1
DWord 3: Buffer 0: 0xa12065
DWord 4: Buffer 1: 0xa13001
DWord 5: Buffer 2: 0xa1400b
DWord 6: Buffer 3: 0xa15000
DWord 7: Buffer 4: 0xa16000
@ Extra Info -
used 1,removing 0,pid 0,interval_ms 0,total_xferred_bytes_ms 0
p_qtd_list_head 0x0x0,p_qtd_list_tail 0x0x0
@ qtd list print -
[QH Node] 0x0x4cfe120 -->
--End
and I try to search some solutions on the internet ,but has no result
so i dont know its usb controller's quetion or the fatfs's qustion ????
have you ever met this ?
Describe the bug
.data
section is not placed in output .bin
file.
Set up (please complete the following information):
To Reproduce
Build either of the above boards.
Expected behavior
.data
section is expected to be in .bin
file, but is not.
The samd21g18a_flash.ld
(and 51) link scripts name the data section .relocate
yet examples/rules.mk
is using data
in the rule to create the .bin
. I guess these section names should be made to match each other?
Porting layer
Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.
Describe the bug
Set up (please complete the following information):
To Reproduce
compile with gcc 8.3.1
Expected behavior
usb device is not recognized
Porting layer
Description
I do not know when I'll get around to this, but I have an interest in using the crystal less USB feature of the STM32F0x2 family for future projects as, say, an cheap FPGA bootloader interface.
This is a Cortex-M0, and more importantly, the PHY provided is different from the Synopsys IP for other STM32 families. So no code duplication will be possible from STM32F4/F3/H7/etc. Thankfully, the PHY is also simpler and less featureful, so I think a port wouldn't take as long as it took me with the Synopsys PHYs.
I don't have a lot of experience with embedded devices and I am asking this question as a last resort after no replies on SO and Adafruit forum.
Recently I got a SAMD21 board to interact with browser via webusb in 2 ways-
Arduino
from USB Stack
with the help of arduino webusb libraryTinyUSB
from USB Stack
with the help of Adafruit_TinyUSB_Arduino libraryNow, arduino webusb doesn't support nRF52840 so far. However TinyUSB does.
NOTE: I don't have the supported boards for nR52840 , instead I have the latest Arduino Nano 33 BLE
So I was wondering how should I go about making my nRF52840 board communicate with browser?
The TinyUSB files don't make any sense to me right now. Nor can I make sense of running the webusb example. When I run make Makefile BOARD="feather_nrf52840_express"
it outputs -
make: Nothing to be done for 'Makefile'
.
I chose feather_nrf52840_express
as BOARD since the code isn't using any hardware pins so it doesn't matter if the board definitions are wrong. Just the internal core should be okay. But it doesn't work.
I tried another method too -
I ran the given webusb examples of Adafruit_TinyUSB_Arduino but they fail to upload on Nano 33 BLE.
I don't know much about why...perhaps its the mbed core it uses and you have a different core for nRF52 devices ? Or maybe the bootloader is different than what you expect ?
I don't necessarily want ready baked answers, I am willing to put in my time and effort. Just need some guidance and right direction on where should I look and what files should I write or will be helpful for this.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.