#tinyusb

1 messages · Page 5 of 1

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] Issue opened: #2398 MAX3421 as host: lost EP Rx transfer, race condition

Operating System

Linux

Board

NUCLEO-WL55JC1 (STM32WL55 with LoRaWAN, but no internal USB controller), external MAX3421 as host

Firmware

own firmware running on STM32 based on STM32CubeWL Firmware Package v1.3.0

What happened ?

I've maybe found a bug, but I'm not sure...
My application: STM32 with MAX3421 and TinyUSB host communicating with attached CDC device (RS232)
The issue: CDC Tx bulk transfers are lost depending on timing relationship of Rx/Tx bulk tranfers

I...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Ryzee119
[hathach/tinyusb] Pull request opened: #2401 [OHCI] Allow more than 16 devices

Describe the PR
Fixes issue we discussed way back in https://github.com/hathach/tinyusb/issues/1497

[Ryzee119]commented [on Jun 8, 2022]
I will create a PR for this fix soon

heh :upside_down_face:

Additional context
This now allows 256 EDs, and >=127 devices as per USB spec. This should cover pretty much anyones needs while keeping a few bits in the TD structs for future use.

The extra array will likely help with iso transfers which I am look at now as we likely ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Okarss
[hathach/tinyusb] New comment on pull request #2402: [STM32 FSDEV] Fix ISR race conditions

In my case it's a custom self-powered device based on STM32L432KBU6, which implements a single MSC class device. There is no RTOS, just a simple cooperative scheduler. The compiler used is GCC v10.3. With O0 the USB often (but not always) worked, but with Og, O1 or anything higher it basically never worked. The TinyUSB log showed that the stack issues too many resets (more than the 3 typical ones). It could be that the fine timings are specific to the host PC. In that case the PC is a rather ...

#
Okarss
[hathach/tinyusb] New comment on pull request #2402: [STM32 FSDEV] Fix ISR race conditions

Took a look on that failed test for F1 series. It fails because the registers on F1 are defined as 16-bit. Just adding a cast to uint16_t doesn't seem future proof and actually H5 series already have some status bits above the bit 15. Maybe it's worth introducing some typedef fsdev_register_t, which should be defined to uint16_t for some series and uint32_t for all the other by default?

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
sckid1108
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

