Describe the bug

• example cdc_msc_hid doesn't work when compiled with gcc 8.3.1 with -Os. It works with gcc v7 though

Set up (please complete the following information):

• OS: Ubuntu 18.04
• Board: stm32f407disco
• Firmware Code: examples/device/cdc_msc_hid

To Reproduce
compile with gcc 8.3.1

Expected behavior
usb device is not recognized

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-

1. Selecting Arduino from USB Stack with the help of arduino webusb library
2. Selecting TinyUSB from USB Stack with the help of Adafruit_TinyUSB_Arduino library

Now, 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.

Here is my question

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.

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):

• OS: Windows 7
• Board: stm32h743nucleo
• Firmware Code: examples/device/webusb_serial

To Reproduce
Steps to reproduce the behavior:

1. Obtain a machine running Windows 7.
2. Compile the webusb_serial example. In my case, I used: make -C examples/device/webusb_serial BOARD=stm32h743nucleo.
3. Wait for Windows as it attempts to load a drivers for each function,
4. WinUSB driver will fail to load for the WebUSB interface.

Expected behavior
Windows would find the magic "WinUSB" descriptors and automatically load the WinUSB driver.

Screenshots

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?

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 :)

Doesn't this not do anything since the len is 0? This is dropped if it's on EP0.

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
A clear and concise description of what you want to happen.

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.

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?

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

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.

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.

should be used with dfu-util

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 ?

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.

should mock/fake anything from DCD and below

I'm suspecting a wrong state of p_csw->status in some cases in this function :

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.

Spec:

• https://github.com/WICG/webusb
• https://wicg.github.io/webusb/#introduction

ref:

• https://github.com/webusb/arduino
• https://developers.google.com/web/fundamentals/native-hardware/build-for-webusb/

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
This new mcu share same usb controller with already ported lpc, it should be quick to get supported.

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

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 ?

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
A clear and concise description of what you want to happen.

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?

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.

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):

• OS: Windows 10 64-bit
• Board: Particle Xenon
• Firmware Code: Circuitpython master branch with tinyusb submodule at legacy-1076-g1ee9ef4f (I quickly inspected tinyusb master branch for relevant changes but didn't find any)

To Reproduce
Steps to reproduce the behavior:

1. Using a supported board with CircuitPython master branch, run https://github.com/CedarGroveStudios/Classic_MIDI_FeatherWing/blob/master/examples/ProgramChange_test.py (some additional support libraries are required, let me know if this poses a problem for your testing procedure and we can minimize it). The CircuitPython console will show the sent messages as it understood them.
2. On Windows, start "MidiTls", open the "MIDI input messages" window, and "Record"
3. Note that with the same or nearly same timestamp, there are two "Program Change" messages reported

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.

this include all host layers: HCD, USBH, and class driver

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

Description
A clear and concise description of what you want to happen.

Info https://docs.readthedocs.io/en/latest/getting_started.html

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.

#101

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):

• OS: Ubuntu 18.04
• Board: LPCXpresso54114
• Firmware Code: examples/device/hid_composite

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!

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.

https://arm-software.github.io/CMSIS_5/RTOS2/html/rtos_api2.html
Note: Will test with cmsis-rtos for freertos

unit test is obsolete, fix and include it in travis build

The README lists the following supported toolchains;

• lpcxpresso
• Keil MDK
• IAR Workbench

I'm guessing that GCC probably already works but isn't included in the list? What about clang?

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

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.

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'?

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.

Porting layer

• Device Controller Driver (DCD)
• Host Controller Driver (HCD)
• Board Supported Package (BSP)
• OS Abstraction Layer (OSAL)

It would be great to have a sample app/target that included tinyusb and mynewt on a NRF52840 (or STM32?)

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.

I'm trying to handle feature reports, but it doesn't look like that's implemented. Or am I missing something? Thank you!

Describe the bug
.data section is not placed in output .bin file.

Set up (please complete the following information):

• OS: Linux
• Board: metro_m0_express and metro_m4_express
• Firmware Code: any

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?

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.

see like:
https://github.com/conorpp/u2f-zero

low priority but wanted to put it down :)