#tinyusb

1 messages ยท Page 14 of 1

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #564 ESP32\-S2 disconnection detection issue

Set up

  • PC OS : Ubuntu 20.04
  • Board : Saola
  • Firmware: examples/device/cdc_msc_freertos

Describe the bug
ESP32-S2 currently doesn't detect disconnection event. Instead Suspend is detected as the side effect (since bus is idel > 3 ms). Worse, it detect suspend infinitely !!

To reproduce

  1. Run example with esp32s2 saola board with CFG_TUSB_DEBUG = 2
  2. Disconnect the usb connection while keeping the cp210x connection
  3. See error

Log
...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: group\-boards\-into\-family
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

I had an idea how to solve this issue! Not an overall solution but a step closer to it. If we would allocate all TX FIFOs not starting directly behind the RX FIFO but from the top (like heap and stack), the common RX buffer can always be extended at any time without problems! This comes in handy in case an ISO OUT EP is opened with a size bigger than 64 bytes (the current standard size of the RX FIFO) because now the RX FIFO can be extended immediately! The size of the RX buffer is thus not r...

fallow birchBOT
fallow birchBOT
#
ccattuto
[hathach/tinyusb] Issue opened: #565 Vendor device class: flushing bulk transfer endpoint packets ?

I wrote an application loosely based on the webusb-serial example, that transfer small packets of sensor data, ~10 packets/s, from a USB dongle (nrf52840-mdk) to the host computer via the vendor interface. Just like in the example, I simulate the CDC_REQUEST_SET_CONTROL_LINE_STATE (0x22) via controlTransfer() to activate or de-activate data transfer.

Possible problem. IF the following happens:

  1. I stop an ongoing data transfer ('request': 0x22, 'value': 0x00), release the interface, and ...
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I just tested usbtmc example (master branch) on a STM32F0, and it's enumerating and responding to "*IDN?" on Windows 10. As far as I know, I'm the only person who has used the class and I've only used it on a ST MCU.