Hey gang, I got STM32H503 with TinyUSB working by removing MX_ICACHE_Init() from main.c
(there might be a timing error - see https://community.st.com/t5/stm32-mcus/how-to-use-stmicroelectronics-classic-usb-device-middleware-with/ta-p/599274?lightbox-message-images-613409=61313i4F7537BE778740F2)

Also I had to change the code in "dcd_stm32_fsdev_pvt_st.h"
Lines 217 and to 230 USB_DRD_BASE -> USB_DRD_FS_BASE

stm32h5xx_it.c

/**

  • @brief This function handles USB FS global interrupt....
fallow birchBOT
#
Ryzee119
[hathach/tinyusb] Pull request opened: #2404 [HUB] Prevent status request to invalid ep_num

Describe the PR
If you disconnect a USB hub tusb clears the hub device memory (to zeros). If its a hub, during disconnect it also creates a detach event on hub port 0 to unroll the loop. Problem occurs when it processes this detach event on the now cleared hub device and requests the next hub status packet

https://github.com/hathach/tinyusb/blob/ae364b1460b91153cd94b4b0303eeda6419ff1d1/src/host/usbh.c#L461

Resulting in this request onto the hub interrupt endpoint
`Queue EP 00 with...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
leptun
[hathach/tinyusb] Pull request opened: #2408 Disable ULPI clock during sleep on stm32f7 when using internal phy

This PR addresses a bug I discovered on stm32f7 when using the OTG_HS dwc2 peripheral with the internal FS phy while also using tickless idle with freertos. The problem is identical to the issue described for the H7 series, but on the F7 different bit names are used. This patch also disables the ULPI clock during tickless idle for stm32f4 and stm32f2 series microcontrollers that have the OTG_HS peripheral. While I did not test the other MCUs, I don't see how this could harm since with this pa...

fallow birchBOT
#
Loc15
[hathach/tinyusb] Issue opened: #2409 Allow to switch between pio mode and native usb on rp2040 on runtime

Related area

host stack

Hardware specification

rp2040

Is your feature request related to a problem?

When the pio support is enabled the native version doesn't work because pio version have redefinition on some functions that doesn't work on native version. There are cases where is necessary to switch from a mode to the other to take advantage from the pio space free when use the native version.

Describe the solution you'd like

Merge the initialization functions of nat...

fallow birchBOT
#
Okarss
[hathach/tinyusb] New comment on pull request #2402: [STM32 FSDEV] Fix ISR race conditions

Reviewed all of the related ST reference manuals and header files and found out that the following factors are equal for all devices:

  • Register width in the header file
  • Register width in the reference manual
  • PMA access width in the reference manual

As registers and PMA are accessed through the same bus interface, most likely access width is limited by the bus interface itself. The access width is 16-bit for all older devices and 32-bit for the newer G0, H5, U5. That means the `PMA_...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2402: [STM32 FSDEV] Fix ISR race conditions

Added a commit with a new fsdev_bus_t typedef. As now those identifiers would serve not just for PMA description, but as a generic FSDEV hardware implementation parameters, for the sake of consistency I would also rename these:

  • PMA_32BIT_ACCESS => FSDEV_BUS_32BIT
  • PMA_LENGTH => FSDEV_PMA_SIZE

Should I add such a commit also or leave those as is?

yeah, please do it while we are here

As registers and PMA are accessed through the same bus interface, most l...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2401 [OHCI] Allow more than 16 devices

superb! Thank you very much for improving the ohci driver. There are some minor things, that I have notice. I take the chance to add cmake support to lpc17 to test out the PR. I have push some update to

  • move gtd extra out of control pool to save sram
  • also rename gtd_data to gtd_extra

Please let me know if these changes make sense to you.

Note: I haven't tested on actual hardware yet, if you have time please do on your side. We can merge this once tested.

#
hathach
[hathach/tinyusb] New review comment on pull request #2401: [OHCI] Allow more than 16 devices

this still potentially waste a bit of sram since compile will do padding to have ED 32 bytes algined resulting to 30*number of control bytes. We should move after all ED/TD declaration e.g

gtd_extra_data_t gtd_data[GTD_MAX]; // extra data needed by TDs that can't fit in the TD struct
gtd_extra_data_t gtd_control_data[CFG_TUH_DEVICE_MAX+CFG_TUH_HUB+1];

it is a bit ugly, but worthy to save as much sram as possible

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: change-weak-event-hook-style
fallow birchBOT
fallow birchBOT
#
Ryzee119
[hathach/tinyusb] New comment on pull request #2401: [OHCI] Allow more than 16 devices

Looks like you beat me to the changes. Good pick ups
I have tested on hardware is all is working great. I tested with 17 devices + 3 hubs :fire:

HID MOUNTED 01 0
START HID
A device with address 1 is mounted
HID MOUNTED 02 1
START HID
A device with address 2 is mounted
HID MOUNTED 03 2
START HID
A device with address 3 is mounted
HID MOUNTED 04 3
START HID
A device with address 4 is mounted
A device with address 5 is mounted
A device with address 6 is mounted
A device w...
#
Ryzee119
[hathach/tinyusb] New review comment on pull request #2397: Add clang to compiler.h

Just to clarify @hathach

Like this?

#if defined(__GNUC__) || defined (__clang__)
  #define TU_ATTR_ALIGNED(Bytes)        __attribute__ ((aligned(Bytes)))
  #define TU_ATTR_SECTION(sec_name)     __attribute__ ((section(#sec_name)))
  #define TU_ATTR_PACKED                __attribute__ ((packed))
  #if defined(__GNUC__)
    #define TU_ATTR_WEAK                  __attribute__ ((weak))
  #else
    #define TU_ATTR_WEAK                  __attribute__ ((weak_import))
  #endif
... ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: cleanup-uvc-example
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
josuah
[hathach/tinyusb] New comment on issue #2194: Enhance HITL (hardware in the loop) test

A type-C switcher allows to programmatically connect two devices pin-by-pin, rather than using a HUB).
Some USBC0 to USBC1, or some USBC0 to USBC2, either at a time.
https://www.digikey.com/en/blog/introducing-the-ultimate-usb-type-c-switch
https://www.codethink.co.uk/articles/2019/codethink-creates-custom-usb-3-switch-to-support-customers-cicd-pipeline-requirements/

This can help to automate host-mode operation:

  1. Workstation <-> DUT: Load a firmware to the DUT (in device mode)
  2. K...
fallow birchBOT
fallow birchBOT
#
josuah
[hathach/tinyusb] New comment on issue #2194: Enhance HITL (hardware in the loop) test

Thinking again, if wanting to leave all boards connected at all time for an automated test script, a switcher of only the D+/D- and +5V lines would be a good compromise.

A port switcher is not the priority, as currently all boards has a debugger attached who can read test results.

Noted! This sounds like a better solution indeed.

For practical setup, regardless of the solution used, here is something that scales well and is cheap and quick to do:

![Testing_USB_devices_practica...

#
sadykowich
[hathach/tinyusb] Issue opened: #2415 SetRequest arrive with wrong buffer content (from other request), when incoming many requests

Operating System

Windows 10

Board

Raspberry Pico

Firmware

TinyUSB 0.15.0
Pico SDK 1.5.1

What happened ?

I would like port this g29emu (https://github.com/mathijsvandenberg/g29emu) to Pico and TinyUSB.
It is almost done but the SetReport requests PS4 auth content not arrived (maybe lost or overwrite with another?): request_id, request_type are good, but the buffer content is other request's content when incoming many requests from the host (PS4).
I attached the log fi...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] Pull request opened: #2416 Add DWC2 Test Mode Support

According to the USB 2.0 specification under point 7.1.20 Test Mode Support, high-speed capable functions must support specific test modes to facilitate compliance testing.

This PR adds the fundamental support for that. It was tested on a NUCLEO-U5A5ZJ-Q and STM32F23E-DISCO where this is supported directly by the MCU.

The entering of the test mode is scheduled by a new event so that the feature request of the host can be acknowledged.

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2413: Support for TUSB_REQ_FEATURE_TEST_MODE

I was also working on a test mode support for TinyUSB. 😃 You can check it out here: #2416
Maybe we can work together so that this feature can be added.

My comments about your implementation:

  • According to the USB 2.0 specification the behavior of the device is not specified if wLength is non-zero. So there should be no reason to filter for that. So I think it's better to just ignore that.
  • TinyUSB should not acknowledge the request and rather stall it if the specific test mode isn...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

what is the preferred code style? ![image](https://private-user-images.githubusercontent.com/151819615/296806613-9ece61c9-88ef-436d-915e-ebfa1feef82b.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MDUzMzc3MTYsIm5iZiI6MTcwNTMzNzQxNiwicGF0aCI6Ii8xNTE4MTk2MTUvMjk2ODA2NjEzLTllY2U2MWM5LTg4ZWYtNDM2ZC05MTVlLWViZmExZmVlZjgyYi5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lB...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: serialhost-change-ftdi-cp210x-pid-list
fallow birchBOT
#
cyber-murmel
[hathach/tinyusb] Issue opened: #2418 sam.h missing

Operating System

Linux

Board

qtpy

Firmware

examples/device/cdc_msc

What happened ?

When trying to compile the cdc_msc example for QTPy, the compilation stops with the error

/tmp/tinyusb/src/portable/microchip/samd/dcd_samd.c:34:10: fatal error: sam.h: No such file or directory
   34 | #include "sam.h"

The solution outline in #616 isn't applicable.

How to reproduce ?

git clone git@github.com:hathach/tinyusb.git
cd tinyusb/examples/device/c...
fallow birchBOT
fallow birchBOT
solemn basalt
#

👋 is it possible to setup usb host mode using the usb-c connector on, say, the kb2040 (or any rp2040 board that has a single usb connector which is generally used in device mode)?

i've fiddled around a bit with trying to get this to work, the example host mode seems to assume i'm using another usb port and uses GPIO pins for the D+ and D- wires (PIN_USB_HOST_DP) (which makes a lot of sense, because debugging is a lot easier).

fwiw: i did get the host_device_info example working when i used a second usb connector and could see device descriptors via my defined tuh_mount_cb callback function.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

Thanks! Please wait with this PR! I'm finishing the CH34x support and I'll get back to you soon. Due to compatibility issues I had to change large parts and so current commit is no more ready for review.

Which compatibility issue you are encoutering with, I actually want to wrap up this ch340 support since I need it in another project . Initial test giving great result, I have fixed some gcc strict warning regarding siged/unsigned cast and do more with code reviews and testing. If you pl...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I just pushed the current but unfinished version.

I'm currently working on ch34x_set_line_coding().

It's not ready to merge to master, but you can work with and test.

It includes all other open PR from me.

Thank you, I am cherry picking changes and re-added changes that got lost in the latest push. Please wait a bit before making more push. Hopefully we can got it merged asap. I only tested with an usb2uart dongle ch340g, what else are you testing with ?

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I just pushed the current but unfinished version.
I'm currently working on ch34x_set_line_coding().
It's not ready to merge to master, but you can work with and test.
It includes all other open PR from me.

Thank you, I am cherry picking changes and re-added changes that got lost in the latest push. Please wait a bit before making more push. Hopefully we can got it merged asap. I only tested with an usb2uart dongle ch340g, what else are you testing with ?

OK.
I te...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

there is some .bak in the latest push since I am in need to get ch340 support, I will do the clean up right away. Please hold until my push, thank you.
PS: when merging, please also retain my changes, it seems like your latest push discard most of my changes. But that is OK, there is an conflict going on since both of us are updating the driver.

yes, it was a mistake

no problem at all, I did a cherry picking and push the update to the PR. Please pull first before making mor...

fallow birchBOT
#
shuchitak
[hathach/tinyusb] New comment on pull request #2413: Support for TUSB_REQ_FEATURE_TEST_MODE

I was also working on a test mode support for TinyUSB. 😃 You can check it out here: #2416 Maybe we can work together so that this feature can be added.

My comments about your implementation:

  • According to the USB 2.0 specification the behavior of the device is not specified if wLength is non-zero. So there should be no reason to filter for that. So I think it's better to just ignore it.
  • TinyUSB should not acknowledge the request and rather stall it if the specific te...
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2413: Support for TUSB_REQ_FEATURE_TEST_MODE

I borrowed some of your ideas and already changed my implementation.

The entering of the test mode needs to be done after the request has finished. Using the control complete callback is a great way of ensuring that. Otherwise the device is in the test mode before the host got the acknowledge. So that the test mode already took over the signaling and the host request times out.

_I already saw people who do signaling tests only relying on the shown status of the compliance tool. They tho...

fallow birchBOT
fallow birchBOT
#
shuchitak
[hathach/tinyusb] New comment on pull request #2416: Add DWC2 Test Mode Support

Sorry I meant this line,
TU_VERIFY(dcd_enter_test_mode && dcd_check_test_mode_support && 0 == tu_u16_low(p_request->wIndex));

If somebody doesn't support this feature, they wouldn't implement these dcd functions and TU_VERIFY would return false.

Isn't it the same as the existing code doing this,
// Only support remote wakeup for device feature
TU_VERIFY(TUSB_REQ_FEATURE_REMOTE_WAKEUP == p_request->wValue);

where for the TUSB_REQ_FEATURE_TEST_MODE feature, it would return false?

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New review comment on pull request #2391: initial support of CH34x CDC device

My list of drivers examined above was not complete.
As already mentioned, I examined the Linux sources of:

  • Vendor WCH (with poor quality)
  • Linux Kernel
  • FreeBSD

None of the 3 Linux drivers worked with all of my CH34x on the desk, not even the WCH one!
Then I tried the two different WCH Windows driver

  • V3.5.2019.1
  • V3.8.2023.2

Only V3.5.2019.1 worked with all my CH34x.
I analyzed both versions with an USB bus analyzer, get the working init and config sequence and overtaken ...

fallow birchBOT
fallow birchBOT
brisk glen
#

Hi 👋

#

I'm debugging an issue with an M0/pico port of a Teensy project. Teensy serial USB is working in both directions, but on the Adafruit_TinyUSB boards sending messages out isn't working.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #2391: initial support of CH34x CDC device

thank you for the update, however, I think we should not use init command to change baudrate/link data. Those are just convenient when init. But it will reset every internal state including all control signal e.g dtr/rts etc, while we only want to change e.g baudrate while connectinng. I am still revisig the driver, lackig official documentation make thing more difficult, but I prefer to program lcr and div_prescale as linux approach.

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New review comment on pull request #2391: initial support of CH34x CDC device

I have had the same thoughts and concerns.
WCH just names the request “CMD_C1”.
In this respect, I wonder where the term “serial init” comes from.
This is probably just an interpretation of the non-WCH developers who didn't have an official datasheet.

But no matter, then we have to implement a sequence of 2 register write requests.
I have no experience with this (especially with special usage of user_data) and in the meantime I'm already working on another project.
Can you please prov...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I have pushed the update that implement 2 stage set line coding, also added single set_data_format() as new API. Please test it out to see if that works for you. I will probably do a bit more clean up before merging this.

I'm now implementing ch34x_set_line_coding() and then and then I'm done with CH34x. My goal is to add complete support for all popular CDC devices. And so support for the Prolific PL2303 is missing. And the line coding settings for FTDI and CP210x are still missing. Wha...

fallow birchBOT
#
IngHK
[hathach/tinyusb] New review comment on pull request #2391: initial support of CH34x CDC device

Better to understand:

  switch(parity) {
    case CDC_LINE_CODING_PARITY_NONE:
      break;

    case CDC_LINE_CODING_PARITY_ODD:
      lcr |= CH34X_LCR_ENABLE_PAR;
      break;

    case CDC_LINE_CODING_PARITY_EVEN:
      lcr |= CH34X_LCR_ENABLE_PAR | CH34X_LCR_PAR_EVEN;
      break;

    case CDC_LINE_CODING_PARITY_MARK:
      lcr |= CH34X_LCR_ENABLE_PAR | CH34X_LCR_MARK_SPACE;
      break;

    case CDC_LINE_CODING_PARITY_SPACE:
      lcr |= CH34X_LCR_ENABLE_PAR | CH...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] Pull request review submitted: #2391 initial support of CH34x CDC device

I advise not to change that.
There are explicit instructions that default line coding is necessary to start up the CH34x.
For this reason I created CFG_TUH_CDC_LINE_CODING_ON_ENUM_CH34X.
It may happen, that the following steps 'CONFIG_CH34X_SPECIAL_REG_WRITE' etc. will not work properly.
see

fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I advise not to change that. There are explicit instructions that default line coding is necessary to start up the CH34x. For this reason I created CFG_TUH_CDC_LINE_CODING_ON_ENUM_CH34X. It may happen, that the following steps 'CONFIG_CH34X_SPECIAL_REG_WRITE' etc. will not work properly. see

* https://github.com/torvalds/linux/blob/c25b24fa72c734f8cd6c31a13548013263b26286/drivers/usb/serial/ch341.c#L386

* inital 9600 Bd write https://github.com/WCHSoftGroup/ch341ser_...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I advise not to change that. There are explicit instructions that default line coding is necessary to start up the CH34x. For this reason I created CFG_TUH_CDC_LINE_CODING_ON_ENUM_CH34X. It may happen, that the following steps 'CONFIG_CH34X_SPECIAL_REG_WRITE' etc. will not work properly. see

* https://github.com/torvalds/linux/blob/c25b24fa72c734f8cd6c31a13548013263b26286/drivers/usb/serial/ch341.c#L386

* inital 9600 Bd write https://github.com/WCHSoftGroup/ch34...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2416: Add DWC2 Test Mode Support

@shuchitak
The build error looks to me like a configuration problem, it appeared while I haven't really changed the code.

CMAKE_C_COMPILER_VERSION not detected. This should be automatic.

-- Configuring incomplete, errors occurred!

For the code exclusion I currently favor to use a symbol and if that is defined to not compile the code in the first place. Because I prefer an opt-out for it and keeping it as simple as possible.

#
IngHK
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I advise not to change that. There are explicit instructions that default line coding is necessary to start up the CH34x. For this reason I created CFG_TUH_CDC_LINE_CODING_ON_ENUM_CH34X. It may happen, that the following steps 'CONFIG_CH34X_SPECIAL_REG_WRITE' etc. will not work properly. see

* https://github.com/torvalds/linux/blob/c25b24fa72c734f8cd6c31a13548013263b26286/drivers/usb/serial/ch341.c#L386

* inital 9600 Bd write https://github.com/WCHSoft...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2391: initial support of CH34x CDC device

I advise not to change that. There are explicit instructions that default line coding is necessary to start up the CH34x. For this reason I created CFG_TUH_CDC_LINE_CODING_ON_ENUM_CH34X. It may happen, that the following steps 'CONFIG_CH34X_SPECIAL_REG_WRITE' etc. will not work properly. see

* https://github.com/torvalds/linux/blob/c25b24fa72c734f8cd6c31a13548013263b26286/drivers/usb/serial/ch341.c#L386

* inital 9600 Bd write https://github.c...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
antoniovazquezblanco
[hathach/tinyusb] Pull request opened: #2421 Log outbound xfer bytes while in debug

Describe the PR
This simple PR logs outbound xfer bytes when log level is set to debug. It is useful to be able to dissect the full conversation and not only incoming packets.
While this may be too verbose, it is quite useful when things go south.

Additional context
This is really nice in combination with a simple USB dissector. I am currently using scapy to parse the logs. I may create a PR to scapy with the relevant USB layers and may post an example on how to use them in a fu...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
shuchitak
[hathach/tinyusb] New comment on pull request #2416: Add DWC2 Test Mode Support

@Rocky04, I agree, a simple opt out based on a define sounds good. Something like this?

`diff --git a/src/device/usbd.c b/src/device/usbd.c
index 83217a869..4b30a7447 100644
--- a/src/device/usbd.c
+++ b/src/device/usbd.c
@@ -731,6 +731,7 @@ static bool process_control_request(uint8_t rhport, tusb_control_request_t const
tud_control_status(rhport, p_request);
break;

+#ifndef DISABLE_TUSB_TEST_MODE_SUPPORT
// Support for TEST_MODE
...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: retry-hil-s3
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
tlyu
[hathach/tinyusb] Issue opened: #2425 C standards-conforming negative number support in HID report descriptors

Related area

HID report descriptors

Hardware specification

N/A

Is your feature request related to a problem?

There is a C standards conformance problem with the macros in class/hid/hid.h and negative 16-bit numbers. This makes it awkward to naturally specify negative numbers in HID report descriptors using the TinyUSB macros. These negative numbers often appear in the HID report descriptors of interfaces such as mice and joysticks. The existing templates in TinyUSB only use...

fallow birchBOT
#
Lotharyx
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

Hmm. USB_DRD_FS_BASE is not a defined symbol for me, but USB_DRD_FS is (and appears to be a register base address).

However, changing that as well as commenting out MX_ICACHE_Init() didn't help my situation. A breakpoint in USB_DRD_FS_IRQHandler is also never hit, and my computer doesn't react to plugging/unplugging the USB cable.

fallow birchBOT
#
sckid1108
[hathach/tinyusb] New comment on issue #2203: STM32H5 support
  1. stm32h5xx_it.c
    /**
  • @brief This function handles USB FS global interrupt.
    /
    void USB_DRD_FS_IRQHandler(void)
    {
    /     USER CODE BEGIN USB_DRD_FS_IRQn 0 */

/* USER CODE END USB_DRD_FS_IRQn 0 /
//HAL_PCD_IRQHandler(&hpcd_USB_DRD_FS); <-- COMMENTED OUT
/ USER CODE BEGIN USB_DRD_FS_IRQn 1 /
tud_int_handler(0);
/ USER CODE END USB_DRD_FS_IRQn 1 */
}

  1. main.c
    make sure to call MX_USB_PCD_Init();

  2. usb.c (see attached)

/* USER CODE BEGIN Header /
/...

#
sckid1108
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

Hmm. USB_DRD_FS_BASE is not a defined symbol for me, but USB_DRD_FS is (and appears to be a register base address).

However, changing that as well as commenting out MX_ICACHE_Init() didn't help my situation. A breakpoint in USB_DRD_FS_IRQHandler is also never hit, and my computer doesn't react to plugging/unplugging the USB cable.

Contact me directly if you want me to walk you through getting this running
It was a PITA

fallow birchBOT
fallow birchBOT
#
sckid1108
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

Yes sir, I do think that tinyusb will work for you and happy to help.
I know how frustrating this can be 🙂
M

From: Brian @.>
Sent: Wednesday, January 24, 2024 12:30 PM
To: hathach/tinyusb @.>
Cc: Michael Margolese @.>; Comment @.>
Subject: Re: [hathach/tinyusb] STM32H5 support (Issue #2203)

That's an extremely generous offer. I am going to make an attempt to roll my own USB CDC implementation and eschew tinyusb;...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: setup-python@v5
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enhance-uvc
fallow birchBOT
#
sckid1108
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

@.***
424-288-9585

From: Brian @.>
Sent: Friday, January 26, 2024 10:58 AM
To: hathach/tinyusb @.>
Cc: Michael Margolese @.>; Comment @.>
Subject: Re: [hathach/tinyusb] STM32H5 support (Issue #2203)

Hi M, I'm not sure how to contact you directly. I followed the link from your profile and filled out the "contact us" form on that site. Is there a better way?

—
Reply to this email directly, view it on GitH...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #2435 Enhance UVC decriptors and example

Describe the PR
UVC (as well as UAC) has a sophisticated configuration descriptor depending on user application, which make defining template macros rather difficult. I have update video_capture example to use custom struct to define uvc configuration descriptor. In my opinion, it make thing a bit clearer and easier to customize and troubleshoot descriptor typo/errors.

I also rename some of the video descritpor add several variant of struct/typedef with different number of trailing o...

fallow birchBOT
#
moc32
[hathach/tinyusb] Issue opened: #2436 Toggling between HID_PROTOCOL_BOOT and HID_PROTOCOL_REPORT is blocking the mouse interface on Logitech M185 and M150

Operating System

Linux

Board

PIC0 RP2040

Firmware

ex_host_bare_api.zip

What happened ?

Toggling between report and boot mode on mouse interface will block the keyboard interface on logitech wireless keyboard
Tested: K270/M185 and K220/M150

How to reproduce ?

Connect one of these wireless logitech K270/M185 and K220/M150.

Press R to set report mode on mouse interface
Or B to set boot ...

#
IngHK
[hathach/tinyusb] Issue opened: #2437 CDCh tuh_cdc_mounted() returns true before process config is completed (also HIDh?)

Operating System

Others

Board

Firmware

What happened ?

If an application uses tuh_cdc_mounted() to check whether a CDC device is mounted, it will be reported "true" before the process config is completed.
The application could then disrupt the process config or the application would not yet be able to work with the CDC device.
tuh_cdc_mount_cb() is correctly called in set_config_complete() after the process config has been completed.
the hid host ma...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
maehw
[hathach/tinyusb] Issue opened: #2439 Unexpected behaviour for USB Video Class (UVC) example on RP2040 (Raspberry Pi Pico)

Operating System

MacOS

Board

Raspberry Pi Pico (RP2040)

Firmware

examples/device/video_capture
(built from pico-examples for a Raspberry Pi Pico (probably works for other RP2040 targets as well))

What happened ?

Introduction

Thanks for the tinyusb project! I stumbled across it a few years ago but I came back here because of Sebastian's GB Interceptor ("Capture or stream Game Boy gameplay footage via USB without modifying the Game Boy.", https://github.com/Staacks/...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2435: Enhance UVC decriptors and example

As you said, I agree that defining descriptors using macros was very difficult. I think the method you suggested is very wonderful. Above all, I think it is good that the compiler’s type checking can be used, so that errors can be detected earlier.

thank you very much for your review, glad that makes sense. The macro template in example will be still kept there for referennce

fallow birchBOT
fallow birchBOT
#
hassan22EL
[hathach/tinyusb] Issue opened: #2440 host USB with SSI in RP2040

Operating System

Windows 10

Board

RP2040 pico

Firmware

usb host

What happened ?

rp2040 host usb and xip ssi problem the rp2040 work a host usb when attached the usb device the program stop after the replace this function (flash-bulk-read) by memcpy and re-try the system normal work note i-used this function to fast read data from flash memory and this function allocate into RAM

please help me to resolve this problem and the code is blew

How to reproduce ?

`...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New review comment on pull request #2429: CDCh PL2303 support

oh, that's a good question...
I initially adopted it from Linux.
There seems to have been derivatives in the early days of the PL2303, where the EPs of one CDC port were distributed over two interfaces. This is no longer relevant for current derivatives. I removed these quirks.
And in pl2303_open() it is checked anyway whether the correct number of EPs is available.

I also removed PL2303_QUIRK_UART_STATE_IDX0 because it only affects the interrupt EP, which we don't use.

We should onl...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
moc32
[hathach/tinyusb] New comment on issue #2436: Toggling between HID_PROTOCOL_BOOT and HID_PROTOCOL_REPORT is blocking the mouse interface on Logitech M185 and M150

I have tested the example app and it works with other combo devices and single keyboard and mouse connected over a hub. The only difference with logitech wireless devices is the wMaxPacketSize which is 20 for the mouse endpoint and 8 for the keyboard.
For the other tested devices wMaxPacketSize is less than or equal to 8 bytes.

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] Issue opened: #2444 CH34x ch34x_set_line_coding() bug

Operating System

Linux

Board

Firmware

What happened ?

ch34x_set_line_coding() handles user_data in wrong way:

    if (user_data) {
      user_data = result;
    }

correct is:

    if (user_data) {
      *((xfer_result_t*) user_data) = result;
    }

I'll create PR soon

How to reproduce ?

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

Screenshots

No response

I have checked existing issues, dicussion and documenta...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
UKTailwind
[hathach/tinyusb] Issue opened: #2447 tuh_hid_interface_protocol returns incorrect value

Operating System

Windows 11

Board

RP2040

Firmware

V0.16.0
NB: works correctly in 0.15.0

What happened ?

Scenario 1:
Plug in a keyboard, tuh_hid_interface_protocol returns the correct value - 1
Then plug in a mouse, tuh_hid_interface_protocol returns the correct value - 2
Then plug in a gamepad, tuh_hid_interface_protocol returns the value for a mouse - 2 SHOULD BE 0

Scenario 2:
Plug in a gamepad, tuh_hid_interface_protocol returns the correct value - 0
Then p...

fallow birchBOT
fallow birchBOT
#
nerdyscout
[hathach/tinyusb] New comment on pull request #2293: Add PlatformIO manifest

thank you @Yveaux !
I did add TinyUSB to the library as it should allow to use its hardware abstraction.
Using it as an external library now i run into exactly this issue bsp/* not been build as it is neither part of my project nor part of TinyUSB/src.

#include "bsp/board_api.h" // can not be found from within my project, therefor init fails
#include "tusb.h"

//------------- prototypes -------------//
static void cdc_task(void);

/*------------- MAIN -------------*/
i...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-esp-build
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2429 CDCh PL2303 support

thank you for another great PR for serial host. Unfortunate, Lunar New Year (aka TET) is super close and I don't have time to review/test out this PR in a few weeks or so. Meanwhile, would you mind fixing the CI build with other ports. It is probably suppress warnings since some ports has stricter warning flags than others. Thak you

fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2449: fix #2448 CH34x ch34x_set_line_coding() callback bug
  • the two-stages ch34x_set_line_coding() forgets the requested complete_cb to be called after 2nd stage. so complete_cb is now stored in p_cdc->requested_complete_cb

Have you tried passing the callback and verify that it is not invoked ?

  • another bug: missing p_cdc->user_control_cb = complete_cb; in ch34x_set_data_format()

I remember don't assign calback for this intentionaly.