I may order a SAMD21 (I've never used one before), and see if I can figure anything out if this issue doesn't get debugged soon.

The only "different" thing in the UBTMC class is that it uses an interrupt endpoint by default. You could try disabling it? Set `examples/devic...

fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I just tested usbtmc example (master branch) on a STM32F0, and it's enumerating and responding to "*IDN?" on Windows 10. As far as I know, I'm the only person who has used the class and I've only used it on a ST MCU.

I may order a SAMD21 (I've never used one before), and see if I can figure anything out if this issue doesn't get debugged soon.

The only "different" thing in the UBTMC class is that it uses an interrupt endpoint by default. You could try disabling it? Set `exampl...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

@PanRe hihi sorry for late response, I have taken a couple of days off and struggle to catch up with day work. This is a good idea, though I still don't quite understand its advantage. Since ISO are opened last, it is all come down to ISOs endpoints only with sub-space of FIFO. For only-one ISO config, there should be no problem at all with fragmentation.

PS: I really need to work on this asap, it has been on-pending for quite some time :(

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

The problem occurs if you want to open an OUT-EP bigger than the standard size of the RX FIFO. This can occur easily since maximum ISO size is 1023 byte for FS or 1024 byte for HS. The standard RX size is set lower than this value. So you need to extend its size at run time or you need to know this before you allocate the RX FIFO size. Knowing it before is not possible if you do not want to parse the descriptors.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

The problem occurs if you want to open an OUT-EP bigger than the standard size of the RX FIFO. This can occur easily since maximum ISO size is 1023 byte for FS or 1024 byte for HS. The standard RX size is set lower than this value. So you need to extend its size at run time or you need to know this before you allocate the RX FIFO size (when a new configuration is set up). Knowing it before is not possible if you do not want to parse the descriptors.

Yeah, you're spot on with out ISO, I am ...

fallow birchBOT
#
g-Mutlu
[hathach/tinyusb] Issue opened: #568 TinyUSB \(CDC\+MSC\) Keil STM32F0 Not Working

Hi Guys,

Used the example in the tinyusb folder for MSC. (tinyusb-master\examples\device\cdc_msc\src)
I can successfully run the same code in STM32CubeIDE. However, Keil didn't happen in Uvision5. Does not recognize the USB device. Can you help me?
Note: In STM32CubeIDE, the compiler uses GNUC.
I had to enable -gnu to compile it in keil.

image
Code:
[STM32F0_MASS_STORAGE_V0...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
czdpd
[hathach/tinyusb] Issue opened: #570 IAR internal error?

Hi,
I try to bring tinyUsb to my project using IAR EWARM(8.5). I added the source files, copied tusb_config.h and usb_descriptor.c from one of the examples. I expect to get a lot compiler errors and I'll work from there. But instead I got IAR internal errors like this:

Tool Internal Error:
Internal Error: [Front end]: assertion failed at: "layout.c", line 2909 in set_field_size_and_offset

I wonder if I missed anything, like compiler specific configuration etc? It appears this only h...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
henrix
[hathach/tinyusb] New comment on pull request #512: Fix a bug in writing SysEx messages\.

I'm still having issues when receiving more than 3 bytes at once with the MIDI class.
I'm using a STM32F746-Discovery board.

Example code for loopback:

uint32_t num_bytes = 0;
uint8_t buf[64] = {0};
if ((num_bytes = tud_midi_available())){
    tud_midi_read(buf, num_bytes);
    tud_midi_write(0, buf, num_bytes);
}

When sending a SysEx message from host with 4 bytes (i.e. {0xF0, 0x0, 0x1, 0xF7}), I receive:
{240, 0, 1, 0, 0, 0, 0, 0, 247}

Sending SysEx messages w...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
j4cbo
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Sorry for the delay here, I've been doing some rewriting of other parts of my firmware but I'm about to pick this up again. I'm also now building on top of FreeRTOS so I'm thinking more about avoiding blocking the whole USB stack.

I think putting the new code in net/ makes sense. @hathach , what do you think about renaming src/class/net/net_device.c to src/class/net/ecm_rndis.c and CFG_TUD_NET to CFG_TUD_NET_ECM_RNDIS? Then src/class/net/net_device.h would be split into two files...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #573: IAR build error fixes 
anย integral constant expressionย with a value greater or equal to zero. When greater than zero, this is the number of bits that this bit field will occupy. The value zero is only allowed for nameless bitfields and has special meaning: it specifies that the next bit field in the class definition will begin at an allocation unit's boundary.

I checked a bit further, and indeed it is part of the specs (not entire sure which specs version it belongs to). Yes, it is good idea to report ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #571: Fix IAR error on memcpy and warnings\.

@HiFiPhile ah, I know this warning, have been encountered it before. IAR is pretty smart about this. There is quite a lot of wr and rd idx passing to a function at same time. So yes, it makes sense to suppress the warning as you did here. We may come back later to "fix" it whenever having time. Please also put the warning message of Warning[Pa082]: undefined behavior: the order of volatile accesses is undefined in this statement so that we could know why we suppress the warning.

fallow birchBOT
fallow birchBOT
#
henrix
[hathach/tinyusb] Issue opened: #576 Incoming MIDI SysEx packets are mangled

Set up

  • PC OS : macOS 11.1 (Big Sur)
  • Board : STM32F746-Discovery board
  • Firmware: examples/device/midi_test

Describe the bug
When sending a MIDI SysEx packet from host with more than 3 bytes, mangled byte array with wrong number of bytes is received. Sending a MIDI SysEx packet with more than 3 bytes works fine though. MIDI SysEx is sent from Web MIDI application.

To reproduce
Example code for loopback:

uint32_t num_bytes = 0;
uint8_t buf[...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #569: add support for frdm\_kl25z

I struggled with the on-board openSDA of the KL25Z, out of all of my machines, it only enumerated with macOS (linux and windows is big no). Also I couldn't get it into BOOTLOADER mode to update to DAPLink as people suggest to fix the issue. Ended up with just solder the SWD and just external jlink for flashing. But that is not really an issue at all.

#
hathach
[hathach/tinyusb] Pull request review submitted: #569 add support for frdm\_kl25z

Amazing, excellent works !! I have tried it on my FRDM-KL25Z and it works perfectly with msc_cdc, cdc_dual_ports, hid_generic_inout, webusb_serial etc ... Other sram heavy example such as net_lwip_webserver aren't testable due to low SRAM on the KL25Z. Thank you very much for the PR.

PS: Since it break the ci, I will do a follow up that add the KL25Z to nxp_driver (just using the device/MKL25Z4 in your branch) and skip the build for large example

#
hathach
[hathach/tinyusb] New branch created: followup\-kl25z\-pr569
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

hihi @j4cbo sorry for late response, I were off for vacation the previously and is only doing catching up until now.

Sorry for the delay here, I've been doing some rewriting of other parts of my firmware but I'm about to pick this up again. I'm also now building on top of FreeRTOS so I'm thinking more about avoiding blocking the whole USB stack.

Not a problem at all.

I think putting the new code in net/ makes sense. @hathach , what do you think about renaming `src/class/net/net_...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New branch created: dcd\_synopsis\_mem\_allocation
#
PanRe
[hathach/tinyusb] Pull request opened: #581 Dcd synopsis mem allocation

Describe the PR
Implementation of #540.
TX FIFOs are now starting to allocate from the top, RX FIFO at the bottom of the available space (like heap and stack). As such, free space is between TX and RX allocations allowing the RX FIFO to grow in size dynamically which is needed in case an ISO OUT EP is opened which is greater than the standard RX FIFO size. Also, once such an OUT EP is closed, the RX FIFO size will be reduced once the RX FIFO is empty.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

This is minor, the comment regarding the // In FIFO is allocated by following rules: aren't true anymore. we should remove it. This is very minor, I could do it myself later on. Note: the reason for such as rules is I am trying to allocate more than epsize fifo for bullk endpoint e.g msc which will greatly improves its throughput. But yeah, it is not really good, maybe we should have some optional method for application to dictate the fifo size for synopsys later on in a separate PR.

#
hathach
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

this is such as great idea. Maybe we should have the formula as inline function, that take max_packet_size and return the rxsiz value, and use this function for the initial set in bus_reset() as well.

Note: it is minor, but I think we don't really need to have a min limit to 16 words, since the GRXFSIZ set by bus_reset() is already set a min for it. (64 for FS, 512 for HS).

// function name is terrible, you could name it anything else if that makes sense.
static inline uint16_t ...
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

True, i removed it!
If a bigger FIFO results in a higher throughput, what is the matter to define a bigger EP size anyway? I mean, why should i set an EP size lower than the FIFO size? As for the STM32, you can not write anything into the FIFO once it was scheduled to transmit. Only after the FIFO is empty you can put more into it... But i am not an expert here - it is easy to manipulate the sizes by additional settings. I recommend doing this when somebody really has the need/time to benchm...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

@PanRe the EP Size is USB specs's transaction size, each packet can only carry that much. For Fullspeed you can only have max of 64 bytes, but you could set the FIFO for it to larger value e.g 256. The screenshot probably help to explain it, the MSC Read a very large data e.g 4096 bytes, since this is FS the EP size is = 64.

  • when FIFO size = 64, hw will stop receive data and NAK until software stack (tinyusb) handle that fifo level full interrupt, which is mostly occurred at the end of ...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

Very interesting! Thx for the details! Well maybe we should already optimize the FIFO allocation a bit now before complains about performance comes up.
Since we do not parse the descriptors, there is now way of determining the optimal FIFO size. IMHO we need additional information from the user how much bigger the FIFO compared to the EP size should be!

How about introducing a factor ff_fact which determines the FIFO size compares to the EP size. There are various possibilities e.g.

  • ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

@PanRe don't worry about it for now, people haven't complained just yet. There is a few ways we could bypass the auto allocation like some specific macros as you mentioned, or having platform-dependent API, I didn't make up my mind just yet.

P.S.: Is it alway the case that BULK EPs work better the bigger their FIFO is? How about CTRL and INTERRUPT EPs? Do they also gain significantly from this? ISO does not since they are transmitted only once per frame.

Only Bulk and Control (asynch...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

Ok fine! I just thought that if we would find a way to solve the fragmentation problem with the TX FIFOs (as for now only the last opened IN EP can be closed) then we could also stepwise optimize the FIFO allocation! To solve the fragmentation problem we would need to find a way to reallocate active IN EP FIFOs at runtime. This could also be used for optimization. For example, lets say CTRL, INT, and ISO EPs get only the FIFO size equal to the EP size, so no problems with opening them. If a B...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: increase\-hid\-default\-epbuf
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: walkround\-samd21\-setup\-overflow
#
hathach
[hathach/tinyusb] Pull request opened: #586 walkround for samd21 setup\_packet overflow

Describe the PR
increase setup packet size from 8 to 12, since USB DMA controller is suspected to overflow the buffer with 2 extra bytes. Issue is discovered while troubleshooting https://github.com/adafruit/circuitpython/issues/3912 . This is considered a walkaround/hack rather than actual fix. It may probably overflow more than 4 bytes in the future, currently 4 bytes is too cheap fix consider the amount of work to trace it down so far. @dhalbert

fallow birchBOT
fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on pull request #586: walkround for samd21 setup\_packet overflow

In https://www.avrfreaks.net/forum/getting-extrange-data-enumeration-process-usb-uc3c?skey=multi_packet_size, someone asks about two extra bytes they are getting, and the reply is that those are the CRC bytes. This is for AVR, but it's a clue.

I think this may be the issue. From the data sheet, 32.6.2.7, page 799:

If data was successfully received, an ACK handshake is returned to the host if the endpoint is not
isochronous, and the number of received data bytes, excluding CRC, is writ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #586: walkround for samd21 setup\_packet overflow

The total number of bytes to be received must be written to
PCKSIZE.MULTI_PACKET_SIZE. This value must be a multiple of PCKSIZE.SIZE, otherwise excess
data may be written to SRAM locations used by other parts of the application.

Thanks @dhalbert, the CRC part does make lots of sense. In case of setup packet, MULTI_PACKET_SIZE = 8 which is not multiple of 64, I am not sure if this would be counted as this.

Also there is a scenario when scheduling the ZLP ACK, we have to also prepa...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #586: walkround for samd21 setup\_packet overflow

Do you think that MULTI_PACKET_SIZE=8 is wrong and it should be 64? I don't understand this well enough to comment.

I just poke at microchip driver, they use MULTI_PACKET_SIZE=8, so I think we are good, increase it has a greater chance for greater overflow I guess.

If you merge this, in whatever form, I'll make a PR for CircuitPython and then test this more thoroughly, including on WIndows 7, etc. Thanks.

merging now

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: followup\-pr581
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: use\-dcd\_event\_bus\_reset
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

I had some thoughts about how to solve the IN EP relocation problem and before i can start with that i would need to be sure about one USB framework behaviour:
If a host tells a device to open an EP (IN or OUT does not matter) and the device currently is not able to execute this request it responds with a NAK message. Some time later, the host will try again and resends its request. Is this correct so far? And further, does the host in the meantime handle remaining active EPs? If so, IN EP F...

fallow birchBOT
hard mesa
#

After some hiccups getting my Feather M0 back to Arduino, I was able to run the Keyboard HID example. To set the Device Descriptor, can I use TinyUSB, or do I need to build my own boot loader?

robust walrus
#

@hard mesa you shouldn't need to change the bootloader

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #581: Dcd synopsis mem allocation

Not quite like that, the host doesn't explicitly tell device to open endpoints, all Control-Bulk-Interrupt (CBI) must be opened after the SET_CONFIGURE request. EP needs to be opened/enabled in order to response with NAK, For ISO, since default ITF is almost always has no endpoint. Host will need to SET_INTERFACE to switch to appropriate profile (endpoint size) before communicating.

In short, all CBI must be opened with SET_CONFIGURE, if device failed to response to this request, host may ...

fallow birchBOT
hard mesa
#

Has anyone used TinyUSB with FreeRTOS on Arduino?

#

(Feather M0)

hard hinge
#

Is it possible to have WebUSB on NRF52840?

#

If yes, is there any plan to support WebUSB on NRF52840?

hard mesa
#

How does TinyUSB interact with SerialUSB on Feather M0? I notice that if I call Serial.begin() before calling USBDevice.setProductDescriptor(), then my device shows up as a "Feather M0," not as my device.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #590: Add support for Windows10 Command Prompt as a shell on GNU make\.

Hmm, the comment in line 5 is not good. I will update the comment.

The reason I am doing this is to detect whether POSIX-like shell (MSYS2/Cygwin) or cmd.exe. $(OS) is the same value, which is WIndows_NT, on these platforms.

MSYS2 and Cygwin work fine without this PR. So, We need to replace the path delimiter from slash to backslash only when using cmd.exe. I think if we use $(OS) for this PR, it will not work with MSYS2 and CYGWIN.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
robojan
[hathach/tinyusb] Issue opened: #592 USB communication stops working after handling a vendor control request on the ESP32s2

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Ubuntu 20.04
  • Board : ESP32-S2-Saola-1
  • Firmware: custom firmware with vendor control requests. I'm using the ESP-IDF, but I am not using the included tinyusb. Instead i have cloned this repo as a submodule.

Describe the bug
USB communication fails to work after an vendor control request has been handled.

To reproduce
On the ESP imple...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New branch created: edpt\_ISO\_xfer
#
PanRe
[hathach/tinyusb] Pull request opened: #593 Edpt iso xfer

Describe the PR
Implementation of a FIFO instead of a linear buffer to be used as ISO EP buffer as discussed in #504.

Additional context
This is an initial draft and not yet finalized. It works and uses the audio driver for testing. I added usbd_edpt_ISO_xfer() to schedule a transmission by use of a FIFO and implemented it for STM32 by adding dcd_edpt_ISO_xfer() in dcd_synopsis.c.
I further needed to enhance the functionality of tu_usb_fifo as:

  • add support for copying fro...
fallow birchBOT
#
nell-du
[hathach/tinyusb] New comment on issue #591: Can't get hid\_composite\_freertos to compile

can you clone this repo (tip of master) separated and compile the example with master of esp-idf. IDF changes structure a lot, and tinyusb copy can get out of sync. https://github.com/hathach/tinyusb/tree/master/examples/device/hid_composite_freertos

Thanks for your answer. I pulled the latest ESP-IDF again and checked out master (now on tip of master). Updated python modules. Checked out master of tinyusb (now on tip of master). The code compiles now.

Another questions though, I wou...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I believe the problem is in the usb_descriptors.c file. When I compare the example/device/cdc_msc/src/usb_descriptors.c file, there is a comment about SAMG:

#elif CFG_TUSB_MCU == OPT_MCU_SAMG
// SAMG doesn't support a same endpoint number with different direction IN and OUT
// e.g EP1 OUT & EP1 IN cannot exist together

SAMG and SAMD aren't the same, they are using different usb controller.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Great PR ! I'm also working on a USB-I2S bridge based on SAME70+iCE40 FPGA. For the moment FPGA part it's about ok and I'm waiting for SAM E70's dcd implementation. (I prefer STM32 but they need external phy, or too big package :( )

Thanks i am glad you like it!
What are you going to do with your I2S bridge? :) And why does STM's need an extra physical? Are there not models with HS PHY embedded or what do you need?

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: pico
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #598: RP2040 support

yeah go ahead - and i guess you are going to make the changes you suggested?

yeah, I will try to do as best as I could for tweaking the port after fixing the ci with decent testing (may be in the form of follow up PR). Would you mind accepting the contributor invitation so that I could request your review on any changes related to rp2040 port in the long run.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: pico\-followup
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: refactor\-bsp
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: pico\-followup
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #601 start the assimilation of Pi Pico into TU

hcd_edpt_xfer() calls get_dev_ep(), which may return NULL, and then unconditionally uses the return pointer. "assert" is used elsewhere in the rp2040 driver code and its use seems warranted here too.

Including "pico/stdlib.h" seems superfluous; there appear to be no issues with its removal.

By convention, TU drivers should implement the dcd_int_handler() API. Ensuring its presence allows users to let a fixed interrupt handler call the driver code.

Interloper macros were substituted...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #603 Pico followup

Describe the PR

  • Get CMakelists.txt to support both esp32s2 and rp2040 with -DFAMILY= along with -DBOARD=. Getting all of current examples compiled with rp2040.
  • *_freertos is skipped for rp2040 since I have no idea if freeRTOS could work with rp2040 atm
  • hid_generic_inout has issue, both hid_test.js/py couldn't send/receive data to rp2040. Not sure why, we will fix it in a separated PR.
  • net_lwip_webserver doesn't work with rp2040, again will troubleshoot and fix it lat...
fallow birchBOT
#
kamtom480
[hathach/tinyusb] Pull request opened: #604 Update Spresense SDK and fix dcd issues

Describe the PR
Update Spresense SDK to 2.0.2.
Define Spresense EP numbers that work with the cdc_msc example.
Fix issues that caused the DTR bit not to be changed to 1.

Additional context
Source code for mkspk has been added. This tool is used to create a .spk file.

Changes to dcd_cxd56:

  • Pass the next setup package when USB stack is ready to receive it.
  • When the transfer is 0 on EP0 send complete to the USB stack
  • Pass the data received after the setup package t...
#
hathach
[hathach/tinyusb] New branch created: add\-adafruit\-rp2040
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #603: Pico followup for \(ci\) building examples

Will you follow up with an int_handler change?

will do, I need to get ci running first and do hand-on testing with current state of the dcd first to see what works and what not. also to make sure when changing the dcd ports, there is nothing breaking. The dcd modification is on-the-way, just need a bit of testing.

wow - lots of great stuff going on here... a little bit overloaded but will try to take a look soon.

This PR is mostly refactor BSP build support for tinyusb example an...

fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I have my Segger JLINK Edu setup and have 2 microcontrollers: (1) Adafruit Trinket M0 (ATSAMD21E18) and (2) STM32 Blackpill (STM32F411CE). STM32 board is working. In "main.c" I tried commenting-out the "usbtmc_app_task_iter()" subroutine and STM32 was just fine (the app did not work but the operating system was fine with the USBTMC device attach). This makes me believe the problem is with either "tusb_init()" or "tud_task()".

Here is my make command for the SAMD21:
`make BOARD=trinket_m0 ...

fallow birchBOT
fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

Thanks for the feedback. I am cleaning the build directory before each new make command. When I try a make with the "LOGGER=rtt", program the part and reboot I am not seeing the device enumerate properly. Is this expected?
This is what I see when I am not using the logger:
[ 2900.059388] usb 1-1.1: new full-speed USB device number 97 using xhci_hcd
[ 2900.206578] usb 1-1.1: New USB device found, idVendor=cafe, idProduct=4000, bcdDevice= 1.00
[ 2900.206596] usb 1-1.1: New USB device string...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: upload\-binary\-artifacts
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #607 RP2040 hid\_generic\_inout does not work

Set up

  • PC OS : Ubuntu 20.04
  • Board : RPI Pico
  • Firmware: examples/device/hid_generic_inout

Describe the bug
Device doesn't seem to response to hid_test.py script

To reproduce
Run python3 hid_test.py in the example folder

python3 hid_test.py 
Openning HID device with VID = 0xCAFE
{'path': b'/dev/hidraw9', 'vendor_id': 51966, 'product_id': 16388, 'serial_number': '123456', 'release_number': 256, 'manufacturer_string': 'TinyUSB', 'produ...
#
hathach
[hathach/tinyusb] Issue opened: #609 RP2040 webusb\_serial example does not work

Set up
Set up

  • PC OS : Ubuntu 20.04
  • Board : RPI Pico
  • Firmware: examples/device/webusb_serial

Describe the bug
Device enumerated, landing URL appear on chrome, could connect via chrome. However, there seem to be issue when using along side with cdc serial. Further troubleshooting is needed.

To reproduce

  1. Click on landing page, click connect
  2. try to open terminal with cdc serial
  3. RP2040 stop responding
fallow birchBOT
fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I was able to see the RTT log using JLinkRTTViewer with the
-DSEGGER_RTT_MODE_DEFAULT=SEGGER_RTT_MODE_BLOCK_IF_FIFO_FULL option enabled.
The JLinkRTTLogger doesn't work at all.

Attached are the 2 log files from JLinkRTTViewer:
tinyusb_usbtmc_example_stm32f411ce.log
[tinyusb_usbtmc_example_atsamd21e18_2.log](https://github.com/hathach/tinyusb/files/5877833/tinyusb_usbtmc_example_atsamd21e18_2.l...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-followup2
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #610 Rp2040 followup2

Describe the PR
Follow up to update the dcd port of rp2040 as mentioned in the feedback issue

  • removed the assigned_address in dcd, which can be extracted from request
  • change panic in dcd_remote_wakeup to pico_info() with not supported yet message.
  • wrap rp2040_usb.c around CFG_TUSB_MCU == OPT_MCU_RP2040 since some auto build system such as arduino will include all the C file which cause compile error on other port (due to lack of pico-sdk etc ..)
  • dcd_int_handler() wra...
fallow birchBOT
fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

I dont know if this is usefull somehow, but webusb (and maybe other hid example) is causing that ubuntu usb driver stop responding/discovering devices at some point:

[ 4627.697667] usb 3-1: new full-speed USB device number 13 using xhci_hcd
[ 4627.875037] usb 3-1: New USB device found, idVendor=cafe, idProduct=4011, bcdDevice= 1.00
[ 4627.875041] usb 3-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 4627.875044] usb 3-1: Product: TinyUSB Device
[ 4627.875046] usb 3-1: ...
#
chegewara
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

@hathach an observation:

Interface Number: 1
		Name: cdc_acm
		Alternate Number: 0
		Class: 0a(data ) 
		Sub Class: 00
		Protocol: 00
		Number of Endpoints: 2

			Endpoint Address: 02
			Direction: out
			Attribute: 2
			Type: Bulk
			Max Packet Size: 64
			Interval: 0ms

			Endpoint Address: 82
			Direction: in
			Attribute: 2
			Type: Bulk
			Max Packet Size: 64
			Interval: 0ms

	Interface Number: 2
		Name: usbfs
		Alternate Number: 0
		Class: ff(vend.) 
		S...
fallow birchBOT
fallow birchBOT
#
fate100
[hathach/tinyusb] Issue opened: #611 Half of the data accepted by running uac2\_headset using esp32s2 is lost

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Ubuntu 18.04
  • Board : esp32s2_kaluga_1
  • Firmware: examples/device/uac2_headset_freertos

Describe the bug
I use FreeRTOS to port uac2_headset_freertos, but when I run it and play audio on the computer, I find that the audio data buffer returned by tud_audio_rx_done_cb is only half of the USB packet capture data. I tried to compare the two...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

I needed to remove the "00>" text from the tinyusb_usbtmc_example_atsamd21e18_2.log file so that it can be compared with the other log file. Here is the updated file.

The highlighted difference is the host assigning a different USB device address for each MCU. I don't think it's a significant difference.

The "interesting" part is the usbtmcd_open_cb 313: assert failed output in the atsamd log. Its DCD (device driver) doesn't like something about EP 0x81.

One conjecture is that t...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #558: USBTMC example not working on SAMD21/SAMD51

One conjecture is that this due to the wMaxPacketSize of 2 bytes. I'm having trouble deciding if this is legal or not for interrupt endpoints. Full-speed bulk endpoints are restricted to 8, 16, 32, or 64 byte max. High-speed bulk endpoints are restricted to 512 byte. My reading is that interrupt endpoints can be anywhere between 0 and 64 bytes for interrupt full-speed endpoints, so 2 should be legal.

You are right, any number from 0 to 64 is complaint to the specs. However, many MCUs l...

fallow birchBOT
#
pm-daniel
[hathach/tinyusb] New comment on issue #611: Half of the data accepted by running uac2\_headset using esp32s2 is lost

PC OS : Windows 10 2004
Board : NUCLEO-H743ZI2
Firmware: examples/device/uac2_headset
I've encountered a similar problem using tud_audio_rx_done_cb callback to send audio samples using SAI in DMA mode - everything ought to be correct but somehow half of the data is being corrupted, though I'm not sure if it's a bug or my poor understanding of how exactly this library works - both cases are possible.

fallow birchBOT
#
pm-daniel
[hathach/tinyusb] Issue opened: #613 STM32 uac2\_headset example SAI DMA data corruption

PC OS : Windows 10 Pro 2004
Board : NUCLEO-H743ZI2
Firmware: examples/device/uac2_headset

I'm having trouble using SAI in DMA mode to transmit received audio samples to external codec ic. It looks like half of the data is being somehow corrupted (for each ~1ms SAI transmission of correct data, there is ~1ms of silence). I'm attaching code snippets:
bool tud_audio_rx_done_cb callback when SAI transmission is being set up (DMA is not using circular buffer):
`bool tud_audio_rx_done_cb(u...

fallow birchBOT
fallow birchBOT
#
dhalbert
[hathach/tinyusb] Issue opened: #614 CFG\_TUD\_ENDPOINT0\_SIZE misspelled as CFG\_TUD\_ENDOINT0\_SIZE

This typo was partly fixed in #186, but the misspelling still exists in a couple of files.

test/test/device/usbd/test_usbd.c
212:  uint8_t zlp_desc_configuration[CFG_TUD_ENDOINT0_SIZE*2] =
215:    TUD_CONFIG_DESCRIPTOR(1, 0, 0, CFG_TUD_ENDOINT0_SIZE*2, TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP, 100),
225:                                         zlp_desc_configuration, CFG_TUD_ENDOINT0_SIZE, CFG_TUD_ENDOINT0_SIZE, true);
226:  dcd_event_xfer_complete(rhport, EDPT_CTRL_IN, CFG_TUD_ENDOINT0_...
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #615: fix \#558

I don't understand the "unit-test" build failure, but I think it's unrelated to the changes made here.

Perhaps we could rephrase the comment as:

// USBTMC Interrupt xfer always has length of 2, but we use epMaxSize=8 here for compatibility
// with microcontrollers that only allow 8, 16, 32 or 64 for FS endpoints

Either way, I'm happy with this patch.

fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on pull request #615: fix \#558

I don't understand the "unit-test" build failure, but I think it's unrelated to the changes made here.

Perhaps we could rephrase the comment as:

// USBTMC Interrupt xfer always has length of 2, but we use epMaxSize=8 here for compatibility
// with microcontrollers that only allow 8, 16, 32 or 64 for FS endpoints

Either way, I'm happy with this patch.

Thanks for the help. I replaced the previous comments with yours, and am still failing the unit-test....

fallow birchBOT
fallow birchBOT
#
charkster
[hathach/tinyusb] Issue opened: #616 hw/bsp/samd21 and hw/bsp/samd51 are missing "sam\.h"

In line 27 of tinyusb/hw/bsp/samd21/family.c the "sam.h" header file is included, but no where to be found.
Also line 27 of tinyusb/hw/bsp/samd51/family.c the "sam.h" header file is included, but no where to be found.

PS OS : Ubuntu 20.04, Raspberry Pi OS
Board: seeeduino xiao
Firmware: examples/device/usbtmc

I am unable to compile the usbtmc example because a header file is missing.

/home/pi/tinyusb/hw/bsp/samd21/family.c:27:10: fatal error: sam.h: No such file or directory
 ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-unittest\-ci
fallow birchBOT
#
charkster
[hathach/tinyusb] New comment on issue #616: hw/bsp/samd21 and hw/bsp/samd51 are missing "sam\.h"

Sorry about that. I missed the step of getting all the submodules. I just updated the submodules for all the hardware and am fine now.

Did the Raspberry Pi guys just recursively added all the libraries again under their own hardware?
/home/pi/tinyusb/hw/mcu/raspberrypi/pico-sdk/lib/tinyusb/hw/mcu/microchip
/home/pi/tinyusb/hw/mcu/raspberrypi/pico-sdk/lib/tinyusb/hw/mcu/sony/cxd56/spresense-exported-sdk

When I get all the submodules it is twice the size now.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
homeodor
[hathach/tinyusb] Pull request opened: #618 A CDC\-like blocking behaviour

This is basically a new try on what @kaysievers did in #359, with all the recent inner changes. It also has some functions rewritten in lieu of their CDC counterparts.

It might still cause issue #377, I haven't tested it this way, I don't have the hardware. However I'm pretty sure that I can feed loads of data into my SAMD21-based device and get 100% reliable transmission.

Two scenarios were tested, a ~6K worth of SysEx and complex lightshow data with thousands of notes, running at 500 ...

fallow birchBOT
fallow birchBOT
#
joshuag1000
[hathach/tinyusb] Issue opened: #619 Help Need \- Using media buttons

I am not sure if this is the right place to be asking this but here goes!
I am using the tinyusb library with my Raspberry pi pico. i have a button connected to the pico. When the button is pressed a subroutine is called which uses tud_hid_keyboard_report to press a key on the keyboard.
All is working fine, I can do key combinations type sentances etc.

But what i cannot work out is how to use/ press media keys. I would like my button to say for example pause my music when i press it. (...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #607: RP2040 hid\_generic\_inout does not work with external hub

@hathach, if you add an โ€œ#errorโ€ to ./src/portable/raspberrypi/rp2040/dcd_rp2040.c at about line 328 inside the #if TUD_OPT_RP2040_USB_DEVICE_ENUMERATION_FIX block, and then attempt a compile, it doesnโ€™t report the error. The โ€œrp2040_usb_device_enumeration_fixโ€ appears to be specifically for a problem with (some) USB hubs.

Ah, you are spot-on, seem like I did missed the macro, it probably only required for this chip version and will be fixed in future silicon, finding a way to insert the...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-logger\-enumfix
#
hathach
[hathach/tinyusb] New comment on issue #608: RP2040 net\_lwip\_webserver does not work

Hmm, for what it is worth, net_lwip_webserver for the raspberry_pi_pico target works on all PCs (Linux and Windows) that I have locally. (Ubuntu 20.04.1, Linux Mint 19, Linux Mint 17, Windows 7)

Ah thanks for testing it out, indeed, somehow my PC network configure only allow 1 ethernet connection at a time and I have to manual toggle the connection. Work fine when selecting the correct USB conneciton

![image](https://user-images.githubusercontent.com/249515/106423943-f4810b80-6493-11...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-consume\-control\-to\-hid\-composite\-example
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-adafruit\-esp32s2\-boards
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-picosdk\-1\.0\.1
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-adafruit\-samd51\-boards
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ndinsmore
[hathach/tinyusb] Issue opened: #628 RP2040 assertion "hw\_data\_offset\(next\_buffer\_ptr\) <= USB\_DPRAM\_MAX" failed:

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : macOS 10.15
  • Board : pi pico
  • Firmware: examples/device/usb/UAC2_headset modified to write square wave to mic see below
  • Using the tinyUSB master repo not the RPI repo
void fill_mic_buffer(int16_t num){
   static uint8_t wave_counter = 0;
   static int16_t wave_state = 20000;
   int16_t *dst = mic_buf;
   int16_t *limit = mic_bu...
fallow birchBOT
fallow birchBOT
#
maemoKKK
[hathach/tinyusb] Issue opened: #630 Compile ERROR ST32F103

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Ubuntu 18.04
  • Board : stm32f103bluepill
  • Firmware: examples/device/webusb_serial

Describe the bug
ace@ubuntu:~/tinyusb/examples/device/webusb_serial$ make BOARD=stm32f103bluepill all
CC system_stm32f1xx.o
In file included from /home/ace/tinyusb/lib/CMSIS_5/CMSIS/Core/Include/cmsis_compiler.h:54:0,
from /home/ace/tinyusb/lib/...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #629: TIVA C SUPPORT

I haven't tried to port this to TI Tiva mcu, in fact I haven't even worked with it so far. Though lots of people do, and willing to help you with the port. However, you need to do it in a more collaborating manner by submitting draft PR (zip doesn't help much with discussion). Here is my porting routines, please

  1. fork the repo
  2. add mcu low-level driver, bsp for Tiva
  3. make sure you got the board_test example running with led + button, when pressing button, the LED will blink faster...
#
hathach
[hathach/tinyusb] New comment on issue #630: Compile ERROR ST32F103

can you check and post your armgcc version here. Anyway, your armgcc is probably too old, try to install with xpacks

npm install --global xpm
xpm install --global @xpack-dev-tools/arm-none-eabi-gcc@latest

installation path is either $HOME/.local/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/*/.content/bin or ``$HOME/opt/xPacks/@xpack-dev-tools/arm-none-eabi-gcc/*/.content/bin`

or simply download it from arm

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

It might still cause issue #377, I haven't tested it this way, I don't have the hardware. However I'm pretty sure that I can feed loads of data into my SAMD21-based device and get 100% reliable transmission.

Thank you for your PR, issue 377 is the only reason 359 got reverted previously. It is necessary to re-test 377 for this PR to be merged. It should be reproducible with SAMD21/SAMD51 or just test with any mcu that you currently have.

fallow birchBOT
#
homeodor
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

All right, I could not make the example run on my hardware and could not be bothered to fix board definitions, so instead I tried the Blue Pill.

I tested a similar setup under macOS, which is my daily OS of choice, and saw no problems other than MIDI Monitor acting ever so slightly sluggish. I used Reason 10, and had a MIDI device within it loop back the data. However, under Windows, the #377 error persists. So I went on and tried by SAMD21 hardware with my original firmware, which ran per...

fallow birchBOT
#
kaysievers
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

The devices worked just fine with https://github.com/hathach/tinyusb/pull/359 and they still do. They work with any MIDI monitor/tool or musical software I tried on Windows.

MIDI-OX might just not work correctly. It is unmaintained and the last release is 10 years old. It seems strange to work around this, as it is the only piece of software which appears to have problems.

The simplest tool I could find for Windows is "Pocket MIDI", freely available from the Windows Store, and the examp...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kaysievers
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

if this is true

Old serial MIDI has a fixed speed, and no flow control, conceptually it is just "broadcasting" data in a fixed format. Many devices have only one one-directional port, and communicate only in a single direction.

The fixed speed makes it possible to avoid the concept of flow-control or client tracking. Transmitting devices just assume that the receiver is able to follow the entire stream of data it is interested in. It would usually not even know, if something, or how m...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

Thank you @homeodor and @kaysievers for following and testing the PR again. An proper testing with an additional pair of eyes is all this PR needed.

Nope, the MIDI example from TinyUSB: https://github.com/hathach/tinyusb/blob/master/examples/device/midi_test/src/main.c It has no reading function, and the overflow drove MIDI-OX crazy. I added lines (see above) that read out the buffer and it works fine.

Would you also update the PR with the midi read as well, I actually haven't worke...

fallow birchBOT
#
kaysievers
[hathach/tinyusb] New comment on pull request #618: A CDC\-like blocking behaviour for MIDI, incl\. SysEx

Would you also update the PR

Maybe you could add something like this to the dummy function as an explanation:

// The MIDI interface always creates input and output port/jack descriptors, regardless
// if both directions are actually used. The device will show up at the host as MIDI IN and
// MIDI OUT. Therefore incoming traffic should be read (possibly just discarded), to
// avoid the sender blocking in IO.
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release\-0\.8\.0
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.1
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.2
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.8\.0
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: test\-ci
fallow birchBOT
#
ndinsmore
[hathach/tinyusb] Issue opened: #635 Cannot get Audio to write out at full data sample rate

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : osx 10.15
  • Board : pi pico
  • Firmware: examples/device/uac2_audio_headset

Describe the bug
On the pico the callback to fill the transfer buffer are only getting called 200-500 times a second, if I try to up the data size the callback frequency goes down.
When sending data what controls the callback frequency?

fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.1
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.2
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.3
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.4
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.5
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.6
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.7
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.8
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.9
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.10
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.11
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.12
#
hathach
[hathach/tinyusb] New tag created: 0\.0\.13
fallow birchBOT
fallow birchBOT
#
TAGORE-git
[hathach/tinyusb] New comment on pull request #637: add basic support for rt\-thread

unsubscribe

On Sun, 7 Feb, 2021, 8:23 pm tfx2001, notifications@github.com wrote:

Describe the PR
Add a basic support for RT-Thread RTOS. More about the RT-Thread
https://www.rt-thread.io/.

Additional context
None.

You can view, comment on, or merge this pull request online at:

https://github.com/hathach/tinyusb/pull/637
Commit Summary

  • add basic support for rt-thread

File Changes

  • M src/osal/osal.h
    <h...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-gamepad
fallow birchBOT
#
tfx2001
[hathach/tinyusb] New comment on pull request #637: add basic support for rt\-thread

It is my mistake.

I'm a student developer in university, and I am still studying embedded development. Maybe add cdc_msc_rtthread example is a little hard for me. I'm concerned about overlooking support for other MCUs.

In fact, the RT-Thread team already provides a USB Device stack in RT-Thread, but not in RT-Thread Nano (the RTOS kernel of RT-Thread). I hope to provide more options for Chinese developers.

Thank you for your review.

#
hathach
[hathach/tinyusb] Pull request opened: #638 Add gamepad

Describe the PR
This PR mirrors modification from @nekuneko PR https://github.com/adafruit/Adafruit_TinyUSB_ArduinoCore/pull/20 . It add Dpad/Hat and Rx, Ry support for gamepad along with hid_gamepad_report_t and GAMEPAD_BUTTON/HAT enum for using with default gamepad template TUD_HID_REPORT_DESC_GAMEPAD() with following layout

int8_t X, Y, Z, Rz  (-127, 127)
int8_t Rx, Ry        (-127, 127)    
uint8_t  hat           (1, 8)
uint16_t button     (1, 16)

TODO: This...

#
hathach
[hathach/tinyusb] New comment on pull request #638: Add gamepad

PS4 Dual Shock Controller hid reporter

  • 1st stick is X, Y
  • 2nd stick is for Z and RZ
  • LT2 is both RY and trigger
  • RT2 is both RY and trigger
Usage Page (Desktop),               ; Generic desktop controls (01h)
Usage (Gamepad),                    ; Gamepad (05h, application collection)
Collection (Application),
    Report ID (1),
    Usage (X),                      ; X (30h, dynamic value)
    Usage (Y),                      ; Y (31h, dynamic value)
    Usage (Z),      ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on commit `72bcc06`

Yeah, thanks for the reminder, I do plan to sync up the Arduino core with this as well. the bm is for bitmask, since this is not really bitmask, therefore it got should have bm in the name. Though, most people will just probably use the enum value than the type anyway.

fallow birchBOT
fallow birchBOT
#
IrisMakes
[hathach/tinyusb] Issue opened: #639 MIDI Output On Other Channels Not Being Picked Up

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : Raspberry Pi Pico (RP2040)
  • Firmware: examples/device/midi_test

Describe the bug
When changing the channel used by tudi_midi_write24 in the midi_test example code, both MIDI-OX and Ableton Live don't detect anything on the channel. With channel 1, things work perfectly fine.
![image](https://user-images.githubusercontent.com...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-hid\-complete\-callback
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ipopov
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

I ran into the same problem and was able to diagnose it fully.

The problem is that when receiving a "standard" CLEAR_FEATURE request, usbd.c calls into the class driver:
https://github.com/hathach/tinyusb/blob/a96ee8f1d850bbd645040e0f5d133e6c1c93a3a4/src/device/usbd.c#L757. (The comment there says that the class must not call tud_control_status.)

Unfortunately the "class driver", i.e. the webusb example's main function, intereprets this as a "class" request with bRequest==1 (i.e. V...

fallow birchBOT
fallow birchBOT
#
ipopov
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

Hey there, Ha,

You're right that the driver working fine on other mcus suggests that the bug is deeper. On the other hand, it's possible that other MCUs ignore a spurious status report, whereas the RP2040 is programmed to panic.

In any case, I did what you requested. The stack trace of the panic is

(gdb) bt
#0  _exit (status=status@entry=1) at /home/pi/sdk2/src/rp2_common/pico_runtime/runtime.c:164
#1  0x10001a28 in panic (fmt=0x100088f0 "ep %d %s was already available")
    ...
fallow birchBOT
#
ipopov
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

I worked up this patch:
https://github.com/ipopov/tinyusb/commit/fd8add72e83a7df67dbaae9ec00a8a5eedfe26a3

which shows what I mean, and has allowed me to run the WebUSB Serial demo. However, sadly, it is based off of e0aa405d19e35dbf58cf502b8106455c1a3c2a5c, which is the original "RP2040 Support" commit, shipped with the Pico SDK; and that is based on a TinyUSB fork from November 2020.

I'm not really set up currently to build TinyUSB at head, sadly; so I cannot test whether the fix work...

fallow birchBOT
#
MimitechIndustries
[hathach/tinyusb] Issue opened: #643 Double Buffering

I started to integrate/use tinyusb into my STM32 project but noticed that there was no double buffering support. This might not be a deal breaker, but common sense would say that performance would be impacted significantly due to lack of double buffering support and my requirement is to be able to saturate most of the available bandwidth of the bus while keeping microcontroller utilization very low.

For now, I am going to switch to this stack https://github.com/xtoolbox/TeenyUSB which I...

fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on issue #643: Double Buffering

I was under the impression from looking at the source code that tinyusb stack in general isn't structured in a way to facilitate double buffering

Same. I was under the impression that tinyusb single buffers by design to keep the packet-handling, well, tiny :).

When I wrote the MSP430 backend, I explicitly used single buffering even tho the hardware supports double. I've not run int...

#
hathach
[hathach/tinyusb] New comment on issue #643: Double Buffering

I guess my question is -- do you mean you want to add f4 or h7, etc. to the title so that double buffering support is worked on for one specific mcu? I was thinking the feature request would be to bring double buffering support as a whole to tinyusb to any/all mcus that support it.

ah, I see, I thought you want to implement the hardware double buffering for some of the STM32 MCU, look like you want to have USBD-level double buffering. So far there isn't a need to do so, and we don't real...

#
MimitechIndustries
[hathach/tinyusb] New comment on issue #643: Double Buffering

OK sounds good ๐Ÿ‘

Also, one of the other things I noticed is that for full speed bulk, it sets the max packet size to 64 and seems to mandate the use of that value; however, in my case I send 44 byte packets since one frame of data for me is 44 bytes. When I send 44 bytes on a 64 MPS endpoint, the host USB on the other end doesn't ask for more data in a timely manner because it says "oh look you didn't even use your max allotted packet size so I guess I can stop bothering you for a bit" ...

fallow birchBOT
fallow birchBOT
#
ipopov
[hathach/tinyusb] Pull request opened: #645 Fix unintended control transfers in webserial example\.

As discussed in https://github.com/hathach/tinyusb/issues/609,

The problem is that when receiving a "standard" CLEAR_FEATURE request, usbd.c calls into the class driver:
https://github.com/hathach/tinyusb/blob/a96ee8f1d850bbd645040e0f5d133e6c1c93a3a4/src/device/usbd.c#L757. (The comment there says that the class must not call tud_control_status.)

Unfortunately the "class driver", i.e. the webusb example's main function, intereprets this as a "class" request with bRequest==1 (i.e. V...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #643: Double Buffering

@kkitayam thanks, I feel the same way as well, since most recent MCU all support DMA, the double buffering is mainly meant for raw bandwidth usage of the hardware. On software side, FIFO (byte copy or DMA) can be added according to the need of the class driver e.g cdc use normal fifo, audio will make use of DMA FIFO. Though, I am still open to discussion and all PRs.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #609: RP2040 webusb\_serial example does not work

Thank you for your log, it is very useful. It is indeed issue between how usbd and class driver agree up on. This seems to be added after webusb is already written and on other mcu, the duplicate ZLP has no effect or overwrite by the next setup packet. Therefore it doesn't bring up any attention to fix. Hmm, I think usbd should detect if tud_control_status() is invoked rather than trusting class driver for not calling it, especially it is vendor in user space.

The #645 is spot-on, I am pro...

fallow birchBOT
fallow birchBOT
#
MimitechIndustries
[hathach/tinyusb] New comment on issue #643: Double Buffering

Interesting, so 44 is technically not a supported value by the official USB spec -- glad Windows happily allows it though :) -- I'll have to test my application on other OSes more thoroughly since I intend on continuing to use 44 for my application. I think it's sort of a silly constraint especially when you consider how the USB protocol works (don't call us, we'll call you).

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: detect\-clear\-set\-ep\-status\-from\-class
#
hathach
[hathach/tinyusb] Pull request opened: #646 remove the requirement of std SET/CLEAR\_FEATURE must not return zlp status

Describe the PR
usbd should detect if tud_control_status() is invoked rather than trusting class driver for not calling it, especially it is vendor class in user space. This PRs use usbd_edpt_busy() to check if tud_control_status() is called by class driver and skip duplicate the action.

more context

The problem is that when receiving a "standard" CLEAR_FEATURE request, usbd.c calls into the class driver:
https://github.com/hathach/tinyusb/blob/a96ee8f1d850bbd645040e0f5d13...

#
hathach
[hathach/tinyusb] New branch created: correct\-fs\-bulk\-epsize
#
hathach
[hathach/tinyusb] New comment on issue #643: Double Buffering

@MimitechIndustries it is up to you to decide if it is worth the compatible should future OS enforce such as check. I have correct the bulk size check for FS endpoint but also leave it open for you by not enforce the 8,16,32,64 check since most people will go to 64 anyway. Should you have any further information regarding the bulk ep size please open an discussion or issue, we should keep this issue focused on "double buffering", thanks.
https://github.com/hathach/tinyusb/pull/647

#
hathach
[hathach/tinyusb] New branch created: rename\-dfu\-rt\-to\-runtime
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ActivePeter
[hathach/tinyusb] Issue opened: #649 the stm32h743iit6 has no response after init tinyusb, the jlink also lost connection

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board : stm32 h743
  • Firmware: examples/device/cdc_msc

Describe the bug
I'm trying to use the tinyusb on my own stm32h743 board, before using this lib, I already success to use the usb cdc provided by cubemx. When I'm using the tinyusb, it just has no reponse after running tusb_init(), the jlink also lost connection

`void basicInit...

fallow birchBOT
#
IrisMakes
[hathach/tinyusb] New comment on issue #639: MIDI Output On Other Channels Not Being Picked Up

Here's what I got from the log:

USBD Xfer Complete on EP 81 with 4 bytes
MIDI xfer callback
Queue EP 81 with 4 bytes ... OK
USBD Xfer Complete on EP 81 with 4 bytes
MIDI xfer callback
Queue EP 81 with 4 bytes ... OK
USBD Xfer Complete on EP 81 with 4 bytes
MIDI xfer callback
Queue EP 81 with 4 bytes ... OK
USBD Xfer Complete on EP 81 with 4 bytes
MIDI xfer callback
Queue EP 81 with 4 bytes ... OK

And then it kept repeating.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I did a complete redesign of the data handling part of the audio driver. It is decluttered now, meaning unnecessary stuff was removed and very important, the naming convection was changed such that it is easier to understand the driver structure. This way the users should understand the driver faster. I updated the examples to meet the new naming scheme.

What is missing is the implementation of dcd_edpt_iso_xfer() function for all dcd's other than STM32.

@hathach There are some CI tes...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rahmanshaber
[hathach/tinyusb] Issue opened: #652 Help Needed using this with ardinuo\.

I can't find any docs to use it with ardinuo, also the examples are not clear.
I just want to make a keyboard using the ESP32-s2 using the usb, but there is not an example so i can base my work on it.
Please help me out.

Also if it possible to simulate or do mouse and keyboard with one ESP32-S2? i can do it using the HID-Project with pro micro.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
robojan
[hathach/tinyusb] New comment on issue #592: USB communication stops working after handling a vendor control request on the ESP32s2

Hi, I just tried it again with the latest master branch. commit 09868434cd9f53394350cce682333ada97f796c3.
It still does not work, but now it seems that the asserts are enabled.

USBD Setup Received 80 06 01 03 03 04 05 00 
  Get Descriptor String[1]
  Queue EP 80 with 5 bytes ... OK
USBD Xfer Complete on EP 80 with 5 bytes
  Queue EP 00 with 0 bytes ... OK
USBD Xfer Complete on EP 00 with 0 bytes

USBD Setup Received 80 06 01 03 03 04 05 00 
  Get Descriptor String[1]
  Que...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] Pull request opened: #654 Add alternate bitfield padding option

Adds configuration option CFG_TUSB_ALT_BIT_PACKING_ALIGNMENT, which substitutes bitfield variable " : 0" padding syntax with an unused variable of size equal to the remaining number of bits.

This change is intended to resolve aligned access issues for some platforms.

The default behaviour is original if the option is not explicitly enabled. Consequently, this change should not affect existing applications.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] Issue opened: #656 make failing on cygwin

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Windows 10
  • Board :
  • Firmware: examples/device/cdc_msc

Describe the bug
Make fails to find the source files when fired from cygwin terminal.
CC board.o
arm-none-eabi-gcc.exe: error: /%localdir%/tinyusb/hw/bsp/board.c: No such file or directory
To reproduce
Steps to reproduce the behavior:

  1. Open cygwin terminal (with make installed)...
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #643: Double Buffering

As for the STM32F4 which has a hardware USB FIFO, there is not double buffering possible. Once the hardware FIFO was loaded and scheduled for transmit or receive, hardware buffer is locked and you can not load any more into it. IMHO double buffering is only necessary if you need linear buffers e.g. for signal processing etc. In any other case i would suggest a ring buffer like the tu_fifo, this buffer is also capable of being loaded/read from by DMA. Some functions supporting this are not mer...

fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on issue #656: make failing on cygwin

Thanks for the suggestion but unfortunately, the path you mentioned i.e. /cygdrive/c/Users/Pranjal/ , was causing trouble initially, so I aliased it to /c/Users/Pranjal. You're right that these are not the best paths to put into Makefile, I figured out the issue to be the $(TOP) in the top.mk. (The other makefiles that work use relative paths). Currently, I am able to build it under /home but was hoping if there could be a better solution.

Thanks

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #654 Add alternate bitfield padding option

Thanks for the PR, actually, the bitfield size = 0 is due to my laziness. Since you already counted the unused size, there is no need to introduce the new macro CFG_TUSB_ALT_BIT_PACKING_ALIGNMENT, we should just always use it which is more explicit (therefore more portable). Would you mind updating the PR accordingly.

PS: also it is better to use the TU_RESERVED instead of unused, it expands to unique token name. But it is optional.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #656: make failing on cygwin

Alright. Thanks. One more question @hathach , a little unrelated to this topic. Is it absolutely necessary to use the vendor provided drivers as a BSP if I m porting it to a new MCU?

You could use any board you have, I tend to go for common/popular one since that is easier for people to get and test.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
jocelynmass
[hathach/tinyusb] Issue opened: #659 Mynewt build issue

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : macOS 11.0.1
  • Board : -
  • Firmware: -

Describe the bug
Building tinyusb with mynewt will trig the following warning message:

* Warning: Multiple packages with same pkg.name=tinyusb in repo tinyusb; path1=/cionic-newt-dev/repos/tinyusb/hw/mcu/raspberrypi/pico-sdk/lib/tinyusb path2=/cionic-newt-dev/repos/tinyusb

The issue is coming from pi...

#
hathach
[hathach/tinyusb] New comment on issue #659: Mynewt build issue

yeah, I notice the issue as well. It is getting a bit complicated since pico-sdk include tinyusb as submodule, and tinyusb also include pico-sdk for building its example. It cross-includes, I don't understand the newt build system to have a sound suggestion. For a walkaround, you could just remove the repos/tinyusb/hw/mcu/raspberrypi/pico-sdk/lib/tinyusb as my newt example ci https://github.com/hathach/mynewt-tinyusb-example/blob/master/.github/workflows/build.yml#L48

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-typo\-midi\-write24
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: improve\-fifo
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #659: Mynewt build issue

thanks for updating, things getting a bit complicated since projects now depends on each other, making recursively submodule clone is out of control. Actually, tinyusb doesn't need any of the submodule, those are mainly for example building and testing. If you know newt have any flags to add to repsitory.yml for that, I will be happy to make changes.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on issue #656: make failing on cygwin

Thanks for this @kkitayam . It helped! I tried building it on WSL as suggested by @hathach , it seems to build. But I haven't tried flashing it using J-Link or OpenOCD + ICDI yet. Although I'm able to get that done using cygwin, I can try accessing the same project from WSL & Cygwin for both the things as a ad-hoc solution for now.

As far as command prompt is concerned, I tried installing make using choco pack manager, but the results were similar to that of cygwin. Can you please sugge...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ndinsmore
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I don't know if a FIFO is the right path for ISO, It seems like a double buffer type might actually be more suitable. When you read the specs for UAC2 and USB 2 there is a lot of talk about when data should be ready, and when processing can start on that data. If we could lock the processing loop to the start of frame, a double buffer would be perfect for that.

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I don't know if a FIFO is the right path for ISO, It seems like a double buffer type might actually be more suitable. When you read the specs for UAC2 and USB 2 there is a lot of talk about when data should be ready, and when processing can start on that data. If we could lock the processing loop to the start of frame, a double buffer would be perfect for that.

At a first glance you may be right but the devil is in the details! The FIFO has two distinct advantages over a double b...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on issue #656: make failing on cygwin

As far as command prompt is concerned, I tried installing make using choco pack manager, but the results were similar to that of cygwin.

I guess that your PATH environment variable has C:\cygwin64\bin for cygwin. The path for cygwin causes failure.
make for windows treats SHELL environment variable as special. Please refer to Choosing-the-Shell
To avoid the issue, would you specify SHELL=cmd.exe on argu...

fallow birchBOT
fallow birchBOT
#
chegewara
[hathach/tinyusb] Issue opened: #668 \[question\] on unmount callback

After unplug USB cable from PC i am getting this:

20:34:02.400 -> device unmounted
20:34:02.433 -> device unmounted
20:34:02.466 -> device unmounted
20:34:02.466 -> device unmounted
20:34:02.499 -> device unmounted
20:34:02.499 -> device unmounted
20:34:02.533 -> device unmounted
20:34:02.566 -> device unmounted
20:34:02.566 -> device unmounted
20:34:02.599 -> device unmounted
...
20:34:06.108 -> device unmounted
20:34:06.108 -> device unmounted
20:34:06.207 -> device unmou...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I am okay with creating a PR at https://github.com/hathach/ti_driver , although I'll need to figure out how shall I update the submodule in the tinyusb repo.

Regarding naming, yes you're right Tiva-C is a marketing name, but I'd suggest creating to separate families of devices : tm4c123xx & tm4c129xx, the reason being there are some changes in both the silicon, including register definitions. Also some parts under tm4c129xx family have USB chapters of their reference manuals un...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I am okay with creating a PR at https://github.com/hathach/ti_driver , although I'll need to figure out how shall I update the submodule in the tinyusb repo.

Once the PR to submodule is merged, you just simply pull the submodule, then git add in the tinyusb repo, it will get updated to the latest commit like you did with normal file.

Regarding naming, yes you're right Tiva-C is a marketing name, but I'd suggest creating to separate families of devices : tm4c123xx & tm4c129x...

#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach Yes the mention is weird. Also, their datasheets contain the register interface and bit definitions as well. There are no register definitions available in the open version : https://www.ti.com/lit/ds/symlink/tm4c129encpdt.pdf?ts=1613987608999&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTM4C129ENCPDT .

I think if the #if macro is fine, then we can name it tm4c* for now, and add the device specific implementation later. I'll get started on this.

fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #672 rp2040: correctly size variables to reduce RAM usage

The rp2040 driver maintains a ginormous (technical term) RAM array of struct to track endpoints, and the author liked to use a proprietary-to-rp2040 type called โ€œuintโ€ that translates to a uint32_t.

Since TinyUSBโ€™s dcd_edpt_xfer() only transfers in sizes of uint16_t, there is no reason to store FOUR variables of size uint32_t in the struct (of which there are 32 total in the array) when 16-bit more than suffices.

Fixing this yields 4 x 2 x 32 = 256 bytes, which may not matter to everyon...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-msc
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #674 Enhance Host MSC

Describe the PR

  • move and rename files
  • Support RT10xx EHCI
  • rename tuh_msc_scsi_inquiry() to tuh_msc_inquiry()
  • add rhport to hcd_init()
  • separate hcd_init from ehci
  • add tuh_msc_get_block_count(), tuh_msc_get_block_size()
  • rename tuh_msc_mounted_cb/tuh_msc_unmounted_cb to tuh_msc_mount_cb/tuh_msc_unmount_cb to match device stack naming
  • change tuh_msc_is_busy() to tuh_msc_ready()
  • add CFG_TUH_MSC_MAXLUN (default to 4) to hold lun capacities
  • add MSC read10 and write1...
fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #675 rp2040: use TU endpoint conventions and remove redundant variables

The rp2040 driver currently has 32 instances of three bytes (bool in, uint8_t num, uint8_t ep_addr), each of which collectively stores only one byte of information.

TinyUSB already has functions (tu_edpt_number() and tu_edpt_dir()) that perform the function of the โ€œnumโ€ and โ€œinโ€ above, and other device drivers use these.

Bringing the rp2040 into line with established TU code conventions improves readability, reduces overall code size, and saves on RAM usage.

fallow birchBOT
fallow birchBOT
#
mbruno-xmos
[hathach/tinyusb] Issue opened: #677 Number of audio input channels hardcoded in AUDIO\_MIC descriptor

https://github.com/hathach/tinyusb/blob/ac30211853e9f8948d03db871f839e93a75b1edd/src/device/usbd.h#L429

I have created a two channel USB audio microphone application. I have set CFG_TUD_AUDIO_N_CHANNELS_TX to two, but I needed to modify the referenced line to set _nchannelsphysical to CFG_TUD_AUDIO_N_CHANNELS_TX rather than to 0x01.

I am wondering if I should not have used TUD_AUDIO_MIC_DESCRIPTOR in my application, but rather created my own similar macro to define exactly the descripto...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach , I have created a PR to your ti_driver repo, to add the necessary supporting files for tm4c123xx family of devices. Once that gets merged. I expect the build shall go through fine.

It is merged already

Regarding it being ready, when can I say it is ready? When I've added the relevant USB Drivers or when the bare minimal builds pass?

When some of the examples is working as proof of concept, especially the cdc_msc example. Once it is running, it is ready for merging, an...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hid\-callback\-multiple\-instance
#
hathach
[hathach/tinyusb] Pull request opened: #678 add itf argument to hid API to support multiple instances

Describe the PR
Follow up to #524, this PR remove backward-compatible single ITF callback when CFG_TUD_HID=1. This makes it clearer for user to notice that stack support multiple instance of HID interfaces and simplify the #ifelse in application should it choose to enable multiple HID. Following API signature is changed and required updated in application.

  • tud_hid_descriptor_report_cb()
  • tud_hid_get_report_cb()
  • tud_hid_set_report_cb()
  • tud_hid_boot_mode_cb()
  • tud_hid_set_i...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
wk89463
[hathach/tinyusb] Issue opened: #679 CDC device read problem

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS : Ubuntu 20.04
  • Board : own
  • Firmware: examples/device/cdc_dual_ports

Describe the bug
The CDC device calls read to read the data sent by the host. The data read is not the latest, but the data of the previous frame.

fallow birchBOT
fallow birchBOT
#
wk89463
[hathach/tinyusb] New comment on issue #679: CDC device read problem

USBD init
CDC init
dcd_int
dcd_connect
dcd_int_enable
USBD Bus Reset

USBD Setup Received 80 06 00 01 00 00 40 00
Get Descriptor Device
Queue EP 80 with 18 bytes
USBD Xfer Complete on EP 80 with 18 bytes
Queue EP 00 with zlp Status
USBD Bus Reset

USBD Setup Received 00 05 2D 00 00 00 00 00
Set Address
dcd_set_address 45
USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received 80 06 00 01 00 00 12 00
Get Descriptor Device
Queue EP 80 with 18 bytes
U...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I need your help in one place, 2 FreeRTOS based builds are failing because of the following:

/home/runner/work/tinyusb/tinyusb/lib/FreeRTOS/FreeRTOS/Source/include/portable.h:52:11: fatal error: portmacro.h: No such file or directory
52 | #include "portmacro.h"

Can you please help me understand what's the dependency I'm missing?

Also, please tell me what flash tool shall I use, I have used OpenOCD to flash this board. How shall I be integrating it?

Thanks

fallow birchBOT
hallow totem
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #680: spresense: fix setup processed flag

@hathach I merged it. I hope that's not a problem.

Not a problem at all, you understand the dcd much better than me. Though looking through the chance, I think there is probably a better approach with dcd_edpt0_status_complete() some dcd make use of this for changing address after status complete and prepare the next setup https://github.com/hathach/tinyusb/blob/master/src/portable/microchip/samd/dcd_samd.c#L187, some doesn't need it therefore it is optional.

PS: There is another br...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
chegewara
[hathach/tinyusb] New comment on issue #185: CDC echo demo of cdc\_msc may truncate characters

Recently ive done 2 apps, which are doing exactly the same, working with S2 CDC. I have 2 different results thou.

  • terminal app in C code works perfectly fine and does exactly what i need,
  • another app is PyQt5, app looks nicely wit GUI, but i am having issues with transfer; i am sending 5 requests (1 byte each), and getting data after each request (1 - 4 bytes); sometimes i am getting correct data and sometimes its some garbage, but after refresh (send 5 write 1 byte, followed by 5 read)...
fallow birchBOT
#
wk89463
[hathach/tinyusb] New comment on issue #679: CDC device read problem

now cdc process is : device get data (dir: out) -> call cdcd_xfer_cb() -> in call cdcd_xfer_cb(), first copy data from epout_buf to rx_ff, but now in epout_buf there not have latest data, only after use _prep_out_transaction() epout_buf have the latest data. this make a problem, when I use read() to read FIFO, I always get the data of the previous frame instead of the latest one. this is my question, is there something wrong with my understanding of the cdc out data process๏ผŸmy mcu is our co...

#
wk89463
[hathach/tinyusb] New comment on issue #679: CDC device read problem

bool cdcd_xfer_cb(uint8_t rhport, uint8_t ep_addr, xfer_result_t result, uint32_t xferred_bytes)
{
(void) result;

uint8_t itf;
cdcd_interface_t* p_cdc;

// Received new data
if ( ep_addr == p_cdc->ep_out )
{
// TODO search for wanted char first for better performance
for(uint32_t i=0; i<xferred_bytes; i++)
{
tu_fifo_write(&p_cdc->rx_ff, &p_cdc->epout_buf[i]); // write data from epout_buf to rx_ff
}

// invoke receive callback (if ther...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #185: CDC echo demo of cdc\_msc may truncate characters

I unfortunately do not have a STM32F4 Discovery board to test with anymore- I accidentally fried it in late 2019/early 2020 :P!

no problems at all, I will pull out the board to test with later on.

thanks @chegewara, maybe enable the LOG=2 would give some inside info and/or using either software/hardware usb analyzer to capture which data is transferred on the bus would help as well. I don't do much of pyqt to be helpful here.

fallow birchBOT
fallow birchBOT
#
amitv87
[hathach/tinyusb] Issue opened: #681 Better way to handle CDC\_REQUEST\_SEND\_BREAK

Found few legacy apps on windows which try to send break requests and terminate the connection if request fails.

Meanwhile I have made a change in cdc_device.c to support CDC_REQUEST_SEND_BREAK by adding a new case as show in code snippet.

case CDC_REQUEST_SEND_BREAK:
  if (stage == CONTROL_STAGE_SETUP)
  {
    tud_control_status(rhport, request);
  }
  else if (stage == CONTROL_STAGE_ACK)
  {
    TU_LOG2("  Send Break\r\n");
    if ( tud_cdc_send_break_cb ) tud_cdc...
fallow birchBOT
#
amitv87
[hathach/tinyusb] New comment on issue #681: Better way to handle CDC\_REQUEST\_SEND\_BREAK

I have setup an rpi pico to behave as USB to UART bridge using CDC. This works perfectly fine in almost all scenarios.

I encountered the behaviour when I tried to flash a firmware using qflash on a quectel modem.
The tool works absolutely fine with ftdi, silabs, prolific etc.

Although the modem needs just the rx and tx uart lines, qflash blindly expects the break request to be acknowledged else it chooses c...

fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@kasjer I saw you wrote the device driver for the DA1469X. Could you do me a favour and test the this PR if it works with with MCU? It is about the dcd_edpt_iso_xfer() if it works. No hurry, if you have some time! Thanks in advance! :)

@PanRe I will try to squeeze it into my workflow.

fallow birchBOT
#
liamfraser
[hathach/tinyusb] New branch created: rp2040\_fix\_hcd\_init
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-host\-example
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

hihi @PanRe sorry for late response, I am focusing on rp2040 last week since Adafruit is about to manufacture them (paid work). Will definitely try to review this asap.

No worries, the only thing i really would like to know is this remaining issue why the code does not compile without errors. The problem is with
#if CFG_FIFO_MUTEX #define tu_fifo_mutex_t osal_mutex_t #endif
in the tusb_fifo.h. osal_mutex_t is unknown and thus an error emerges. To be honest, i do not kno...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #685: \[msp430\]: a way skip nanolib for MSP430

not all board will have an msp_exp430 in their name. Marketing people will prefer to have AI, Super, in the product name :smile: . @cr1901 we can do it simply by moving msp430 into its own family with shared `family.mk' e.g stm32f4 https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32f4 . Though I am too lazy to do that with a family with only 1 board :smile: . will wait until some people make PR for another msp430 .

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach I had a question related to one of the call backs that the driver makes to the stack, i.e. dcd_event_setup_received(0, setup, true); . It says whenever we receive a "SETUP" packet then it shall be called. My question is, what do we mean by SETUP packet here, just the SETUP packet as in figure 1, or the Data that follows the SETUP (i.e. Data packet in the SETUP stage) as in figure 2.

Figure 1:
![image](https://user-images.githubusercontent.com/52209005/109392798-232fbc00-794...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
duddie
[hathach/tinyusb] Pull request opened: #688 Fix Endpoint descriptor size for MIDI Device

Endpoint descriptor should be 9 bytes in length (not 7) and have two extra bytes at the end: bRefresh and bSynchAddress

According to MIDI USB specification 1.0 (6.2.1 Standard MS Bulk Data Endpoint Descriptor)

This is actual error before fix:

Endpoint Descriptor (Audio/MIDI 1.0):

0x07 bLength
0x05 bDescriptorType
*** ERROR: Invalid descriptor length 0x07
Hex dump:
0x07 0x05 0x81 0x02 0x40 0x00 0x00

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

Thank you @PanRe for another great PR. This is too big for me to do a full review in one round. I will try to do break it into a few round, hopefully it doesn't cause any inconvenience.

I have go through the overall PR (not into too much of the detail). To be honest I don't really like to have fifo invoked in the DCD layer API, it will complicate the port for smaller mcu. Also this cause the fifo to be a bit too complicated.

It may be me not familiar with audio application. However, I...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Hathach, you could have told me this a very long time ago that you don't want the dcd to be changed. I asked about this idea in september last year #504. And this PR was a long time open with exactly this change...
If i understand you right, you want all of the fifo logic cut out of the audio driver am i correct? Well IMHO, this will lead to asynchronous problems and users will ask why its not working occsionally. If somebody has problems with the performance, he can change it anyway easily....

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-lpc55
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Hathach, you could have told me this a very long time ago that you don't want the dcd to be changed. I asked about this idea in september last year #504. And this PR was a long time open with exactly this change...

I apologize for this, I probably got distracted by other works and didn't follow this as closely as I could. In #504, I paid too much attention to the fifo rework for DMA.

If i understand you right, you want all of the fifo logic cut out of the audio driver am i correct? ...

#
hathach
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

I take back my own words after revisiting #504 . If we could, we should get rid of the middleman EP buffer on appropriate MCU. Samples -> FIFO -> EP buffer -> USB FIFO . dcd_edpt_xfer_fifo() would be an nice (optional) addition to current dcd. Other driver e.g CDC that also use fifo can make use of this API on appropriate MCU as well. We will do more polished work as follow up PR later on. There is only 1 request for change is to rename the API (ubsd/dcd) from edpt_iso_xfer() to `edpt_...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

instead of setting copy_mode, I think it would be better to have an dedicated API for read_n() write_n() for this mode e.g
tu_fifo_read_n_const_addr(), tu_fifo_write_n_const_addr() ( you can name it differently). That way we don't have to mange the mode internally. It also make the usage more explicitly (const address) where it is called.

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I pushed my latest polished version, which i came up yesterday. It bootstraps the audio driver and clarifies a lot of names with the intent to make it easier to understand the purpose of all the buffers and so on.

I know this PR is getting bigger and bigger ^^ To be honest, it was not my intention to flood you with code. It just came out, that the iso_transfere with the FIFO support became more complicated due to these copy modes (which i was not thinking of at the time of starting this pr...

fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe about DA1469x changes.
I'm afraid it will not work as intended here is why.
Unlike other MCUs USB controller does not have large enough FIFO to send or receive ISO packet greater then 64 bytes.
To make it work data needs to be read from the hardware FIFO during packet transmission and not after it was received like is usually the case. More over if DMA is not used to read whole packet it is very likely that interrupt handling will not be fast enough to process incoming data.
It was...

#
hathach
[hathach/tinyusb] New branch created: submodule\-on\-the\-fly
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I pushed my latest polished version, which i came up yesterday. It bootstraps the audio driver and clarifies a lot of names with the intent to make it easier to understand the purpose of all the buffers and so on.

I know this PR is getting bigger and bigger ^^ To be honest, it was not my intention to flood you with code. It just came out, that the iso_transfere with the FIFO support became more complicated due to these copy modes (which i was not thinking of at the time of starting this pr...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Within dcd_edpt_iso_xfer() the copy mode is set

if (dir == TUSB_DIR_IN)
{
  tu_fifo_set_copy_mode_write(ff, TU_FIFO_COPY_CST);
}
else
{
  tu_fifo_set_copy_mode_read(ff, TU_FIFO_COPY_CST);
}

But anyway, it would not solve the problem you described with the 64 bytes. The FIFO is capable of handling DMA transferes, however, its write or read pointers would need be updated in between a write/read if a wrap to the start of the FIFO buffer would occur. This needs to be handled ...

#
kasjer
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

I've made the mistake because of lines

buf8 = buf8 + (n - f->depth) * f->item_size;
...
_ff_push_n(f, buf8, n, wRel);

that suggests that source address (in my case register) can be modified,
and I just assumed that _ff_push_n works as it used to.
but in this case changing address of register also seems suspicious (I did not dig deep enough
to see if this will never happen).

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Today I tested your code (with change to access rx fifo as byte only) and It was not working for unknown reason I will let you know what come out of it tomorrow. I don't know if it was due to timing or some other small detail yet.
One more thing that may affect interrupt latency is that DA146xx chips don't have internal flash. It is all using external SPI flash in XIP mode. So when code is in cache it may work if it needs to be read it may be too slow and DMA would not be affected. Anyway I ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I pushed my latest polished version, which i came up yesterday. It bootstraps the audio driver and clarifies a lot of names with the intent to make it easier to understand the purpose of all the buffers and so on.

I know this PR is getting bigger and bigger ^^ To be honest, it was not my intention to flood you with code. It just came out, that the iso_transfere with the FIFO support became more complicated due to these copy modes (which i was not thinking of at the time of starting t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-rp2040\-host\-build
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach , There seems to be a serious problem in this MCU's silicon. I went on debugging trying to understand why a specific address is having spurious values even after initialization. The situation is as follows :

  1. I have two exactly identical board with same part number.
  2. The address at fault is 0x20002784 which shall contain the address of _usbd_q as confirmed by the map file below:
    ![image](https://user-images.githubusercontent.com/52209005/109637530-ea295e80-7b72-11eb-9102-...
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I tested some more just to be sure.
With default 32MHz clock interrupts are not able handle incoming ISO traffic while current DMA version works ok.
When switched to 96MHz sometimes interrupts seemed to have just enough time but not always (maybe if code
is cached it is fast enough). But on the whole I was not able to have forking stream without DMA when packet size
is above 64 bytes (size of hardware FIFO size).
There is one more problem. If data is streamed directly to TinyUSB F...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

This comment is just for DA146xx driver.
@PanRe I tested some more just to be sure. (
With default 32MHz clock interrupts are not able handle incoming ISO traffic while current DMA version works ok.
When switched to 96MHz sometimes interrupts seemed to have just enough time but not always (maybe if code
is cached it is fast enough). But on the whole I was not able to have forking stream without DMA when packet size
is above 64 bytes (size of hardware FIFO size).
...

#
hathach
[hathach/tinyusb] New branch created: improve\-rp2040
#
hathach
[hathach/tinyusb] Pull request opened: #692 Improve rp2040

Describe the PR

  • Update pico-sdk to latest of develop branch
  • Enable pico_bootsel_via_double_reset for all examples
  • Add Disconnection detection and submit UNPLUGGED event to usbd
  • Add Add TODO for suspend, resume later on, since it needs a bit of time to test on board with/without vbus detection.
  • Implement dcd_remote_wakeup() (not tested since suspended is not enabled yet).
  • Tested LOG with segger rtt.

All CMakelists.txt are updated, just ignore it, the interested modi...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Since the dcd_edpt_iso_xfer() does not have anything specific about ISO, I think we should rename it to dcd_edpt_xfer_fifo()

I thought about that too and i would say thats better! There is but one concern, currently all dcd_edpt_xfer_fifo() are implemented such that no EP0 transfere can be handled via the FIFOs. This was a matter of time, since most EP0 transfers are somewhat special and i had no time to dig into that.
I would spare this for later if somebody really has the need f...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

@PanRe hmm, I forgot about multiple API() right across threads in application. Which is indeed true for cdc, the write()/print() can be called virtually across all the thread (with rtos). Hmmm, apparently we may need to put more thought on this, fifo does come with complexity of mutex though. We can separate write/read mutex for fifo and only enable mutex for the driver side (since mutex in isr can be tricky). I am not too worry about it right now, but definitely something to pay more attenti...

#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Since the dcd_edpt_iso_xfer() does not have anything specific about ISO, I think we should rename it to dcd_edpt_xfer_fifo()

I thought about that too and i would say thats better! There is but one concern, currently all dcd_edpt_xfer_fifo() are implemented such that no EP0 transfere can be handled via the FIFOs. This was a matter of time, since most EP0 transfers are somewhat special and i had no time to dig into that.
I would spare this for later if somebody really has th...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Well there is the case that you don't have a middle man buffer any more but only one FIFO... i think the best would be to extend the FIFO capabilities now and solve this issue once and for all by using separate mutexes for read and write and allow to not enforce use of mutexes just as you suggested!
Maybe the best would be to check within fifo.c if a mutex is set and only if so execute it. Otherwise just ignore it.
I can do this easily, the only nasty thing is that all projects where mutexe...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #693 SAME70 DCD Support

Describe the PR
Implementation of the SAM70 DCD driver.

Additional context
It's still very sketchy. Tested echo works with cdc_dual_ports example, but EP0 still have issues, for example set_line_coding doesn't work. (Seems like )

TODO:

  • [ ] Fix EP0 bugs
  • [ ] Test with more examples
  • [ ] Clean up & format code
  • [ ] Add DMA&FIFO support

Any help is appreciated :)

fallow birchBOT
#
geek-slt
[hathach/tinyusb] Issue opened: #694 get device descriptor error

Set up
[Mandatory] Provide details of your setup help us to reproduce the issue as quick as possible

  • PC OS :Windows 10
  • Board : STM32 F407VGXX
  • Firmware: examples/device/hid_composite_freeRTOS

Describe the bug
0.Projects created using the master branch on 2.24 can run normally
1.tusb_init() success
2.The windows device manager prompts that the device descriptor request failed
3.It looks like uint8_t const * tud_descriptor_device_cb(void) function ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-family\-board
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #688: Fix Endpoint descriptor size for MIDI Device

endpoint descriptor is always 7 (USB specs). There is probably some mis-handling somewhere.If you provide further details on how you test it, people could help to clear it up ( I am assuming you are using midi_test example, if you don't please use that example )

It does appear that for audio class, the descriptors are length 9. This is mentioned as a note in the USB 2.0 spec (section 9.6):

9.6 Standard USB Descriptor Definitions

The standard descriptors defined in this speci...
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #688: Fix Endpoint descriptor size for MIDI Device

@hathach ,

Eeek, yeah, I didn't even notice that USB-MIDI 2.0 and USB AUDIO 2.0 and 3.0 use the 7-byte descriptor:

USB-MIDI spec 2.0: 5.3.1:

Note: In the USB MIDI 1.0 specification, the Standard MIDI Streaming Data Endpoint Descriptor
includes two additional fields, bRefresh, and bSynchAddress. These fields are not included in
USB MIDI 2.0.

It looks like the class driver here is for USB-MIDI 1.0, so this patch is correct. This library's other USB audio class uses audio 2...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
geek-slt
[hathach/tinyusb] New comment on issue #694: device descriptor request failed

I tested it in depth and found that the problem appeared in the loop of tud_task(), so I added log output to the tud_task() function, and found that the program can enter the tud_task()->while(1) loop and be able to get from the queue I received the event, but it is strange that the DCD_EVENT_BUS_RESET event can be received, but the DCD_EVENT_SETUP_RECEIVED cannot be received. This is why the process_control_request() cannot be executed and cannot respond to the host's descriptor request, whi...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Wait, what exactly do you mean? Should

#if CFG_FIFO_MUTEX
static inline void tu_fifo_config_mutex(tu_fifo_t *f, tu_fifo_mutex_t mutex_hdl)
{
  f->mutex = mutex_hdl;
}
#endif

be changed to

#if CFG_FIFO_MUTEX
static inline void tu_fifo_config_mutex_write(tu_fifo_t *f, tu_fifo_mutex_t mutex_hdl)
{
  f->mutex_wr = mutex_hdl;
}
#endif

and

#if CFG_FIFO_MUTEX
static inline void tu_fifo_config_mutex_read(tu_fifo_t *f, tu_fifo_mutex_t mutex_hdl)
{
  f->mutex_...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

@PanRe I mean you could do it now, or leave it to follow up PR. There is no need to implement it right away :). Regarding the API we can change it to

tu_fifo_config_mutex(f, tu_fifo_mutex_t write_mutex, tu_fifo_mutex_t read_mutex)

and it is legit to set either as NULL or both Write and Read mutex to the same one, which we will do atm for existing driver . Regarding updating existing code, it should be no problem, tu_fifo is internal data type, there is only a handful of drive...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-rp2040\-bus\-reset
#
hathach
[hathach/tinyusb] Pull request opened: #700 fix enum walkaround forever check for SE0 when pull up is disabled

Describe the PR
This issue is discovered while troubleshooting https://github.com/adafruit/circuitpython/issues/4066#issuecomment-789524956

Part of enumeration walkaround is waiting for bus reset to complete i.e line state != SE0.
https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_fix/rp2040_usb_device_enumeration/rp2040_usb_device_enumeration.c#L61

However, when pull-up is disabled e.g application call tud_disconnect() to soft disconnect from Host (while s...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #688: Fix Endpoint descriptor size for MIDI Device

@dhalbert Circuitpython should also update its MIDI endpoints descriptor as well, the correct endpoint size is 0x09. Just notice cpy is also 0x07.

0x07, 0x05, 0x06, 0x02, 0x40, 0x00, 0x00, // <adafruit_usb_descriptor.standard.EndpointDescriptor object at 0x7fe81cffbdc0>
0x05, 0x25, 0x01, 0x01, 0x01, // <adafruit_usb_descriptor.midi.DataEndpointDescriptor object at 0x7fe81cffbdf0>
0x07, 0x05, 0x86, 0x02, 0x40, 0x00, 0x00, // <adafruit_usb_descriptor.standard.EndpointDescriptor object...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: ci\-cache\-toolchain
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #700: fix enum walkaround forever check for SE0 when pull up is disabled

Looks good to me. In terms of VBUS, you can use a level high / level low interrupt on any GPIO to provide a vbus changed interrupt. That is to say, you don't need to use vbus detect from the actual usb controller input.

Does it trigger the VBUS_DETECT interrupt in sie_status. I would hop to handle it internally by the stack without user to call any API. For example, on nRF52, the PHY is still disabled after tud_init() and only enabled after VBUS is detected. Then it got disabled again af...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-ci
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Pull request opened: #703 EFM32 Family Support

Describe the PR
Addition of Silabs config options
Addition of EFM32GG12 cmsis
Implementation of the EFM32 DCD driver.
EFM32GG12 Dev Board Support

Additional context
While trying to port this family, thinking it would be completely new, I noticed something very peculiar while looking at the other drivers for help.
I noticed the USB peripheral Silabs uses on their mcus is very close to the one use in the ESP32S2 from espressif, very little difference between them, my guess is that ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #703: EFM32 Family Support

that is great to hear EFM32 also use synopsys as their USB-IP. There is a pending issue #382 to generalize the ip driver much like ehci/ohci. If you could get it running on EFM32, then I guess it would help a lot in the generalization later on. Good news, that I also have an EFM M4 Giant Gecko sitting on my storage for more than 5 years. Would be great to revive it :D .

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-back\-cmsis5
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #693: SAME70 DCD Support

With DMA and Dual Bank the throughput is quiet good.
Running at 150MHz in ITCM, with cdc_xfer_cb commented out

    // TODO search for wanted char first for better performance
    for(uint32_t i=0; i<xferred_bytes; i++)
    {
      tu_fifo_write(&p_cdc->rx_ff, &p_cdc->epout_buf[i]);

      // Check for wanted char and invoke callback if needed
      if ( tud_cdc_rx_wanted_cb && ( ((signed char) p_cdc->wanted_char) != -1 ) && ( p_cdc->wanted_char == p_cdc->epout_buf[i] ) )
      ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach , How does the communication happen stack and the driver if there more than 64 bytes of data to be transferred during control transfer? I see the stack says that the total length of configuration descriptors is 98 bytes, however, the dcd_edpt_xfer function just provides 64 bytes for. The driver needs to send more data on next IN packet from the host. Is there a shared buffer that I can use from the driver?

fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

@hathach For some reason the checks are failing as they aren't able to find the ti_driver repo. I don't know what happened all of a sudden, can you help me with that?

Additionally, I had a question, how does the communication happen between the stack & the driver if there are more than 64 bytes to be transferred? I see the configuration descriptor's total length is 98 bytes. However the dcd_edpt_xfer passes only 64 bytes to the driver at a time. Is there a shared buffer that the driv...

fallow birchBOT
#
crosswick
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

Thank you - unfortunately, still the same error

Op za 6 mrt. 2021 om 05:22 schreef Ha Thach notifications@github.com:

There is recent bug fix related to vendor control handling especially
webusb #646 https://github.com/hathach/tinyusb/pull/646 please pull and
try again to see if it fix this issue

โ€”
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/hathach/tinyusb/issues/498#issuecomment-791866835...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pran005
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

TinyUSB usbd can request transfer that is a lot larger than max packet size. It is dcd responsibility to carry out the requested length. When all the bytes is transferred, dcd invoked the dcd_event_xfer_complete() to notify the usbd

@hathach but I see the configuration descriptor is 98 bytes in length, however the len field in dcd_edpt_xfer is set t 64 by the usbd. Also, no stack doesn't request any ZLP to be sent. Is there some other function / shared data structure that requests t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #670: WIP : Adding Tiva C \(ek\-tm4c123gxl\) support\.

usbd will request next packet after 64 first bytes is transferred. It will also request xfer with length=0 as zlp as well. DCD must not auto send zlp. Sum up, dcd just need to transfer what the usbd request. The rest will be taken care by usbd.
Note: to save sram, usbd control is transferred 64 byte each, but behavior can be configured/changed later on. Other class driver such as msc can normally request 4K or more for each transfer.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

hm, if you are not using the updated example, please also sync your project to the new webusb example handling for control transfer as well. https://github.com/hathach/tinyusb/pull/645

I just pulled out the board stm32f407disco and test with webusb_serial and everything works just fine with chrome on Linux. Please note that it is necessary to test with exact dev board and the exact example since that ensure we are testing the same thing.

fallow birchBOT
#
crosswick
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

I did use the updated example... also yes I have an exact
stm32f407disco board. I compiled in macOS and also in a fresh Ubuntu
20.04.1 VM and uploaded the resulting .elf file with STM32CubeProgrammer in
macOS, resulting in the same error in Chrome macOS. I will try again with
everything inside the Linux VM.

Op di 9 mrt. 2021 om 05:43 schreef Ha Thach notifications@github.com:

hm, if you are not using the updated example, please also sync your
project to the new webusb example handli...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

yes, it is that one, maybe it has something to do with macOS. There is a SET_INTERFACE targeted the webusb interface can you update the main.c tud_vendor_control_xfer_cb() of webusb serial to add following if to see if it could get it work

else if (
        request->bmRequestType_bit.type == TUSB_REQ_TYPE_CLASS &&
        request->bRequest == 0x22) {
    // existing code
}
// new code
else if ( request->bmRequestType_bit.type == TUSB_REQ_TYPE_STANDARD && request->bRequest == ...
fallow birchBOT
#
ristohelkio
[hathach/tinyusb] Issue opened: #709 RP2040 Host Stack fails with HID devices

Set up

  • Board : Raspberry Pi Pico with UART tracing via Raspberry Pi 4
  • Firmware: /examples/host/cdc_msc_hid
  • Keyboard: Generic wireless keypad (Exibel - Provision Technology, Inc)
  • HUB-keyboard: Apple

Describe the bug
When connecting a keyboard to Pico the process fails at the point where the stack is trying to read the full Device Descriptor. If the Device Descriptor fits into one single packet (bMaxPacketSize0 == 64) the reading is successful. When...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-doc
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

@crosswick update: I also tested with one of my macos machine, it seems to work just fine. I guess you have to do the test here if you don't mind. Can you post the LOG with updated code to see if we got other error rather than the stall with SET_INTERFACE as previously.

USBD Setup Received 01 0B 00 00 02 00 00 00
Set Interface
VENDOR control request
Stall EP0
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: usbd\-handle\-set\-interface
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-pico\-sdk\-1\.1\.0
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I am bump it up to master, and change base back and forth to get github file changes updated, also fix ci build. Indeed there is a spaghetti include especially between osal and fifo, since they include each other. or osal_none and osal_pico, the fifo is used to implement os queue structure. I just add enough to get ci passed, will do an overall includes refactor later on as separated PR.

While reviewing your latest push, I realized that fifo to fifo opertation (read, peak) isn't use...

#
hathach
[hathach/tinyusb] Pull request review submitted: #713 Call One time tu\_fifo\_write\_n on cdcd\_xfer\_cb

thanks for the PR, yeah, this is one of the improvement I planed to do but totally forgot. However, the implementation is not actually quite right. The driver must invoke the wanted_cb() right at the time it push the wanted_char into the fifo. which allow the application callback that call read() see the wanted_chr right away.

For example, to catch the \n then call read() to get the whole line. Else application must skip dozen of characters. which can potentially has another '\n' ...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #713 Call One time tu\_fifo\_write\_n on cdcd\_xfer\_cb

After giving it more thought, I think it is not worth to have wanted as the last char in the fifo at the time of the callback. It doesn't occur often and also doesn't have much impact on existing usage (application may need a minor of adjustment). Let's do it this way, though we still need to check if there is still data in the fifo before invoking the wanted callback, else it could confuse the app.

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

@PanRe I am bump it up to master, and change base back and forth to get github file changes updated, also fix ci build. Indeed there is a spaghetti include especially between osal and fifo, since they include each other. or osal_none and osal_pico, the fifo is used to implement os queue structure. I just add enough to get ci passed, will do an overall includes refactor later on as separated PR.

While reviewing your latest push, I realized that fifo to fifo opertation (read, p...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #677: Number of audio input channels hardcoded in AUDIO\_MIC descriptor

Sorry for the late reply! The audio driver was not fully finished at your time using but it is nearly done. There will be some changes regarding the data structure with the FIFOs, but i tried to make everything easier! Please have a look on the new driver once it is out. Not everything is fully tested as audio is a pretty broad topic, so i am happy if you can test it too!

The descriptors were written hard coded at the time being. If you find the time you are very welcome to generalize the ...

fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] Issue opened: #714 Moving core library to submodule

Is your feature request related to a problem? Please describe.
I would like to use TinyUSB in an SDK; however I found that it is less than ideal to add as a submodule, due to the current structure. Tinyusb submodules pico-sdk in hw/mcu/raspberrypi. pico-sdk submodules tinyusb in lib. Currently, pico-sdk submodules a fork without the raspberrypi submodule added, so there is no infinite recursion issue, for now. Additionally, the SDK I am working on has FreeRTOS and fatfs, so currentl...

fallow birchBOT
#
crosswick
[hathach/tinyusb] New comment on issue #498: "NetworkError: Unable to set device interface\." when testing webusb\_serial on stm32f407disco

Well not sure why, but it works now... first I used my Catalina Mac Pro to compile and test - works. Same board also works on the earlier Mojave Macbook. Next, without changing the compile toolchain on that Macbook, I compiled the current version - also works. Perhaps my previous test of 4 days ago somehow wasn't with the updated version...

I could doublecheck with a version prior to the vendor control handling fix if you'd like. In any case: thank you! Issue can be closed as fas as I'm c...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #713: Call One time tu\_fifo\_write\_n on cdcd\_xfer\_cb

After some thought I feel more hesitate about how to implement it :>

While I use UART extensively in our product, I always use a packet so there is no last char problem.

We also need to make sure data is written (fifo not full) before call the cb. If the application relies on tud_cdc_rx_wanted_cb, there could be a deadlock where the fifo is full but no wanted char received.

If it's a personal project I'd delete this cb and let the application to do all the decoding :) I think we ...

fallow birchBOT
fallow birchBOT
#
mayl
[hathach/tinyusb] Issue opened: #715 usbd\.h missing includes?

I'm using tinyusb as part of my project, and in the course of integrating it into my build system hit an error when compiling usbd.h. The line below references MSC_SUBCLASS_SCSI which is declared in class/msc/msc.h. However, my build was failing because usbd.h never includes class/msc/msc.h.
https://github.com/hathach/tinyusb/blob/2adb7e719316b12c53a907153cfa0056db1abd70/src/device/usbd.h#L220

Adding a #include "class/msc/msc.h" line to usbd.h resulted in a successful,...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #713: Call One time tu\_fifo\_write\_n on cdcd\_xfer\_cb

Oh, I didn't think about the edge case where fifo is full and wanted char has yet to come. Maybe we should have an rx_full_cb(). However, it should not be affected by existing code or your PR. After all, if application want to process a large data with wanted ch (e.g command with newline), they should tune up the fifo to large enough. Anyway, I think we should just continue with this PR, would you mind to add the check if fifo not empty before invoked the wanted callback. That would be enou...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release\-0\.9\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.9\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

I am slowly reviewing this, still there is a lot more to go through. Though there is few simple lines that I made a quick commit for. Not bad for the start :)

Regarding the audio_task(), do you have an sample with recognized tone that we could feed usb host (repeatedly). Just to show that it works. That will make sure more confident in the example, also allow me (noob at audio) can confidently refactor code in driver and fifo etc ... MIDI example has some thing similar https://github.com/h...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

I am slowly reviewing this, still there is a lot more to go through. Though there is few simple lines that I made a quick commit for. Not bad for the start :)

Regarding the audio_task(), do you have an sample with recognized tone that we could feed usb host (repeatedly). Just to show that it works. That will make sure more confident in the example, also allow me (noob at audio) can confidently refactor code in driver and fifo etc ... MIDI example has some thing similar https:...

fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Yes alternate settings are implemented! But this was included from beginning on?! So you can define alternate interface descriptors 1,2,3 etc. and the host selects those. There you can define your desired sampling ratios, resolutions etc. Currently, the driver assumes only one sampling rate but this is only used in the #define n_bytes_per_sample which is used to determine the amount of bytes to be copied. If you want the more flexible version this needs to be generalized in the dr...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request review submitted: #593 Edpt iso xfer

Yes alternate settings are implemented! But this was included from beginning on?! So you can define alternate interface descriptors 1,2,3 etc. and the host selects those. There you can define your desired sampling ratios, resolutions etc. Currently, the driver assumes only one sampling rate but this is only used in the #define n_bytes_per_sample which is used to determine the amount of bytes to be copied. If you want the more flexible version this needs to be generalized in the driver...I d...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

DMA is already covered by the functions

// Pointer modifications intended to be used in combinations with DMAs.
// USE WITH CARE - NO SAFTY CHECKS CONDUCTED HERE! NOT MUTEX PROTECTED!
void     tu_fifo_advance_write_pointer  (tu_fifo_t *f, uint16_t n);
void     tu_fifo_backward_write_pointer (tu_fifo_t *f, uint16_t n);
void     tu_fifo_advance_read_pointer   (tu_fifo_t *f, uint16_t n);
void     tu_fifo_backward_read_pointer  (tu_fifo_t *f, uint16_t n);

// If you want to read/writ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Regarding the example, currently the loading of data is done within a callback function tud_audio_tx_done_pre_load_cb(), hence, within audio_task() there is not much left to do... I did not put samples into the buffer from the audio_task() because i thought it would be pretty unreliable to generate a sample frequency of 48 kHz using wait() functions. So i put everything at once within the callback. This is of course not the way to do it later when you have real samples but much more...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #593: Edpt iso xfer

Regarding the example, currently the loading of data is done within a callback function tud_audio_tx_done_pre_load_cb(), hence, within audio_task() there is not much left to do... I did not put samples into the buffer from the audio_task() because i thought it would be pretty unreliable to generate a sample frequency of 48 kHz using wait() functions. So i put everything at once within the callback. This is of course not the way to do it later when you have real samples but...

#
PanRe
[hathach/tinyusb] New review comment on pull request #593: Edpt iso xfer

Yes alternate settings are implemented! But this was included from beginning on?! So you can define alternate interface descriptors 1,2,3 etc. and the host selects those. There you can define your desired sampling ratios, resolutions etc. Currently, the driver assumes only one sampling rate but this is only used in the #define n_bytes_per_sample which is used to determine the amount of bytes to be copied. If you want the more flexible version this needs to be generalized in the dr...