Yes, and this is the starting point for all further issues.
`tuh_cdc_set_...

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2429: CDCh PL2303 support

thank you for another great PR for serial host. Unfortunate, Lunar New Year (aka TET) is super close and I don't have time to review/test out this PR in a few weeks or so. Meanwhile, would you mind fixing the CI build with other ports. It is probably suppress warnings since some ports has stricter warning flags than others. Thak you

OK, thanks for your hint, I fixed the errors/warnings

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
roel0
[hathach/tinyusb] Issue opened: #2456 Don't receive packets immediately when usb packet equals CFG_TUD_ENDPOINT0_SIZE

Operating System

Linux

Board

STM32U575

Firmware

938cae818

What happened ?

I dont receive USB packets when they are the maximum packet size CFG_TUD_ENDPOINT0_SIZE immediately. I do receive when the host sends more bytes. (The host is a linux PC). So it's seem that the incoming ZLP isn't processed.

If I trigger handle_epout_irq manually, the packet is still not processed. So the packet is for some reason not provided yet by the hardware.

How to reproduce ?

USB de...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
roel0
[hathach/tinyusb] New comment on issue #2456: Don't receive packets immediately when usb packet equals CFG_TUD_ENDPOINT0_SIZE

Well,

  1. If I use the the official STM32 USB library (yikes), it works fine and I get 3 usb interrupts when receiving a 64 bytes from my linux host
  2. If I use tinyusb I only get one usb interrupt, which handles the 64 bytes packet. But no second interrupt to complete the transfer

-> So it's seems that the the stm32u575 is not correctly initialised by tinyusb? Still need to take a deeper look

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
WilheJo
[hathach/tinyusb] New comment on pull request #1537: When clearing an endpoint stall, reset DTOG

@hathach could you possibly review this PR as well?

I process 1,2MSPS (yes, I know, the ADC is a little overclocked) in the background.
This data is streamed via a ISO transfer to the PC.
Besides this, I have usbtmc for other purposes.
Additionally, there's a MSC interface for writing calibration data, update,...
PR #2392 fixes most problems I had so far, but.....

This works ok, but I get timeouts under linux from py-usbtmc during stress-testing.

Applying this change fixes at lea...

fallow birchBOT
#
IngHK
[hathach/tinyusb] Pull request opened: #2459 CDCh ACM fixes and small changes
  • added check of xfer->result in acm_process_config()
  • missing TU_VERIFY(p_cdc->acm_capability.support_line_request); in acm_set_data_format() => moved it to common acm_set_line_coding()
  • added missing check of data bit quantity in acm_set_line_coding()
  • better explanation of CFG_TUH_CDC in misc. example tusb_config.h
  • TU_LOGs cleaned and harmonized with other drivers
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pmiettinen
[hathach/tinyusb] Pull request opened: #2462 Draft: Add support NXP Kinetis K28FA

This is an attempt to add support for NXP Kinetis K28FA. Effort is mostly based on the existing ports for kinetis_k32l2, mimxrt1170_evkb and the frdmk28fa_dev_composite_cdc_vcom_cdc_vcom_bm example in NXP MCUXpresso.

Current state of the port

Build OK:

tinyusb$ make -C examples/device/cdc_dual_ports/ BOARD=frdm_k28fa15 LOG=2 all
...
CREATE _build/frdm_k28fa15/cdc_dual_ports.hex

   text    data     bss     dec     hex filename
  26436     152   10260   36848    8f...
fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2461: removed redundant result handling in CDCh Control Endpoint API

I'm currently making extensive changes to the CDC host to add new support for PL2303, expand FTDI and CP210x, and simplify and reduce the code size.
It might make more sense to review just one PR with all the changes rather than several smaller PRs.
If you agree then I'll withdraw this PR and create a "big" PR soon.
I will also carry out a complete test of all devices.
I have all of them (ACM, FTDI, CP210x, CH34x, PL2303) as real HW in various versions (RS232/TTL, different chip versions ...

#
IngHK
[hathach/tinyusb] New comment on pull request #2459: CDCh ACM fixes and small changes

I'm currently making extensive changes to the CDC host to add new support for PL2303, expand FTDI and CP210x, and simplify and reduce the code size.
It might make more sense to review just one PR with all the changes rather than several smaller PRs.
If you agree then I'll withdraw this PR and create a "big" PR soon.
I will also carry out a complete test of all devices.
I have all of them (ACM, FTDI, CP210x, CH34x, PL2303) as real HW in various versions (RS232/TTL, different chip versions ...

#
IngHK
[hathach/tinyusb] New comment on pull request #2451: CP210x CDCh upgrade

I'm currently making extensive changes to the CDC host to add new support for PL2303, expand FTDI and CP210x, and simplify and reduce the code size.
It might make more sense to review just one PR with all the changes rather than several smaller PRs.
If you agree then I'll withdraw this PR and create a "big" PR soon.
I will also carry out a complete test of all devices.
I have all of them (ACM, FTDI, CP210x, CH34x, PL2303) as real HW in various versions (RS232/TTL, different chip versions ...

#
IngHK
[hathach/tinyusb] New comment on pull request #2449: fix #2448 CH34x ch34x_set_line_coding() callback bug

I'm currently making extensive changes to the CDC host to add new support for PL2303, expand FTDI and CP210x, and simplify and reduce the code size.
It might make more sense to review just one PR with all the changes rather than several smaller PRs.
If you agree then I'll withdraw this PR and create a "big" PR soon.
I will also carry out a complete test of all devices.
I have all of them (ACM, FTDI, CP210x, CH34x, PL2303) as real HW in various versions (RS232/TTL, different chip versions ...

#
IngHK
[hathach/tinyusb] New comment on pull request #2429: CDCh PL2303 support

I'm currently making extensive changes to the CDC host to add new support for PL2303, expand FTDI and CP210x, and simplify and reduce the code size.
It might make more sense to review just one PR with all the changes rather than several smaller PRs.
If you agree then I'll withdraw this PR and create a "big" PR soon.
I will also carry out a complete test of all devices.
I have all of them (ACM, FTDI, CP210x, CH34x, PL2303) as real HW in various versions (RS232/TTL, different chip versions ...

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #2463 nrf5x: Handle ISOOUT CRC errors

Describe the PR
NRF5x USB controller can detect ISO OUT CRC errors. In such case USBEVENT is signaled with EVENTCAUSE_ISOOUTCRC set. Even if controller detects corrupted ISO OUT packet it allows to data transfer from endpoint to RAM however packet is corrupted and code could just as well drop packet altogether.

With current implementation incoming ISO OUT packets were put in FIFO and exact information how much data already in FIFO is correct was hard to keep track of.
If was observed...

fallow birchBOT
#
karlp
[hathach/tinyusb] Issue opened: #2464 kinetis frdmk32l2a4 device examples fail to enumerate / don't work (FIX AVAILABLE)

Operating System

Linux

Board

frdmk32l2a4

Firmware

examples/device/cdc_msc

What happened ?

The clock config file used is wrong. I'm not sure how it ever worked, but perhaps the defaults used to be different.
The board makefile here: https://github.com/hathach/tinyusb/blob/master/hw/bsp/kinetis_k32l2/boards/frdm_k32l2a4s/board.mk#L11 is including the "project_template" clock_config.c file for the device "K32L2A4S" which is here: https://github.com/hathach/mcux-sdk/blo...

#
karlp
[hathach/tinyusb] New comment on issue #2464: kinetis frdmk32l2a4 device examples fail to enumerate / don't work (FIX AVAILABLE) 
diff --git a/hw/bsp/kinetis_k32l2/boards/frdm_k32l2a4s/board.mk b/hw/bsp/kinetis_k32l2/boards/frdm_k32l2a4s/board.mk
index f69700139..851968794 100644
--- a/hw/bsp/kinetis_k32l2/boards/frdm_k32l2a4s/board.mk
+++ b/hw/bsp/kinetis_k32l2/boards/frdm_k32l2a4s/board.mk
@@ -8,8 +8,8 @@ CFLAGS += -Wno-error=unused-parameter -Wno-error=redundant-decls -Wno-error=cast
 # All source paths should be relative to the top level.
 LD_FILE = $(MCU_DIR)/gcc/K32L2A41xxxxA_flash.ld
 
-SRC_C += \
-...
fallow birchBOT
#
jerpa77
[hathach/tinyusb] Pull request opened: #2466 TinyUSB stack ported to MCXA and MXCN freedom boards.

TinyUSB stack ported to MCX A and MXC N freedom boards.

Notes

  1. MCX A and MCX N families created under hw/bsp folder. Due to differing compiler options required by different versions of ARM Cortex M-33 for MCX A and MCX N, they were not grouped together in the same family.

  2. Build code for make and cmake tools added under example/build_system to support the ARM Cortex M-33 core with no DSP and no FPU.

  3. Since the NXP SDK repository is not up to date yet, the tools/get_dep...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Lotharyx
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

Well, here I am again. It's been a while; the work to try to get this working was shelved for a while. Now it's back on my plate.

What I've done most recently is do a git reset --hard and git pull on my checkout of tinyusb. That seems to have brought in a lot of changes that look like they're meant to provide STM32H5xx support.

I've gone through some example code that @sckid1108 very kindly provided, looking for differences between his and mine, and reconciled as many as I could ...

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] Issue opened: #2469 compiler warning tusb_fifo.c -> missing default: break;

Operating System

Linux

Board

Firmware

What happened ?

../tinyusb/src/common/tusb_fifo.c: In function '_ff_push_n':
../tinyusb/src/common/tusb_fifo.c:162:3: warning: switch missing default case [-Wswitch-default]
162 | switch (copy_mode)
| ^~~~~~

How to reproduce ?

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

Screenshots

No response

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checke...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
dmalnati
[hathach/tinyusb] New comment on issue #435: "Set Address failed" error on Windows

I am adding the #define CFG_TUSB_DEBUG 3 logging for the both scenarios above (I hadn't realized I could enable this before).

Diff between bcdUSB = 0x0200 and bcdUSB = 0x0210

This image is the first of 4 sequences of the same pattern.

It is showing that in the bcdUSB = 0x0210 case, the BUS RESET and USBD Bus Reset : Full Speed don't occur, also that the USBD Setup Received bytes change from 00 05 31 ... to 00 05 25 ..., but I do...

fallow birchBOT
#
Marcus2060
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi, great work,
very nice feedback method improvement on Tinyusb class Audio !
I Have implemented the feedback method FIFO_COUNTER (stereo 16 bit, 48KHz) on a my RP2040 hardware with I2S DAC with success .. but ...
I observe a good audio USB reproduction on Windows but the system crashes on MAC computer...???
If, instead, I remove only the feedback EP, the system It's starting to work on MAC too ! But obviously not sync ...

Could this be due to the fact that macOS does not accept this ...

fallow birchBOT
fallow birchBOT
#
Protoxy22
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi, great work, very nice feedback method improvement on Tinyusb class Audio ! I Have implemented the feedback method FIFO_COUNTER (stereo 16 bit, 48KHz) on a my RP2040 hardware with I2S DAC with success .. but ... I observe a good audio USB reproduction on Windows but the system crashes on MAC computer...??? If, instead, I remove only the feedback EP, the system It's starting to work on MAC too ! But obviously not sync ...

Could this be due to the fact that macOS does not accept thi...

fallow birchBOT
#
mastupristi
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

I observe a good audio USB reproduction on Windows but the system crashes on MAC computer...??? If, instead, I remove only the feedback EP, the system It's starting to work on MAC too ! But obviously not sync ...

How did you get it working on Windows?
I have interface 1 containing the data endpoint OUT and the feedback endpoint IN. Then I have interface 2 containing only the data endpoint IN.
On Linux I can see it working (I still have to validate the absence of glitches), and with wir...

fallow birchBOT
#
mastupristi
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

I recommend you the section "Feedback for Asynchronous Output Streams" in https://developer.apple.com/library/archive/technotes/tn2274/_index.html

Do you know whether Windows also has such behavior?

I would also recommend you to test to add "TUSB_ISO_EP_ATT_IMPLICIT_FB" in your Standard AS Isochronous Audio Data Endpoint Descriptor

I have interface 1 containing the data endpoint 1 OUT and the feedback endpoint 1 IN. Then I have interface 2 containing only the data endpoint 2...

fallow birchBOT
fallow birchBOT
#
Protoxy22
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi @mastupristi, can you show me your tusb_desc.c and tusb_desc.h if you have them ?
I didn't use this fifo counting feedback branch yet, so I'm not sure if my suggestions could work in this case.

After some hindsight, my bad, I think changing any endpoint to implicit feedback is a non-sense in this situation, because the whole branch is about a feedback endpoint which is necessarily explicit.

In the example [uac2_speaker_fb](https://github.com/HiFiPhile/tinyusb/tree/rx_fb/exam...

fallow birchBOT
#
mastupristi
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi @mastupristi, can you show me your tusb_desc.c and tusb_desc.h if you have them ? I didn't use this fifo counting feedback branch yet, so I'm not sure if my suggestions could work in this case.

I am also not using the counting fifo method. I tried the rx_fb branch but in the end we went back to the main repo branch. We calculate the feedback "by hand," and it proves very reliable even in tests where we vary the clock of our peripheral. We see that the host "chases" our clock suf...

fallow birchBOT
fallow birchBOT
#
gemarcano
[hathach/tinyusb] Pull request opened: #2474 Add critsec to rp2040 xfer, check endpoint status

Describe the PR
hw_endpoint_lock_update is unimplemented for the rp2040 port. This PR takes a stab at implementing it. Without it, if the USB port is disconnected, say with tud_disconnect, a race condition can happen where a transfer is in progress and the USB IRQ can fire, calling reset_non_control_endpoints and leaving the ongoing transfer in a bad state, as it tries to access endpoint data structures that are now zero'd.

While debugging that main issue, I also found some case...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
acscd
[hathach/tinyusb] Issue opened: #2478 (RP2040) tud_connected() and tud_mounted() stay true after disconnected

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

#include "Adafruit_TinyUSB.h"

void setup()
{
	pinMode(LED_BUILTIN, OUTPUT);
	Serial.begin(115200);
	Serial1.begin(115200); //for debug
}

void loop()
{
	digitalWrite(LED_BUILTIN, tud_connected());
}

What happened ?

tud_connected() and tud_mounted() correctly return FALSE before USB is connected, and TRUE when connected. However, they continue to return TRUE indefinitely after USB is no long...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2466 TinyUSB stack ported to MCXA and MXCN freedom boards.

Thank you very much for your PR. It looks great, though there is some change request below:

MCX A and MCX N families created under hw/bsp folder. Due to differing compiler options required by different versions of ARM Cortex M-33 for MCX A and MCX N, they were not grouped together in the same family.

besides the DSP/FPU option, is there any other difference, we can solve this by either using the MCU_VARIANT check in family.mk/cmake or just set the correct CPU_CORE in the board.mk/cm...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-ohci-volatile-2318
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-k32l2-clock
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
eightycc
[hathach/tinyusb] Pull request opened: #2484 video_device: fix uninitialized variable warning

Describe the PR
Fixes may be used uninitialized compiler warning for variable interval_ms when building at optimization level -Og. Compiler is GCC 13.2.

Additional context

../../lib/tinyusb/src/class/video/video_device.c: In function '_negotiate_streaming_parameters':
../../lib/tinyusb/src/class/video/video_device.c:578:36: error: 'interval_ms' may be used uninitialized [-Werror=maybe-uninitialized]
  578 |         payload_size = (frame_size + interval_ms - 1) / in...
fallow birchBOT
#
Kilklang26
[hathach/tinyusb] Issue opened: #2485 USB Audio Mic is unusable if tud_task isn't called thousand times a second (missed packets?)

Operating System

Windows 10

Board

STM32F4

Firmware

custom firmware

What happened ?

Audio Mic works with the base example where the MCU does nothing but calling tud_task. However, any real use case involves other tasks processed by the MCU. Any processing that takes too long without calling tud_task (haven't checked exactly, but seems close to a millisecond or a few hundred us), and the received audio data on the computer is corrupted (zeros in place of the real audio da...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-cdc_msc_freertos-example
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2171: Invoke power state change on DCD_EVENT_BUS_RESET

Had some time again recently to check this issue out...

The problem is that when a TinyUSB device is used on an active USB hub it don't react properly when the host is either shutdown or disconnected from the hub. In that case the hub will may provide a single-ended zero signal on both data wires resulting in a continuous reset state for the device while the device is still being powered.

If the device was in the suspended state before the tud_resume_cb was never invoked while `tud_...

fallow birchBOT
#
IngHK
[hathach/tinyusb] Pull request opened: #2488 CHCh Upgrade: Improved FTDI and CP210x support, add PL2303 support, bugfixes

This PR is the kick-off of the series of single commits, which should result in the following improvements:

  • Improved support of FTDI: support of all popular types (B/R/H, single and multiple channels), support of set line coding, data format, baudrate, line state
  • Improved support of CP210x: support of set line coding, data format, baudrate, line state
  • Added PL2303 support
  • Added continuation of enumeration after TU_ASSERT
  • Bugfix #2448 and several other bugfixes

I think, it'...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2168: Added support for the NXP K64 series

Why did you need the freertosconfig.h file? That seems unnecessary to have another copy of it? (and freertos demos work fine for me without it)

I'm still clearing our work with internal management, so it's not (very) publically shared yet unfortunately.

It is part of my new approach, previously there is 1 freertos (per example) for all ports. However, that makes it difficult to compile with IAR since freeRTOSConfig.h is included by IAR assembler which is very primitive and cannot ...

#
hathach
[hathach/tinyusb] New comment on pull request #2488: CHCh Upgrade: Improved FTDI and CP210x support, add PL2303 support, bugfixes

@IngHK thank you, though don't worry too much about the number of commits etc, just make it convenient for you. I don't always have time to review things (pending PRs is already long enough), but small change is indeed easier to review. So just group thing together as long as you think that make sense. The current PR only update comment, do you have anything to push more or you want to merge this as it is.

fallow birchBOT
fallow birchBOT
#
IngHK
[hathach/tinyusb] New comment on pull request #2488: CHCh Upgrade: Improved FTDI and CP210x support, add PL2303 support, bugfixes

@IngHK thank you, though don't worry too much about the number of commits etc, just make it convenient for you. I don't always have time to review things (pending PRs is already long enough), but small change is indeed easier to review. So just group thing together as long as you think that make sense. The current PR only update comment, do you have anything to push more or you want to merge this as it is.

Yes, I know, the first commit is pretty small, only to warm up ;-)
The next commi...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-non-crystal-less-ci-fs
#
hathach
[hathach/tinyusb] New comment on pull request #2488: CHCh Upgrade: Improved FTDI and CP210x support, add PL2303 support, bugfixes

@IngHK I appreciated your effor to break it out, but please push everything you think work best. Otherwise this make take several months to complete this whole process. I would like to merge portion of code once it is reviewed, and I may only have time to review this 1 or 2 times a month or so. Last time, I could focus on the PR since I need to get ch34x driver running for another paid works.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2462: Draft: Add support for NXP Kinetis K28FA

yeah, it should be ci_hs, try to compile with LOG=2 and checkout its output with either UART or segger rtt (LOGGER=RTT)

If I didn't totally misunderstand, this is what I've already done? Please check the PR description. Additionally, I have observed the dcd_int_handler behavior in debugger and saw ENDPTSETUPSTAT going unhandled in the current logic.

sorry my bad, look like it could be an clock/setup issue, each MCU will have slightly different clock setup. Unfortunately I ...

fallow birchBOT
#
IngHK
[hathach/tinyusb] New review comment on pull request #2488: CHCh Upgrade: Improved FTDI and CP210x support, add PL2303 support, bugfixes

Since the central flow code of tuh_cdc_set_control_line_state(), tuh_cdc_set_baudrate(), tuh_cdc_set_data_format() and tuh_cdc_set_line_coding() is identical and very tricky, it was outsourced to the common subfunction set_function_call(), which calls the regarding driver's function.
Here you see, why I moved the requested line coding and line state into p_cdc->requested..., because it also simplifies the parameter transfer from Control Endpoint API to Driver API independent of four differen...

fallow birchBOT
fallow birchBOT
#
GitHobi
[hathach/tinyusb] Issue opened: #2491 Unexpected ReportID

Operating System

Linux

Board

ESP32-S3-DevKit-1

Firmware

n/a

What happened ?

I'm trying to implement a FIDO2 USB Device. Using espressif-tinyUsb within Arudino IDE. Adapted standard CustomHIDDevice - just exchanged the report_descriptior with a FIDO2 compliant one - see attachment.
fido.txt
Communication is comming in using requestID 255 - which is not "visible" within the scatch and does not match the spec...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
tlyu
[hathach/tinyusb] Pull request opened: #2492 work around possible RP2040 erratum

RP2040 device controller does not seem to clear pending transactions configured in EP0 buffer controls when the host aborts a control transfer. This causes assertion failures, including when a buffer AVAILABLE flag set for a previous transfer causes an unexpected transaction completion.

Describe the PR
Fix assertion failures or panics in the RP2040 DCD when handling aborted control transfers.

Additional context
See adafruit/circuitpython#8824 for analysis and traces.

It's p...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
khking
[hathach/tinyusb] Issue opened: #2495 usbtmc error in freertos

Operating System

Windows 10

Board

stm32h743ii

Firmware

freertos 10.4
tinyusb-0.16.0

What happened ?

cannot execute

How to reproduce ?

cannot execute

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

USBD init on controller 0
sizeof(usbd_device_t) = 55
sizeof(tu_fifo_t) = 20
sizeof(tu_edpt_stream_t) = 36
TMC init
usbtmcd_init_cb 249: ASSERT FAILED
guid, gsnpsid, ghwcfg1, ghwcfg2, ghwcfg3, ghwcfg4
0x00002300, 0x4F54330A, 0x00000000, 0x229FE190, 0x03B8...

fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2171: Invoke power state changes on DCD_EVENT_BUS_RESET

Fixed some bugs...

  • The USB speed is now kept on a USB reset.
  • Repeating bus state events are now suppressed preventing that a spamming MCU can fills up the queue quickly.
  • Adding a fix for the DWC2 driver that the start of a reset is suppressed.

The later is related when such a device is connected to an active USB hub while that gets disconnected from the host. In that case the hub may continuously send a USB reset signal. Because it can take a long time until the reset state is...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
vestal matrix
#

Hi guys

#

Do you know how can i build a vendor host implementation

fallow birchBOT
#
jmark1m
[hathach/tinyusb] New comment on issue #1097: Update Code for Class Vendor_Host

I guess I did manage to get usb host to work just using the tinyusb submodule that comes with the pico 2040 sdk.

For my project it was known what devices were going to be plugged in to it so I assigned them fixed end points and didn't go through all of the things a host should do to assign endpoints.

But eventually I just sent data from my host to the device with this simple function.

Good luck.

bool hid_send( board::host_command_t command )
{
  tuh_xfer_t xfer =
  {
  ...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-tuh-hid-abort
#
Docfch
[hathach/tinyusb] Issue opened: #2501 Host Vendor Class API

Related area

Host Vendor Class API

Hardware specification

pico w, esp32 s3

Is your feature request related to a problem?

Hello Everyone,
I am currently working on a project where I use a USB cable for communication between my stm32 in vendor-specific device mode and a PC software with libusb, and I want to replace it with a connection of my board to the USB of the pico w or the esp32 s3 to communicate through WiFi.
For this, I wanted to know when will we have the complete h...

fallow birchBOT
fallow birchBOT
#
szsam
[hathach/tinyusb] Issue opened: #2502 Potential code typo in examples/device/uac2_headset

Operating System

Linux

Board

N/A

Firmware

examples/device/uac2_headset/src/main.c

What happened ?

https://github.com/hathach/tinyusb/blob/2720392a154dac5ff4529fbcc16c0a0718c9c8af/examples/device/uac2_headset/src/main.c#L234
The condition UAC2_ENTITY_SPK_FEATURE_UNIT looks unusual (it is always true). Is this intentional?

How to reproduce ?

N/A

Debug Log as txt file (LOG/CFG_TUSB_DEBUG=2)

N/A

Screenshots

No response

I have checked existing iss...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Marcus2060
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi,
I continued working with a Full-Speed USB audio system RP2040 48KHz 16 bit by using feedback explicit endpoint.
(TinyUSB with FIFO counter feedback mechanism).

I've done other experiments and I get the impression that the usbd_edpt_xfer() function on low-level stack doesn't work well when we try to send 3 bytes.
These are my two scenarios:

MAC:

  1. The system works fine with 10.14 feedback (CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION=1) but only if I set MaxPacketBytes=3 in ...
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

So, could the problem be on the low level of the Tinyusb stack when we try to send 3 bytes feedback via usbd_edpt_xfer() to Host ???

No it can't be, you also tested 3 bytes works on MAC.

If I use, instead, the same code of MAC (as above MaxPacketBytes = 3 in the descriptor) unfortunately the system stops working because the Audio class it is not enumerate on WIndows and I no longer see the card ... ???

It's true.

I tested the pico-playground usb_sound_card project (Pico boar...

fallow birchBOT
fallow birchBOT
#
Marcus2060
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi,
thank you for reply and sorry if I try to clarify better:

No it can't be, you also tested 3 bytes works on MAC.

No, my previous comment is precisely because I tested that the 3 bytes don't seem to work (see my pont 1, 2 about MAC):

  1. The system works fine with 10.14 feedback (CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION=1) but only if I set MaxPacketBytes=3 in the feedback descriptor.
  2. The system doesn't work if I try to send 3 Bytes (10.14) via usbd_edpt_xfer() but w...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: tuh-set-config-abort-all-ep
#
karlp
[hathach/tinyusb] New comment on pull request #2168: Added support for the NXP K64 series

I'm back from holidays, and this asserts (vApplicationStackOverflowHook 43: ASSERT FAILED ) when a hub is plugged in, with the examples/host/cdc_msc_hid_freertos example.

My local version (didn't get to a PR) works fine. I can't see what the difference would be (yet) but I'm obviously goin to have to find out :) Did this example work for you at all?

Related to the FreeRTOSConfig files, the newly added file is not even used at present. At least in the host/cdc_msc_hid_freertos. ...

fallow birchBOT
#
Marcus2060
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Sorry I've some problem understanding, you mean 3 Bytes && MaxPacketBytes=4 doesn't work ? How about 3 Bytes && MaxPacketBytes=3 ?

Below 4 different tests on MAC using 10.14 format:

  1. When (4 Bytes sent) && (MaxPacketBytes=4) -> Wrong Audio (I think the macOS recognize 16.16).
  2. When (3 Bytes sent) && (MaxPacketBytes=4) -> No Sync, some clicks.
  3. When (3 Bytes sent) && (MaxPacketBytes=3) -> No Sync, some clicks.
  4. When (4 Bytes sent) && (MaxPacketBytes=3) -> **Works...
#
Kilklang26
[hathach/tinyusb] Issue opened: #2505 Enabling feedback for USB microphone hangs

Operating System

Windows 10

Board

custom STM32F4

Firmware

Custom

What happened ?

Hello,
When I add feedback endpoint to my USB microphone application the device enumerates but hangs immediately after.

This is what I did :

  • Start from the USB 1 channel microphone example
  • Add TUD_AUDIO_DESC_STD_AS_ISO_FB_EP endpoint after the isochronous data endpoint and adapt descriptor size
  • Feedback endpoint number is set to the same as data endpoint. Data is an IN endpoint...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
JMattChiam
[hathach/tinyusb] Issue opened: #2509 Inconsistent Driver Errors on STM32F0

Operating System

Windows 10

Board

STM32F072 Custom Board

Firmware

STM32CubeIDE configured following #633 with tusb_config.h to use RHPORT 0 and USB Full Speed instead of High speed.

Main firmware:
examples/device/midi_test
usb_descriptors.c identical to example, other than changing product name.

What happened ?

I'm new to USB and trying to get my custom STM32F072 MIDI controller recognized by windows. I've followed the steps outlined in #633 for my needs and the...

fallow birchBOT
#
tlyu
[hathach/tinyusb] New comment on pull request #2492: work around possible RP2040 erratum

Standard timeout for control requests with no data stage is 50ms. The second SETUP arrives within the same millisecond as the ACK for the first. This is more likely the host application (probably actually the kernel serial driver) cancelling the control request IRP before completion.

I don't think we can depend on the second control request being identical to the first, in that case, so it's safer to process both. Skipping the data or status stages when the interrupt flags show that a SETU...

fallow birchBOT
#
tlyu
[hathach/tinyusb] New comment on pull request #2492: work around possible RP2040 erratum

USB 2.0 §5.5.5

If a Setup transaction is received by an endpoint before a previously initiated control transfer is completed, the device must abort the current transfer/operation and handle the new control Setup transaction. A Setup transaction should not normally be sent before the completion of a previous control transfer. However, if a transfer is aborted, for example, due to errors on the bus, the host can send the next Setup transaction prematurely from the endpoint’s perspective.

fallow birchBOT
fallow birchBOT
#
lijunru-hub
[hathach/tinyusb] Issue opened: #2513 [UVC] Support device with multiple VS and VC interface

Related area

Class UVC

Hardware specification

esp32sx

Is your feature request related to a problem?

I want to define a UVC device with two VS (Video Streaming) interfaces, capable of simultaneously transmitting two video streams. However, the current class UVC driver does not support installing all VS VC (Video Control) interfaces.
I've identified two main issues and made modifications to the source code, enabling the simultaneous opening of two VS (Video Streaming) interfac...

#
Marcus2060
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

Hi,

I agree it seems strange but I don't see any issue in TUSB side (maybe something wrong in RP2040 porting ?), could you use Wireshark USB capture to see what happened ?

  1. Yes, thank you for your suggestion, I tried with Wiresharc and my board connected to Windows: The messages LOG shows that 3 bytes messages of feedback are sent from the TinyUsb stack to Host correctly on size and value !

  2. So the problem seems to be a different behavior of TinyUsb Audio Class 2.0 between Win...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Lurcy38
[hathach/tinyusb] Pull request opened: #2515 Bug fix for

dcd_stm32_fsdev.c: Fix a bug seen with stm32h5xxx when the driver is compiled with CubeIde O1/O2/O3
patch fixes a bug discovered when I build my application for the speed. The new timing introduces a bug in the function pcd_get_ep_rx_cnt().
The function doesn't return the correct value.
After discussion with my colleagues, they told me that this issue is fixed with a workaround.
This workaround is ported from stm32h5xx_hal_pcd.h : PCD_GET_EP_RX_CNT (ST HAL for H5)
Issue observed on...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: minor-code-format
fallow birchBOT
#
Gadgetoid
[hathach/tinyusb] New comment on pull request #1702: UAC2 supports interrupt-endpoint for providing control-change notifications to the host

Has anyone got this working?

I've attempted to reconcile these changes with the version of tinyusb used by Pico SDK, but at best nothing happens and at worst I can reliably crash my board. This happens when I attempt to adjust the volume from the host after calling tud_audio_int_ctr_n_write .

There's an awful work in progress mess here:

https://github.com/Gadgetoid/pico-tinyusb-i2s-speaker/commit/84c127f5296ab82b9262720d78d13360cd917d4f

This doesn't show my futile modifications ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2168: Added support for the NXP K64 series

~You also removed the pinmuxing, are you sure this actually works with uarts after those changes?~ Well, the uart still works, with LOGGER=uart, so I guess mcux is doing pinmuxing automatically....

pin muxing is done by boards/pin_mux.c which I use mcupinconfig to generate.

Related to the FreeRTOSConfig files, the newly added file is not even used at present. At least in the host/cdc_msc_hid_freertos. I added #error calls, and it's still using the standard one from the example. (ho...

fallow birchBOT
#
learmj
[hathach/tinyusb] Issue opened: #2517 panic on hid device enumeration with a particular hub

Operating System

Others

Board

Raspberry Pi Pico

Firmware

examples/host/msc_file_explorer

What happened ?

A customer sent us a product they designed based on our RP2040. They also supplied a usb hub which they reported caused problems with hid device enumeration when the hub was connected to their product. Debugging the problem on one of our Pico boards with our SDK, I can see that the tip of tinyUSB today exhibits the problem which is that there is a panic in tinyUSB wh...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2462: Draft: Add support for NXP Kinetis K28FA

By the way. I am seeing the same behavior on NXP MIMXRT1160-EVK secondary processor (M4). The primary core or M7 is working as expected. Just in case you have access to these boards more easily.

Oh, I don't have rt1160 but got 1170. Let me try to see if I could make a quick switch from m7 to m4 to compile with. However, they can be two different issues with different clock/pin configuration since these MCUs are totally different.

fallow birchBOT
fallow birchBOT
#
pmiettinen
[hathach/tinyusb] New comment on pull request #2462: Draft: Add support for NXP Kinetis K28FA

By the way. I am seeing the same behavior on NXP MIMXRT1160-EVK secondary processor (M4). The primary core or M7 is working as expected. Just in case you have access to these boards more easily.

Oh, I don't have rt1160 but got 1170. Let me try to see if I could make a quick switch from m7 to m4 to compile with. However, they can be two different issues with different clock/pin configuration since these MCUs are totally different.

1170 should be fine. As a background, I did the M...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Lurcy38
[hathach/tinyusb] New comment on pull request #2515: Bug fix for

The pre-commit fails because the build doesn't produce .OUT , it seems that there is no relationship with my patches
my local build produce a fonctional .out on the board stm32h573i_dk
Could please tell me what is wrong ?
I noticed that with GCC cubeide, the build produces some warnings , especialy with __ARMCC_VERSION
in the initial H5 commit, i added -D __ARMCC_VERSION=0 as a workaround to remove this warning

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2515: Bug fix for

just re-run and it works now, I also notice @HiFiPhile try to re-run it a few time before. I guess action has some kind of issues previously. Let me try to reproduce the issue with O1 and freertos example, which example you are testing with ? Otherwise, it would be helpful if you could provide reference to Manual where it say some minimum cycle is required for accessing pma

fallow birchBOT
fallow birchBOT
#
Lurcy38
[hathach/tinyusb] New comment on pull request #2515: Bug fix for

Hello Tinyusb,
I didn’t reproduce the issue with examples such as uac2_headset using the same toolchain. (ie GCC CubeIDE in command line)
But the issue is clearly visible in our product.
tinyUsb examples implementations are minimalist, the tu_task() is called in a bare-metal loop with no other heavy tasks sing the CPU.
Our application is different in several points.

  1. The USB clocking probably different (using HSI48 + CRS)
  2. CPU at 250MHZ with loaded at 60% (signal processing)
  3. ...
fallow birchBOT
fallow birchBOT
#
tommie
[hathach/tinyusb] New comment on pull request #2494: Add notification support for device class USBTMC

Not a TMC expert, just to mention there is no buffering inside usbd_edpt_xfer(), you need to add buffer like how bulk endpoints did:

https://github.com/hathach/tinyusb/blob/9e674fa109348d97fb4280ac534be665f619a4d8/src/class/usbtmc/usbtmc_device.c#L129

Yes, I documented that the buffer must remain valid until the notification_complete callback, since that's what tud_usbtmc_transmit_dev_msg_data already does:

https://github.com/hathach/tinyusb/pull/2494/files#diff-0c276774d...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #2520: fix: uvc multiple interface support 
      uint8_t const *sbeg = (uint8_t const*)itf_desc + stm->desc.beg;
      uint8_t const *send = (uint8_t const*)itf_desc + stm->desc.end;
      if (send == _find_desc_itf(sbeg, send, _desc_itfnum(sbeg), 1)) {
        TU_VERIFY(_open_vs_itf(rhport, stm, 0), 0);
      }

I noticed a typo in the original code. It should be send instead of end. I apologize for the inconvenience. If you could change it to send to achieve the expected behavior, I would appreciate it.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #2520: fix: uvc multiple interface support

@hathach

Just a heads up, the pre-commit action is failing. I'm not sure if we should go ahead with the merge. Could you check it out when you get a chance?

I've confirmed that the pre-commit has successfully run on my local WSL machine. In my estimation, I believe the reason why the GitHub action's pre-commit failed is due to the test environment. I think there are no issues with this PR.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-uvc-hardfault
#
hathach
[hathach/tinyusb] Pull request opened: #2526 Fix uvc hardfault

Describe the PR
Currently streaming buffer is shared/re-used when doing probe/commit control, since it is possible for dynamic stream setting, this could lead to memory corruption and lead to hardfault.

image

Discovered while adding UVC support for Arduino/Circuitpython, I found out that sometime it crashes. Which can be quite easily reproduced by simply launch cheese on Linux, or device mana...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-tuh-deinit
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2515 Bug fix for

thank you very much for the PR. After reviweinng your provided code from stm hal driver and a bit of reading (go through Manual but it does not give any hint). This PR is totally spot-on

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #2530 Add tuh deinit

Describe the PR
Start adding tuh_deinit(), this also need

  • hcd deinit() not implemented on any controller yet.
  • class driver deinit()
  • tu_edpt_stream_deinit()
  • semaphore/mutex/queue delete
  • add .name to usbh_class_driver_t without the need of enabling log, also change init() signature from void to bool.
  • add TUSB_VERSION_BUILD that increased when API changes within an release
  • other code reformat
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #2526: Fix uvc hardfault

Thank you for investigating this issue.

When implementing UVC, I thought that once state transition from PROBING to STREAMING, the buffer used for PROBING becomes unnecessary and can be reused. So, I implemented using the same ep_buf for both PROBING and STREAMING.

Anyway, this issue actually existed and was resolved by your patch. I think that approach is correct.

fallow birchBOT
#
Gadgetoid
[hathach/tinyusb] New comment on issue #1697: Interrupt-endpoint for audio class

If you don't need any newer features than my fork (or official support from the project), you could potentially use my fork.

Unfortunately I think I need both, I'd hoped I could get away with cherry-picking some bits from your fork but so far it's mostly lead to eclectic bugs and crashes.

Thanks for blazing this trail, anyway, there are surely others out there like me who think using media keys to have the host control the volume is barbaric 😆

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2333: dwc2: add endpoint allocation support.

@kkitayam When you have time could you add ISO endpoint allocation support to UVC class ?

The idea is to avoid USB buffer alloc/free at runtime as it's hard to manage buffer on some devices.

It's pretty simple:

fallow birchBOT
fallow birchBOT
#
greenscreenflicker
[hathach/tinyusb] New comment on pull request #2362: Add CH32V20x USB OTG/FS Driver

I would apprechiate here a warning in compile time, not in runtime...

 void board_init(void) {
    __disable_irq();

#if CFG_TUSB_OS == OPT_OS_NONE
    SysTick_Config(SystemCoreClock / 1000);
#endif


    switch (SystemCoreClock) {
        case 48000000:  RCC_USBCLKConfig(RCC_USBCLKSource_PLLCLK_Div1); break;
        case 96000000:  RCC_USBCLKConfig(RCC_USBCLKSource_PLLCLK_Div2); break;
        case 144000000: RCC_USBCLKConfig(RCC_USBCLKSource_PLLCLK_Div3); break;
        de...
#
greenscreenflicker
[hathach/tinyusb] New comment on pull request #2362: Add CH32V20x USB OTG/FS Driver

I'm just trying to compile the Pull request. I'm documenting here my process.

  1. I'm getting an error in dcd_int_handler(uint8_t rhport) . That a semicolon is missing after a declaration.
    switch (token) {
    case PID_OUT:;
    uint16_t rx_len = USBOTG_FS->RX_LEN;
    update_out(rhport, ep, rx_len);
    break;

Some compilers don't like declaring a variable inside a switch/case. Added brackets to fix.

Fixed by additional semicolon... see PID...

fallow birchBOT
#
greenscreenflicker
[hathach/tinyusb] New comment on pull request #2362: Add CH32V20x USB OTG/FS Driver

Can you please give me some hints why I don't get enumeration. What could I do wrong?
I run it in Freertos, in a seperate task. It looks like this:

void task1_task(void *pvParameters)
{

    board_init();

    // init device stack on configured roothub port
    tud_init(BOARD_TUD_RHPORT);

    if (board_init_after_tusb) {
      board_init_after_tusb();
    }

    while (1) {
      tud_task(); // tinyusb device task
      tud_cdc_n_write_str(0,"Hello, World!\r\n");
    ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2328: UAC2: Implement feedback by fifo counting.

@Marcus2060 I come back to this.

So the problem seems to be a different behavior of TinyUsb Audio Class 2.0 between Windows, Linux (16.16 ok) and MAC (10.14 ok ... but with the trick MAXPacketBytes=3 ) .... ??

No the stack works (tries to) the same way across all OSes, the issue is some OS doesn't respect the UAC specification as I mentioned earlier.

The Rp2040 is a full-speed device and I don't need large audio streaming traffic. So would it be possible with the TinyUsb stack to...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
jay94ks
[hathach/tinyusb] New comment on issue #2537: `tud_cdc_rx_cb` callback is never called.

Please check the disassembly output of final binary.

https://github.com/hathach/tinyusb/blob/3ec22e24ed3e8169b7aa8bd51f86f95dda0e6002/src/class/cdc/cdc_device.c#L457

You can start with official examples on supported board, like adding following code to cdc_dual_ports example.

void tud_cdc_rx_cb(uint8_t itf) {
  static uint8_t state=0;
  board_led_write(state++);
}

10000664 <tud_cdc_rx_cb>:
10000664:	b510      	push	{r4, lr}
10000666:	b...
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #2537: `tud_cdc_rx_cb` callback is never called.

there is no reference which calls this callback cdcd_xfer_cb in full disassembly.

But it's there in your attached disassembly.

And even more, basic examples are all working well if descriptor has no HID + CDC combination.

So cdc_dual_ports works ? In the case of HID + CDC, does CDC data receive actually work (by tud_cdc_n_available and tud_cdc_n_read in main loop) ?

If the version of tinyusb in pico-sdk has corrupted, how can I replace it to other distribution?

You ...

fallow birchBOT
#
jay94ks
[hathach/tinyusb] New comment on issue #2537: `tud_cdc_rx_cb` callback is never called.

there is no reference which calls this callback cdcd_xfer_cb in full disassembly.

But it's there in your attached disassembly.
Yeah, but the instruction that calls the address of that function cannot be found.
And even more, I tested TUD_CFG_CDC value using vsprintf, and it says usb: cdc: 1.

tty_printf("usb: cdc: %d.\n", CFG_TUD_CDC);

And even more, basic examples are all working well if descriptor has no HID + CDC combination.

So `cdc_dual_po...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-auto-label
fallow birchBOT
#
Lurcy38
[hathach/tinyusb] New comment on pull request #2515: Bug fix for STM32H5 need few cycles for RX PMA descriptor to update

Comment : https://github.com/hathach/tinyusb/pull/2515#pullrequestreview-1954563527

Hello Tinyusb team

Happy this patch fixes a potential issue for other MCU families.

I would like to notice, I found a second issue on synopsis IP ( for H735 & H757), but I didn’t provide the path because the issue vanished with an rebase upstream. But it was characterized with a previous build in CubeIDE and -O3 -oFast.
The characterization was an in an infinite loop in reset_core()
->while (dwc2->g...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2515: Bug fix for STM32H5 need few cycles for RX PMA descriptor to update

Comment : #2515 (review)

Hello Tinyusb team

Happy this patch fixes a potential issue for other MCU families.

I would like to notice, I found a second issue on synopsis IP ( for H735 & H757), but I didn’t provide the path because the issue vanished with an rebase upstream. But it was characterized with a previous build in CubeIDE and -O3 -oFast. The characterization was an in an infinite loop in...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #2541 MAX3421 (host) and NAK handling

Discussed in https://github.com/hathach/tinyusb/discussions/2510

Originally posted by IngHK March 5, 2024
I examined the CPU and USB usage on my host with STM32F401 (ARM M4 CPU 84 MHz) and MAX3421 (SPI 21 MHz).

With a CDC ACM device I saw that the CPU, SPI and USB are mostly busy handling the input stream endpoint.
The endpoint responds with NAK because there is no new data, and handle_xfer_done() in hcd_max3421.c causes the same stream to be repeated immediately (no ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
jay94ks
[hathach/tinyusb] New comment on issue #2537: `tud_cdc_rx_cb` callback is never called.

I updated lib/tinyusb of pico-sdk to latest release.

PS C:\ARM\RP2040\pico-sdk> git submodule status
 72ef1732c954d938091467961e41f4aa9b976b34 lib/btstack (v1.4-2371-g72ef1732c)
 8ef38a6d32c54f850bff8f189bdca19ded33792a lib/cyw43-driver (v1.0.1)
 239918ccc173cb2c2a62f41a40fd893f57faf1d6 lib/lwip (STABLE-2_1_0_RELEASE-548-g239918cc)
 a77287f8fa6b76f74984121fdafc8563147435c8 lib/mbedtls (v2.28.1-36-ga77287f8f)
 86c416d4c0fb38432460b3e11b08b9de76941bf5 **lib/tinyusb (0.15.0)**
...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421-hcd-deinit
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hil-pi4-usbreset-hub2.0
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2515: Bug fix for STM32H5 need few cycles for RX PMA descriptor to update

yeah, H5 running at max 250Mhz, which is 4ns per cycle, the above loop do check, minus, then jump which take 3 cycles per run, therefore only delay 3410 = 120ns, I guess other interrupt handler contribute to the delay. We may consider to add back a few nop.

For low speed, it is definitley not enough, we should check the curent linkspeed and do delay accordingly, we need to burn some cycles anyway. I will push an update for this later.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: labeler-change-token
#
hathach
[hathach/tinyusb] New branch created: labeler-change-token-1
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: unplug_on_deinit
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: usbh-unroll-hub-remove
fallow birchBOT
#
duckylotl
[hathach/tinyusb] Pull request opened: #2549 forward declare board_millis for OPT_OS_CUSTOM

When porting examples to a custom OS the missing forward declaration of board_millis creates problems.
The forward declaration lets custom OS ports use the board_api.h for use of board_usb_get_serial and implement board_millis anywhere if needed with the correct signature.

The CDC examples include the bsp/board_api.h in usb_descriptors.c for use of board_usb_get_serial. board_api.h also includes implementation of board_delay which uses board_millis. But in case of `OPT_O...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ccrome
[hathach/tinyusb] Pull request opened: #2553 IMXRT: update linker scripts so that the code section does *not* star…

IMXRT: update linker scripts so that the code section does not start at 0x0.

Describe the PR
On those cpus that have the internal RAM start at 0x0, this sets the start of ram to 0x20, so that we can never end up with a valid piece of code living at address 0x0. That's a bad thing.

Additional context
This happens when you put stuff into CodeQuickAccess memory.

all of these linker scripts are directly from the mcu directory. The downside is that if the upstream mcu re...

fallow birchBOT
#
PwnVerse
[hathach/tinyusb] Issue opened: #2554 Add a check to see if device ID is correctly mapped before accessing it

Operating System

Linux

Board

Feather nRF52840 Express

Firmware

In the function board_get_unique_id from hw/bsp/nrf/family.c, here is the relevant section of the code -

size_t board_get_unique_id(uint8_t id[], size_t max_len) {
  (void) max_len;

#ifdef NRF5340_XXAA
  uintptr_t did_addr = (uintptr_t) NRF_FICR->INFO.DEVICEID;
#else
  uintptr_t did_addr = (uintptr_t) NRF_FICR->DEVICEID;
#endif

  const uint8_t* device_id = (const uint8_t*) did_addr;
  for...
fallow birchBOT
#
theosib
[hathach/tinyusb] Issue opened: #2555 Debug logging options not enabled by tusb_config.h, ep_dir_string not defined

Operating System

Others

Board

Raspberry PI Pico

Firmware

Custom firmware. You can see my whole project here: https://github.com/theosib/pico_vga/tree/main

What happened ?

I'm trying to debug TinyUSB. I want to find out why plugging in two USB devices at once results in no devices found. You can see more detail at https://github.com/raspberrypi/pico-sdk/issues/1680.

The first thing I did was set CFG_TUSB_DEBUG to 3 in my project's tusb_config.h, which is supposed to g...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #2555: Debug logging options not enabled by tusb_config.h, ep_dir_string not defined

The first thing I did was set CFG_TUSB_DEBUG to 3 in my project's tusb_config.h, which is supposed to get included by TinyUSB for various config options. But this didn't work. I think it's because src/common/tusb_debug.h doesn't have an #include directive for this.

Either pico-sdk or you messed up the includes.

undefined reference toep_dir_string'`

Semms 6dc714b has some left ups...

fallow birchBOT
fallow birchBOT
#
theosib
[hathach/tinyusb] Issue opened: #2556 Plug in two devices at once, no devices found, panic

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

Custom firmware. You can see my whole project here: https://github.com/theosib/pico_vga/tree/main

What happened ?

TinyUSB detects no new devices when two are plugged in at once

How to reproduce ?

Plug in a keyboard and mouse simultaneously.

I'm u...

#
theosib
[hathach/tinyusb] New comment on issue #2556: Plug in two devices at once, no devices found, panic

Those messages are a bit spammy. I reduced the debugging level to 2, and this is what I got:

[0:] USBH DEVICE ATTACH
Full Speed
[0:0] Open EP0 with Size = 8
Get 8 byte of Device Descriptor
[0:0] Get Descriptor: 80 06 00 01 00 00 08 00
Transfer complete
on EP 00 with 8 bytes: OK
Buffer complete
Transfer complete
on EP 80 with 8 bytes: OK
[0:0] Control data:
0000: 12 01 00 02 09 00 00 40 |.......@|
Buffer complete
Transfer complete
on EP 00 with 0 b...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-rp2-debug3
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ccrome
[hathach/tinyusb] New comment on pull request #2553: IMXRT: update linker scripts so that the code section does *not* star…

Totally true. I just got burned when I ended up with a function pointer at address 0x0.

Then when I did the callback thing:

if (funcptr)
funcptr()

funcptr was placed at 0x0 and never got called.

Not an issue for the examples since they don't place anything in fast ram. But when taking the examples and building off of them, it could be an issue.

It's totally fine to close this if not worthwhile.

fallow birchBOT
#
UKTailwind
[hathach/tinyusb] New comment on issue #2447: tuh_hid_interface_protocol returns incorrect value

I've solved this but does anyone read these issues? The issue is that tinyusb re-uses an itf without clearing the protocol and does not set it if the new protocol is zero

fix:

static hidh_interface_t* find_new_itf(void) { for (uint8_t i = 0; i < CFG_TUH_HID; i++) { if (_hidh_itf[i].daddr == 0) { _hidh_itf[i].itf_protocol=0; //Clear the protocol - needed if the new protocol is zero return &_hidh_itf[i]; } } return NULL; }

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2553: IMXRT: update linker scripts so that the code section does *not* star…

function callback at address 0x0 is kind of odd, though totally valid. Normaly that is for reset/entry/start. However, within the scope of tinyusb examples, we don't really need it and I really don't want to maintain these linker script if I don't have to. Thank you.

Note: in the future I will try to migrate from weak callback to weak/ref default implementation. It will elimiate the need for the if (func_cb) func_cb(), this is for keil compatible see #1018

fallow birchBOT
#
PwnVerse
[hathach/tinyusb] New comment on issue #2554: Add a check to see if device ID is correctly mapped before accessing it

What you said definitely makes sense. But a simple Null check before using the variable in my humble opinion would not cause much performance difference. Nevertheless, I also noticed that the length of the id array is being passed to the function and isn't being used which I'm assuming is 8 bytes since the code tries to access 8 bytes of id. Removing such stale variables would also be a nice thing to see in future.

fallow birchBOT
fallow birchBOT
#
theosib
[hathach/tinyusb] New comment on issue #2556: Plug in two devices at once, no devices found, panic

I don't know anything about USB, so this is slow going for me, but it looks like the problem is being caused by an attempt to set power management on a hub, and TinyUSB may not be giving it sufficient time to complete that setup before performing further communication. I've tried putting delays in various places, but I'm stabbing randomly. If someone who knows what they're doing could give me some hints about where I might put strategic delays, that would be really helpful.

Basically, we h...

#
theosib
[hathach/tinyusb] New comment on issue #2556: Plug in two devices at once, no devices found, panic

It also occurred to me that perhaps the end point it's trying to get the speed for doesn't really exist, so I modified hcd_port_speed_get to return TUSB_SPEED_INVALID on an invalid speed. It got a little further and then died here:

void __tusb_irq_path_func(_hw_endpoint_buffer_control_update32)(struct hw_endpoint* ep, uint32_t and_mask,
                                                               uint32_t or_mask) {
  uint32_t value = 0;
  
  TU_LOG(3, "Enter _hw_endpoint_buffer...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-hid-close-not-clear-data
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-h5-errata-2.15.1
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2515: Bug fix for STM32H5 need few cycles for RX PMA descriptor to update

I made an follow up to move delay to the interrupt handler instead. Per errata we should delay first before any attempt to read pma region. This assume read rx count is always the first access to the region (which is true most of time but not always). Also do some reformat and rename the header.

Note: initially I want to check the link speed then delay more if low speed, however, a quick check from manual does not show how link speed is detected, and low speed is super rare these days, so...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
theosib
[hathach/tinyusb] New comment on issue #2556: Plug in two devices at once, no devices found, panic

I'm comparing the success and failure cases. The success case is when only the keyboard (with its internal hub) is plugged in, while the failure case has the mouse also plugged in. The logs are identical up to a certain point.

Everything is pretty much the same as I shared above, ending with this:

HUB Set Feature: PORT_POWER, addr = 5 port = 3
[0:5] Class Request: 23 03 08 00 03 00 00 00 
hw_endpoint_init dev 5 ep 00 xfer 0
dev 5 ep 00 setup buffer @ 0x50100180
endpoint control...
fallow birchBOT
#
duckylotl
[hathach/tinyusb] Pull request opened: #2564 send ZLP to terminate packet size aligned transfers

Describe the PR
add NCM transfer termination by ZLP if necessary.
If NCM transfer aligns with (multiple) USB packet size the transfer has to be terminated with a ZLP.

This PR also lowers the likelihood of needing a ZLP to terminate a transfer.

Additional context
The driver implementation increased likelihood for this happening by always sending a multiple of 4 bytes in an NCM transfer, caused by including the padding bytes to the next NCM datagram, this however is not require...

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #1702: UAC2 supports interrupt-endpoint for providing control-change notifications to the host

@battlesnake @Gadgetoid Sorry for the extra long delay, finally I reviewed the changes and it's ready to merge:

  • Some code refactor, now the only option needed is CFG_TUD_AUDIO_ENABLE_INTERRUPT_EP
  • Added interrupt endpoint descriptor in usbd.h.
  • Added support to uac2_headset example, now volume can be changed by on-board button press (Tested with Nucleo-G0B1RE on Windows 10 and Linux)
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2543 MAX3421E NAK retry handling next frame

Perfect, thank you very much of the PR. Though I made some changes to

  • always en-force max NAK with default = 1. IMO, this should work best for most people. We can increase to 2,3 should it has issue with throughput in the future
  • add tuh_configure() cfgid to allow changing this behavior. This can only be used to change other max3421 behavior such as interrupt level polarity, edge in the future.
  • add ep's hxfr

tested and confirmed it only send 1 token per frame

![image](https://gi...

#
hathach
[hathach/tinyusb] Pull request review submitted: #2563 Support for STM32H503 MCU

thank you for the PR, I made an final changes following stm32h5_hal_pwr_ex to check for USB VDD instead of having that in each board.h

#if defined (PWR_USBSCR_USB33DEN)
void HAL_PWREx_EnableUSBVoltageDetector(void);
void HAL_PWREx_DisableUSBVoltageDetector(void);
void HAL_PWREx_EnableVddUSB(void);
void HAL_PWREx_DisableVddUSB(void);
#endif /* PWR_USBSCR_USB33DEN */
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421-limit-max-nak
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421-correct-max-nak
#
hathach
[hathach/tinyusb] Pull request review submitted: #2397 Add clang to compiler.h

recently I switch to use weak as the default implementation of callback to be compatible with keil #2239

https://github.com/hathach/tinyusb/blob/master/src/device/usbd.c#L48

the other callback header can work with weak_import, but this style seems to require actual weak and cause the compile issue with unit-test (since test include mocking of dcd layer).

Maybe I should use weakref/alias or unify them all to default implemenation, will revise later. We probably need to keep t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421-check-cfg-param
fallow birchBOT
#
Gadgetoid
[hathach/tinyusb] New comment on pull request #1702: UAC2 supports interrupt-endpoint for providing control-change notifications to the host

Sorry for the extra long delay

Looks like three weeks since I bumped it, that's a fast turnaround IMO and it's hugely appreciated! (We'll pretend the PR isn't years old because something something glass houses and stones 😬)

I have updated my code and replaced the tinyusb submodule in my local clone of pico-sdk. Everything works as I'd expect with our RP2040-based design. Including mute/unmute. Full changeset on my not-actually-a-headset-but-two-speakers codebase here: https://github.c...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-labler-error
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-max3421-rp2040-build
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ChrisDeadman
[hathach/tinyusb] Pull request opened: #2573 Add support for SAMD21 HCD

This was written from scratch using the datasheet and tested on a SAMD21 (using SparkFun SAMD21 Mini Breakout).
However, it should also work with SAMD51 boards, I don't have one for testing though.

USB Hub Issue

For some reason, when compiling the host/hid_controller example (modified by setting CFG_TUH_HUB to 1) from tinyusb, GET_DESCRIPTOR times out when connecting devices via USB hub.
When I use tinyusb within my platformio pr...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add_uvc_2ch_example
#
hathach
[hathach/tinyusb] New comment on pull request #2538: Add an example of 2ch video capture.

With new changes for camera 2 bulk is ok but iso (#2567 applied) gives a strange output on STM32G0.

In the capture STM32G0 sends packets every frame while STM32F4 sends much less.

capture.zip

Then I added a gpio toggle in tud_video_frame_xfer_complete_cb, for camera 1 it toggles every 100ms, for camera 2 it toggles about every 1ms.... Seems fsdev driver need some fix...

yeah, seems like fsdev specific...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add_uvc_2ch_example
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2538: Add an example of 2ch video capture.

regarding the fsdev driver issue with 2 ISO stream. We probably need to have its own issue/pr to fix.

Yeah, I've nearly sorted it out. For ISO transfer fsdev doesn't clear endpoint state upon transfer completion, once next IN token received it just resend current packet (even CPU halted) and trigger rx interrupt without way to mask...

The issue wasn't caught as in old examples the number of IN token corresponds to packets needs to send, but here all ZLP sent automatically are triggeri...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2576: WIP: DWC2 DMA support

Setup is received, somehow Data packet ending is corrupted...

USBD init on controller 1
sizeof(usbd_device_t) = 44
sizeof(dcd_event_t) = 12
sizeof(tu_fifo_t) = 12
sizeof(tu_edpt_stream_t) = 24
CDC init
guid, gsnpsid, ghwcfg1, ghwcfg2, ghwcfg3, ghwcfg4
0x00001100, 0x4F54281A, 0x00000000, 0x229ED590, 0x03F403E8, 0x17F00030
Fullspeed PHY init
USBD Bus Reset : Full Speed

USBD Setup Received 80 06 00 01 00 00 40 00
  Get Descriptor Device
  Queue EP 80 with 18 bytes ...
  0000...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421-configuration
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2574: FSDEV fix/cleanup.

I would prefer to keep double buffering for ISO if possible. Otherwise it may not keep up to 1023 byte per packet.

In fact currently double buffering is not configured correctly, it's enabled but both buffer are pointed to the same address.
https://github.com/hathach/tinyusb/blob/d33fe38a6257bcdd60f51a57c9fd19ce2ad1f202/src/portable/st/stm32_fsdev/dcd_stm32_fsdev.c#L965C1-L967C76

Maybe it's better to fix the buffer stuff and enable double buffering, since on older chips there is no m...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1580 Fixing Renesas register write protection and some compiler warnings in static code analysis

sorry for late response, thank you for the PR. Everything makes sense. Though the usba driver is rename to rusb2 and has been generalized to work with ra family. Though I noticed there is some hipcup espcially msc example does not work anymore with rx. Haven't spent much time to testing more. But it has nothing to do with this PR. Maybe I will revisit and/or file an seperated issues for that later. Will merge when ci passes.

#
hathach
[hathach/tinyusb] New branch created: labeler-more-catch
#
MatiMcFly
[hathach/tinyusb] New comment on pull request #1580: Fixing Renesas register write protection and some compiler warnings in static code analysis

Thank you very much for merging the PR.
Yes, I also noticed that there is an issue with the msc example code. If I remember correctly, the issues start as soon as USB version 2.1 is specified and certain msc descriptors are read.
I think there are even some open discussions regarding this topic.

I'll be back to work next week. If you want, I could probably provide further information.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1580: Fixing Renesas register write protection and some compiler warnings in static code analysis

Thank you very much for merging the PR. Yes, I also noticed that there is an issue with the msc example code. If I remember correctly, the issues start as soon as USB version 2.1 is specified and certain msc descriptors are read. I think there are even some open discussions regarding this topic.

I'll be back to work next week. If you want, I could probably provide further information.

that would be awesome, since I am not really familliar with rx much.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: labler-permission
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: dwc2-interrupts
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2574: FSDEV fix/cleanup.

I've reworked the PR, now it has correct ISO double buffering handing.

It's enabled only for device with 2048b PMA, smaller devices has 2 buffers point to the same address as before, otherwise they will fail to run some examples. In my tests I didn't see single buffering cause any issue.

Tested on L0, G0, H5 to be sure nothing broken.

I put each change in one commit hope it's easier to review...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2584: Dwc2 interrupts (based on #2050)

For 5ade917 I think it's better to double Tx fifo size only for port who has 4096b buffer. As Rx buffer size is already doubled, port with 1280b buffer has very limited usable space. Also 1280b port running in FS doesn't need much performance.

I think you are right on this, now thinking a bit more, even with 4096, having an in + out with 512 can take up to 2K if we double both of them. It is probalby ju...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: dwc2-txfifo-empty-level
#
hathach
[hathach/tinyusb] New branch created: fix-2097
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: revert-pr2245
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: support-ra2a1