#tinyusb

1 messages ยท Page 17 of 1

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on commit `be98cd5`

@nxf58843 do you happen to know which specific changes that break the K32L2 port. Any info would help to narrow the issue. Each port can be a bit different. I am on the way to test each port compliance, will test with Freescale Kinetic sooner or later.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-compliance
fallow birchBOT
fallow birchBOT
#
nxf58843
[hathach/tinyusb] New comment on commit `be98cd5`

I started with master (on Aug 31) and tracked it down to this commit where it broke. I have not root caused the specific change that did it yet. I don't know that there has been much evaluation with the khci port yet. I still need to check KL25Z.

fallow birchBOT
#
m-mcgowan
[hathach/tinyusb] New comment on issue #126: Port STM32 L4

Hi there @kasjer and @hathach! I'm excited to see tinyusb has a definition for the STM32L4R5nucleo board under hw/bsp. Can anyone confirm that they have seen this board function correctly with the cdc_msc example? Our board is very similar to this one, but I am not able to get the usb functioning. It would be great to know if this board is expected to work or not with tinyusb.

If not, any pointers greatly appreciated before I go diving in!

fallow birchBOT
fallow birchBOT
#
csBlueChip
[hathach/tinyusb] Issue opened: #1066 assert\(\) failure in hcd\_rp2040\.c

Operating System

RaspberryPi OS

Board

RP2040

Firmware

examples/host/hid_controller

What happened ?

assertion "ep->active" failed: file "/path/to/tinyusb/src/portable/raspberrypi/rp2040/hcd_rp2040.c", line 164, function: hw_trans_complete

Workaround: comment out the assert [dirty]

How to reproduce ?

  • mkdir ~/tmp ; cd ~/tmp
  • cmake -DFAMILY=rp2040 -DCMAKE_BUILD_TYPE=Debug /path/to/tinyusb/examples/host/hid_controller/
  • make
  • Attach minicom (or s...
#
csBlueChip
[hathach/tinyusb] Issue opened: #1067 /examples/host/hid\_controller is not compiled

Operating System

Linux

Board

RP2040

Firmware

/examples/host/hid_controller

What happened ?

hid_controller does not build ...because /examples/host/CMakeLists.txt lacks the line family_add_subdirectory(hid_controller)

How to reproduce ?

  • mkdir ~/tmp ; cd ~/tmp
  • cmake -DFAMILY=rp2040 /path/to/tinyusb/examples
    ...note that hid_controller is not built

Debug Log

n/a

Screenshots

No response

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
csBlueChip
[hathach/tinyusb] New comment on issue #1066: assert\(\) failure in hcd\_rp2040\.c

This (?obviously?) does not happen with debug DISabled.

what do you mean by this ? Can you confirm if the issue occur when debug is disabled ??

If you do NOT use -DCMAKE_BUILD_TYPE=Debug then the HID code (seemingly) works well... You can connect/disconnect a keyboard and the PID/VID are shown as expected ...Enable debug, and the driver just crashes :/

BTW, hid controller is for mounting game controller only, and currently only tested with Sony PS4. If you want to test keyb...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #1071 More IAR support

Describe the PR

Add IAR project connection files, which can be used to automatically import tusb stack & example into IAR project.

Since SDKs in hw\mcu only have GCC's cstartup file (and there are too much MCUs for me...), a buildable IAR project need to be created before import tusb.

Example's source files (main.c, tusb_config.h, etc.) will be copied to project's directory, os they can be edited safely.

tools/iar.ipcf only contains the stack, *.ipcf inside examples ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1071 More IAR support

This is great and I am sure IAR user will find it helpful. However, as you mentioned ipcf only add source files as they appear in the actual file system and not buildable. Therefore it is not too useful IMHO.

To be honest, I have a mixed feeling about adding these file. I don't use IAR at all therefore cannot and won't be able to maintain these project file in the future. My experience with IDE is that they are super nice with specific project on specific MCUs with all of its great deb...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1070: Fix for MSC during stage STATUS

@kamtom480 the stall condition (before PR logic) is indeed correct here, according to the MSC BOT 13 cases. this particular if is for case 5 when Host expect more data than Device could send. In this particular case is Read Format Capacity command, where host expect 252 bytes, and we only send 12 bytes in response. Device really need to send an STALL first, then resume to send SCSI status afterwards when received clearing stall request https://github.com/hathach/tinyusb/blob/master/src/class/...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1070: Fix for MSC during stage STATUS

@kamtom480 hmm seem like the dcd didn't notice the stack when setup packet of the next CLEAR STALL request. Therefore the msc couldn't continue. I haven't looked too closed at dcd_cxd56.c so far, I will try to see if I could get any clues

Here is the log level 2 from cp210x from make BOARD=spresense LOG=2

USBD Xfer Complete on EP 05 with 31 bytes                                                                                               
  MSC xfer callback                   ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1070: Fix for MSC during stage STATUS

I see spresense has its own usb stack under nuttx system, and it Doesn't forward the Clear Feature (Endpoint) request toward tinyusb. https://github.com/sonydevworld/spresense-nuttx/blob/2ffe58b6dcb8ca7e83a4d2acec5622276f7c6f5d/arch/arm/src/cxd56xx/cxd56_usbdev.c#L1367

It is quite troublesome, since most of the msc recover is based on the Clear Stall request. I will try to figure an way. In general the setup seem to be conditionally forwards (most but not all), and Status stage can als...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-cxd56\-msc
#
hathach
[hathach/tinyusb] Pull request opened: #1075 Fix cxd56 msc

Describe the PR

Revert changes in #1070 , fix the root cause of the issue with cxd56. Following is the explanation (copied from other pr)

@kamtom480 the stall condition (before PR logic) is indeed correct here, according to the MSC BOT 13 cases. this particular if is for case 5 when Host expect more data than Device could send. In this particular case is Read Format Capacity command, where host expect 252 bytes, and we only send 12 bytes in response. Device really need to send an ST...

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1075: Fix cxd56 msc

yeah, it will work since my default python is to python3 (it used to be python2 though) unitl I upgrade my ubuntu 20.04 to 5.10.0. I will update it python3 on Linux and simply python on windows

$ uname -a
Linux hathach-itx 5.10.0-1044-oem #46-Ubuntu SMP Wed Aug 11 09:50:57 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ python --version
Python 3.8.10

$ python3 --version
Python 3.8.10

$ python2 --version
Python 2.7.18
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: st\-synopsy\-compliance
#
hathach
[hathach/tinyusb] Pull request opened: #1077 St synopsy compliance

Describe the PR
make synopsys usbcv compliance

  • implement dcd_edpt_close_all()
  • reset dtoggle when open endpoint
  • correct dev interrupt mask on bus reset
  • also implement remote wakeup for stm synopsys with nop delay() based on SystemCoreClock

This is tested on stm32f411disco which passed all the compliance test (chapter 9, hid, msc) more detail in #1059

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rx\-msc\-compliance
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1062: Improvements for dcd\_transdimension

The current TD buffer setup is not correct in general, the requirement with 4K aligned is too specific to make its way into the buffer page array set up. And this does not work with other MCU dcd.

For ISO, you have to understand this limit and need to declare the fifo depth to be multiple of ISO frame. Re-config the fifo length to even smaller depth than its buffer when needed when the ISO packet size is changed is better implementation. E.g fifo buffer is 4x1024, but should be changed to...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #1062: Improvements for dcd\_transdimension

the requirement with 4K aligned is too specific to make its way into the buffer page array set up. And this does not work with other MCU dcd.

Yes it is specific, so I've introduced a on/off switch in #1063 to not enable fifo_xfer by default, except explicitly.

For ISO, you have to understand this limit and need to declare the fifo depth to be multiple of ISO frame.

That's won't work since sample length could be +-1, wrapped part has to be always considered.

#
hathach
[hathach/tinyusb] New review comment on pull request #1062: Improvements for dcd\_transdimension

Yes it is specific, so I've introduced a on/off switch in #1063 to not enable fifo_xfer by default, except explicitly.

I don't like the TUD_AUDIO_PREFER_RING_BUFFER, it is only temporarily solution, we will eventual remove that.

That's won't work since sample length could be +-1, wrapped part has to be always considered.

Apparently, I am not aware of this issue. In this case, can you modify to make it more generic. xfer_fifo() will make use of qtd_init() with the linear part fi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] Pull request opened: #1086 Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

Describe the PR

  • Implement dcd_edpt_close_all() function.
  • Fix dcd_edpt_close_all() function. This function worked for endpoint 0 but others.

Additional context

  • Chapter 9 tests pass with the exception of four tests regarding suspend/resume/remote-wakeup. frdm_kl25z does not have any switches, so these tests cannot be tried.
  • All HID tests pass.
  • The MSC tests pass with the exception of five tests: error-recovery/case 4,8,10/required-command. Not investigated yet.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1059: USB Compliance Verification Test Suite \(USBCV\)

Thank for the testing, though, did you test with the hid composite, one of the chapter9 is remote wakeup which is only tested with hid example due to TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP

It didn't work.
There is a typo of |= but still something more.
https://github.com/hathach/tinyusb/blob/d66d817c38d3da25198dbef90e8e0cd516f4508e/src/portable/nuvoton/nuc121/dcd_nuc121.c#L258

HID test passed.
USB3CV.zip

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #1087: NUC126: fix remote\_wakeup

Without 22571ec with cdc_msc disk won't show up, but with this commit it fails strangely:

USBD Xfer Complete on EP 83 with 13 bytes
  MSC xfer callback
  SCSI Status = 0
  Queue EP 03 with 31 bytes ...
USBD Xfer Complete on EP 03 with 31 bytes
  MSC xfer callback
  SCSI Command: Read10
  Queue EP 83 with 512 bytes ...
USBD Xfer Complete on EP 83 with 512 bytes
  CDC xfer callback
cdcd_xfer_cb 431: ASSERT FAILED
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: imxrt\-compliance
#
hathach
[hathach/tinyusb] Pull request opened: #1089 Imxrt compliance

Describe the PR
Update NXP TDI (transdimension) dcd to fully pass USBCV test #1059 following is changes

  • add other speed descriptor callback tud_descriptor_other_speed_configuration_cb()
  • implement device qualifier and other speed configuration descriptor for high speed device which is required by USBCV e.g to work with full speed host
  • Enhance plugged/ unplugged detection
  • Enhance/implement suspend, resume, remote wakeup
  • implement dcd edpt close all
  • Fix and enhance dc...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1062: Improvements for dcd\_transdimension

@HiFiPhile I do some refactoring and happy with the refactored code. However, the xfer_fifo is not complete yet. In case where total_bytes > than linear length and the buffer is not 4K. DCD must

  1. make an td with linear length
  2. when td is complete, continue to submit another TD with the rest.

In short, The dcd must transfer all requested bytes by usbd/class driver, depending on the driver, breaking it into 2 sub transfer may still be acceptable e.g with stream/buffered endpoint such ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1086 Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

Superb ! Thank you very much for the update. For frdm_kl25z, we could pick one of its header pin and use wire jumper for input. Though we could always do it later.

For the MSC test, it is the most tricky test, have you tried to explicitly reset the PID of endpoint to DATA0 when dcd_edpt_open() is called. Since one of the msc test sequence is reset by simply Set Config(0) then SetConfig(1), and expect all the endpoints to be reset.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

For frdm_kl25z, we could pick one of its header pin and use wire jumper for input

For boards without I/O, I think we can make bsp functions 'weak' to make it easier to override for testing purposes while keeping git workflow clean.
For example my nuc126 board has a button and I could push the wrong file.

It is not necessary, pin/port is fixed on individual board, If you have an custom nuc126 board, you should add your own board file that correctly reflect your hardware.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: esp32sx\-compliance
#
hathach
[hathach/tinyusb] Pull request opened: #1091 Esp32sx compliance

Describe the PR
Get esp32sx to fully compliant to USBCV #1059, changes mostly follow #1077 since esp32sx also use synopsys controller.

  • implement dcd_edpt_close_all()
  • reset PID to DATA0 when open endpoint
  • implement dcd_remote_wakeup() and temporarily enable SOF for bus resume detection.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #1062: Improvements for dcd\_transdimension

Now UAC2 is broken with no transfer, maybe forget to reset EP busy flag in usbd_edpt_close ?

USBD Setup Received 01 0B 03 00 01 00 00 00
  Set Interface
  AUDIO control request
  Set itf: 1 - alt: 3
  Open EP 01 with Size = 776
  Queue EP 01 with 776 bytes ...
  Open EP 81 with Size = 4
Set interface 1 alt 3
  Queue EP 81 with 4 bytes ...
  Queue EP 80 with 0 bytes ...
USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received 01 0B 00 00 01 00 00 00
  Set Interface
...
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #1062: Improvements for dcd\_transdimension

which audio example you are running

I've tested both uac2_headset and my own config.

Somehow EP flags are not reset when closed.

With xfer_fifo enabled it fails for the same reason:

USBD Setup Received A1 01 01 01 00 02 01 00
  AUDIO control request
Get channel 1 mute 0
  Queue EP 80 with 1 bytes ...
USBD Xfer Complete on EP 80 with 1 bytes
  AUDIO control complete
  Queue EP
USBD Setup Received 01 0B 01 00 01 00 00 00
  Set Interface
  AUDIO control request
  Set...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1062: Improvements for dcd\_transdimension

@HiFiPhile yeah, I think this is the right fix, closing endpoint should also reset its state. Please make the commit if possible

void usbd_edpt_close(uint8_t rhport, uint8_t ep_addr)
{
  TU_ASSERT(dcd_edpt_close, /**/);
  TU_LOG2("  CLOSING Endpoint: 0x%02X\r\n", ep_addr);

  uint8_t const epnum = tu_edpt_number(ep_addr);
  uint8_t const dir   = tu_edpt_dir(ep_addr);

  dcd_edpt_close(rhport, ep_addr);
  + _usbd_dev.ep_status[epnum][dir].stalled = false;
  + _usbd_dev.ep_s...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

I have tried this out with cdc_msc example but seems still be issue with stall/clear stall. kl25z doesn't seem to clear stall correctly. As captured in the bus, the device continue to response with STALL after a clear stall attempt from host, and cause it to issue bus reset for recovery. And it loops over again, until host driver give up and doesn't issue the MODE SENSE command.

transaction 7883 + 7941 is clear stall control request and ack. Afterward the msc bulk in still response with...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

Thank you very much for your comments and checking the patch!
It is very helpful for me. I check the patch again.

When USBCV was run, no other USB devices would work, so I did not get testing logs.

You only need to tested with normal operation (now confirmed on windows) The side-effect would be a decent delay before the device show up. The log with LOG=2 LOGGER=rtt will show the issue (around the stall -> clear stall -> bus reset). There is an hidden (no-log) transaction as c...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

@hathach
Thank you for your help. I found that a issue regarding stall interrupt handling.
When dcd set a stall response by setting bdt_stall = 1, it set ENDPOINT[epn].EPSTALL. I found we need to clear the bit in process_stall().

I wasn't expecting ENDPOINT[epn].EPSTALL to be set!

Superb !!! I confirmed it passed the MSC test suite. Yeah, I have read the KL25z manual back and forth and didn't see any mentioned about controller will set this bit and the need to clear ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

@kkitayam I confirmed that we couldn't detect the RESUME signal currently, suspend detection is fine. Btw, i found an new usb tool HSETT https://www.usb.org/compliancetools#anchor_usbxhsett is very useful to manipulate the bus manually. After too tired of pressing power button on my windows machine to put it on suspend and resume. This can be done by using HSETT

<img width="428" alt="Screenshot 2021-09-16 172209" src="https://user-images.githubusercontent.com/249515/133595933-83bde6cc-e...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

@kkitayam I have pushed the new commit, it passed all the suspend/resume/remote-wakeup test now. The issue is due to the RESUME detection, it seems the ISTATW RESUME is never triggered. possibly used for host. The tranceiver resume_int is correct way to detect bus activity. Also it will be triggered when the USB_USBTRC0_USBRESMEN_MASK is set regardless of the INTEN.

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1094 dcd\_da146xx: Add VBUS handling

Describe the PR
DA146xx are Bluetooth devices that may be battery
powered and when not connected to USB host there
is no need for USB peripheral to be running.

This change allows to enable USB peripheral when
VBUS is present otherwise USB is down reducing
power consumption.

tud_vsub_changed() function must be called
whenever VBUS change was detected.
For bus-powered devices this function should be called
at startup since VBUS must be present while device
is working.

Tw...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

@kkitayam Thank you for your testing. oh, I didn't know that mcu also use the same controller as khci. It is submitted by mcu vendor https://github.com/hathach/tinyusb/pull/869 . And I am unaware of the driver is based on yours. The license should name yours instead. I will correct that. Ideally, it should be the same common dcd file though, I am really bad of naming, I wish I know the USB IP name (like synopsys) to make it spot-on, but I will try.

I haven't run tested on the mcu just yet,...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1094: dcd\_da146xx: Add VBUS handling

Thank you for your PR. I agree that we need an unified API for managing vbus/power. The nrf implementation is a good candidate with an API(vbus_state) which is detected/ready/removed. These can be useful for port that does not have built-in vbus detect (required external gpio) such as esp32s2. For those vbus detection is only way to distinguish between Suspend vs Disconnection. Do you need to merge this right away, else give me a few days, I will try to review all the dcd and try to finaliz...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1094: dcd\_da146xx: Add VBUS handling

I prefer to merge and you can take more time to rethink it. It will not be a problem if API will slightly change later on.

Yeah, I prefer to merge this as well. Since I can be late on the API revising --> merged

I can also implement dcd_edpt_close_all() for Dialog in spare time. Do you have any scenario that this function can be tested?

The close_all() is quite similar to bus_reset(), except it does not reset control endpoints. It is used when host switching from active configura...

fallow birchBOT
fallow birchBOT
#
qingliyu
[hathach/tinyusb] Issue opened: #1095 setting keyboard led error

Operating System

Windows 7

Board

nrf52840

Firmware

\tinyusb\examples\device\hid_boot_interface\src\main.c

What happened ?

Execution fails forever on \tinyusb\examples\device\hid_boot_interface\src\main.c๏ผšline 216.
report_type is always equal to 0

How to reproduce ?

empty

Debug Log

No response

Screenshots

No response

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

It is very interesting! I've also looked into PIC18F2455 too. It looks that this MCU has a similar USB IP. The IP has PPB(Ping-Pong Buffer) instead of BDT. And it seems that PPB had been applied as a patent in 2004.
BDT may be an upgraded version of PPB by microchip.

I found that the USB IP seems to be called as [VUSB](https://doc.hcc-embedded.com/hcc-documentation/usb-device-sta...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1086: Implement dcd\_edpt\_close\_all\(\) and fix dcd\_edpt\_clear\_stall\(\) for frdm\_kl25z

@kkitayam I spent several hours to do a bit of research on this, here is my findout.

The Chipidea Full Speed USB 2.0 OTG Controller is a highly optimized, low gate count IP core that allows system developers to implement compact, cost-effective, low-power USB-based SoC solutions.
  • ChipIdea previously bought this IP from ...
fallow birchBOT
#
jmark1m
[hathach/tinyusb] Issue opened: #1097 Update Code for Class Vendor\_Host

The type definitions for pipe_handle_t were removed in #449 for all class drivers except for class Vendor_Host (/class/vendor_host.h and /class/vendor_host.c).

The Class Vendor_Device also does not use the type pipe_handle_t so it seems Vendor_Host should follow a similar pattern.

I want to simply define,

#define CFG_TUH_VENDOR 1

and then simply be able to use these functions for bulk data transfer.

`
tusb_error_t tusbh_custom_read(uint8_t dev_addr, uint16_t vendor_id, ui...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #1096: dcd\_da146xx: Implement dcd\_edpt\_close\_all\(\)

@hathach thanks for input, I will update PR.
But before this I will make another PR that will remake power state handling. Bus reset and sleep related code was only testes on live systems. Now when I've used USB3CV, I see that more changes are needed in that area.

But since you are on this, let me ask about something that prevents USB3CV tests to pass on this board.
EP0 size is 8 for this chip family, when code below is NOT removed tests fail.

      // Only send up to EP0 P...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1096: dcd\_da146xx: Implement dcd\_edpt\_close\_all\(\)

@kasjer this is really an edge case. This particular code is added since it is needed when testing with actual host driver such linux/windows with 8-byte control endpoint e.g msp430. The host driver won't bother getting the 2nd packet EP0 and will send ZLP as status right after the 1st packet. Maybe the USBCV has different expectation, I will try to test it later on.

You can try to comment it out to run the USBCV, but you may have issue with normal enumeration.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1101 da146xx bus reset and sleep reworked

Describe the PR
So far bus reset was handled (with some holes in it).
Sleep and remote wake-up were not really tested and did not work.

With this change:

  • bus reset is reworked
  • remote wakeup works
  • bus signal sleep is handled
  • in some cases register modification (read/update/write) was change to just writes.
  • FRAME interrupt is used for bus reset end condition and for delay needed in remote wakeup condition.

Additional context
While it work with Windows and Linux s...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #1096: dcd\_da146xx: Implement dcd\_edpt\_close\_all\(\)

@hathach about USB3CV and Windows/Linux enumeration difference.
For me behavior of USB3CV is more reasonable, but then I also understand what was done in Windows/Linux.
It could be fixed in TinyUSB if we had EP0 OUT endpoint ready not just after expected length of DATA STAGE, but (for example) after first packet or from the beginning. Then STATUS STAGE could just stop control request.

But there is simpler solution that can make USB3CV and Windows happy.
We could slightly...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1096: dcd\_da146xx: Implement dcd\_edpt\_close\_all\(\)

@hathach I decided to make dcd_edpt_close_all() look very simple.
This PR will be followed by next change that will take into account what should be done when endpoint is closed so basically I will update dcd_edpt_close() as well.

The previous edpt_close_all() is actually simpler since it is used when expecting a full reconfiguration. The edpt_close() is currently meant for ISO only, in the future, I plan to retire/remove it to prefer and better API e.g edpt_resize() due to the fact t...

#
hathach
[hathach/tinyusb] New comment on pull request #1096: dcd\_da146xx: Implement dcd\_edpt\_close\_all\(\)

@kasjer the new condition look great. IMHO, It is really OS host driver fault, getting the 1st 8bytes to get EP0 size is common approach similar to getting first 9 bytes of configuration descriptor. I did this as well in the host stack https://github.com/hathach/tinyusb/blob/master/src/host/usbh.c#L712

Back to your suggestion, I think it is great, could you made an PR for it along with the comment to explain the different between the 2 cases

  • Host only want to receive only 1 packet with...
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1102 usbd: Workaround for non standard device descriptor request

Describe the PR
Windows and Linux host during enumeration requests device
descriptor with request size set to 64 bytes when device
was in default state (no address).
Those systems do not want 64 bytes though since usb descriptors is
only 18 bytes long so they silently expect that only one packet
will be received possibly 18 bytes for EPS > 16 or 8 or 16 bytes
for smaller EP0.

For devices with CFG_TUD_ENDPOINT0_SIZE size 8 or 16 there was
workaround that reduced request size to ...

#
kasjer
[hathach/tinyusb] Pull request opened: #1103 dcd\_da146xx: Remove registers pointer from xfer\_ctl\_t

Describe the PR

xfer_ctl_t structure keeps all dynamic data connected with transfer.
It used to have pointer to register set that was constant and was there
for convenience only.
Removing register pointer from structure makes cleanup easier as whole
structure can be erased with memset-like function.

In many cases functions were using local variable regs and xfer->regs which
were same, that could be confusing so this part is unified.

Few macros were added for easy conversion ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-esp32\-ci
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #1105 MSP430 failed to response Get Device Descriptor

Operating System

Linux

Board

msp_exp430f5529lp

Firmware

examples/device/cdc_msc

What happened ?

Failed to enumerate on both Linux and Windows. The root cause is msp430 responses with incorrect data, basically using the control request instead of the device descriptor payload.

How to reproduce ?

  1. Run cdc_msc
  2. PC will complain with read device descriptor error
[89841.141609] usb 3-2.1: new full-speed USB device number 45 using xhci_hcd
[89846.329389] u...
fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on issue #1105: MSP430 failed to response Get Device Descriptor

@hathach Would you be willing to handle this for me? If not, I'll take a look in the coming days.

Is that screenshot first transaction that happens after bus reset (i.e. beginning of enumeration)? If so, that looks somewhat (see italics) normal to me.

MSP430 is hardcoded for control endpoint to xfer 8 bytes at a time. I know the first xfer an OS will send should be 64 bytes, and the OS should notice that the MSP430 only responded w/ 8 bytes. _MSP430 responding by echoing the setup pack...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #1107 add NCM driver in a compatible manner : hathach/tinyusb\#550

This adapt the Nov 2020 era CDC NCM driver from @j4cbo to be compatible with the TinyUSB network API.

The big difference between this PR and PR #550 is that instead of the user having to craft a new user application to use the NCM driver, the existing net_lwip_webserver example just works, regardless of which network driver is used. Similarly, anyone who is writing their own TinyUSB-based network application can switch between the two drivers, using the same API, to choose which works best...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: minor\-changes
fallow birchBOT
fallow birchBOT
#
asypost
[hathach/tinyusb] Issue opened: #1109 MSC slow after USB sleep with CDC and MSC configuration

Operating System

Windows 10

Board

STM32F103

Firmware

tinyusb 0.11.0 with CDC and MSC option set runs without OS on STM32F103 board.

What happened ?

The program runs quite normal until the CDC and MSC idle for hours.If you open a file in the tinyusb disk with Windows 10 file explorer,it will stuck for a long time and you will see the disk usage in task manager which is 100%,in the mean time if you send data to the cdc COM port,it will resume normal.

How to reproduc...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1106: Add extra validation to msc\_device

Could you please verify that validation for the case when cbw->total_bytes = 0 and block_count = 0 is correct. From what I can see rdwr10_validate_cmd will return MSC_CSW_STATUS_PASSED thus proc_read10 will be called. This will lead to a division by zero in proc_read10_cmd.

status is passed, but the total_bytes = 0, will skip the data phase, go straight to status and didn't invoke the proc_read10 https://github.com/hathach/tinyusb/blob/master/src/class/msc/msc_device.c#L425

Also rdw...

#
hathach
[hathach/tinyusb] New comment on issue #1109: MSC slow after USB sleep with CDC and MSC configuration

could you provide a bit more info

  1. Which exact firmware you are using, if possible please check with the examples/cdc_msc, otherwise, please attached your firmware similar to how stock firmware for reproducing.
  2. Instead of Leave the device for hours, can you try to sleep/suspend pc, then resume to see if it is sleep/suspend related issue
  3. Build example with make LOG=3 BOARD=your board then attached the the log file here around the incident occur for analyzing.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] Pull request opened: #1114 fix for endpoint bitfield problem in big endian mode

I could track down the problem with the bitfield "wMaxPacketSize" in the file "usb_types.h"
https://github.com/hathach/tinyusb/blob/32bdf3b79d27ed9f0851440df35b6a72bcd8bff8/src/common/tusb_types.h#L352-L361
and the CCRX toolchain building in big endian mode. The problem does not occurs if the CCRX toolchain is building in little endian mode.

The bitfield "wMaxPacketSize" is a member of the "tusb_desc_endpoint_t" struct definition, which is used to make the access to the USB descriptor ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: zhangslice\-master
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enhance
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] Pull request opened: #1118 Add Video class

Describe the PR
Add Video class driver and a video capture example. #908
This version is experimental and has many limitations. I have only implemented a minimum number of features.

  • Support only uncompressed format.
  • Support only isochronous IN. No support isochronous OUT and bulk.
  • Support only Full speed. So, the maximum bitrate is 1Mbps.
  • Support only input-terminal and output-terminal. No support any other unit.
  • No support dynamic streaming settings modification.
  • No...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

AMAZING!!! brilliant PR :+1: :+1: , thank you very much for making this. UVC along with UAC are 2 most complicated classes. This awesome PR with testable examples will greatly help further development (iso out, highspeed), and I have no doubt that we could pull this off together in the next several PRs.

Since the changes are huge, please give me a bit of time to digest it. I will also take the chance to test it with other ports as well. We will probably make an separated issue to keep tra...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1114: fix for endpoint bitfield problem in big endian mode

Thank you @Wini-Buh for detail breakout, I think I understand the issue, indeed the bitfield doesn't work well when swapping the endian. USB descriptors are always in endian --> need swap, which will cause incorrect mapping of bitfield. I think the best solution is just drop the bitfield within multi-byte field such as wMaxPacketSize entirely. The highspeed mult isn't used much anyway, in case of usage, it could be done simply by bitwise operation. I will make any PR to rename/change it, alth...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1113 Assure msc device block size is not zero

Thank you very much for the PR. I take a look back at the MSC BOT specs, the case where total bytes < block num is actually counted as

  • READ10: case 7 Hi < Di host read less than device want to send or
  • WRITE10 (we need this check for write as well): case 13 Ho < Do, host send less than device would like to receive

In both cases, the specs say we must response with phase error. Therefore, I made a bit of changes and push the update

![image](https://user-images.githubusercontent.c...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

Fix CI errors, and I confirmed video capture example works fine on Raspberry Pi Pico and RX65N target board.

Superb ! thank you for more testing, I will check this out and do more testing on other ports within this week as well. It may be the good chance to enhance/update the ISO api as well. Current one has issue with certain port when switching the bandwidth.I have some idea, but haven't got time to do something with it. Thank you again :+1:

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1120 house keeping update

Describe the PR
Mostly house keeping work

  • Update ISO endpoint for nrf5x to be 8 for audio example
  • fix #1067
  • correct drivers interface binding for MIDI and BTH, where it have 2 interfaces but does not use IAD.
  • clean up usbh configuration parser a bit
  • Make vendor driver more flexible with varies of custom descriptors between Interfaces and Endpoints. Also can have 0-2 endpoints (previously fixed 2 endpoints).
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1107: add NCM driver in a compatible manner : hathach/tinyusb\#550

So, I've been using the pre-rebased version of this (5a1a6ba) for about a month now on several RPi Picos. I'm perfectly happy with it and didn't have any issues yet. I'm running a DHCP server over it, an HTTP server and I have quite a bit UDP traffic (unicast and multicast) host -> board.

EDIT: And I'm using the "Microsoft OS 2.0 USB descriptors" so Microsoft actually loads its NCM driver: https:/...

fallow birchBOT
#
maemoKKK
[hathach/tinyusb] New comment on issue #1105: MSP430 failed to response Get Device Descriptor

I have similar issue.
I use STM32F103 BLUEPILL board, Win10-PC-Host send usb packet ๏ผˆ 80 06 00 01 00 00 12 00 ๏ผ‰means descriptor length is 18 bytes. in tiny usb code, the descriptor is prepared by desc_device, and the length is 18bytes exactly.
However, I use another MCU IC manufacture by Chinese facturary ( they said it is as the same as the STM32F103C8T6). after power on, usb enumeration ๏ผŒWin10-PC-Host send usb packet ๏ผˆ 80 06 00 01 00 00 40 00 ๏ผ‰. my board still response 18bytes.

then is...

#
maemoKKK
[hathach/tinyusb] New comment on pull request #1102: usbd: Workaround for non standard device descriptor request

I have similar issue.
I use STM32F103 BLUEPILL board, Win10-PC-Host send usb packet ๏ผˆ 80 06 00 01 00 00 12 00 ๏ผ‰means descriptor length is 18 bytes. in tiny usb code, the descriptor is prepared by desc_device, and the length is 18bytes exactly.
However, I use another MCU IC manufacture by Chinese facturary ( they said it is as the same as the STM32F103C8T6). after power on, usb enumeration ๏ผŒWin10-PC-Host send usb packet ๏ผˆ 80 06 00 01 00 00 40 00 ๏ผ‰. my board still response 18bytes.

then is...

fallow birchBOT
fallow birchBOT
#
maemoKKK
[hathach/tinyusb] Issue opened: #1121 Host ask for 64 bytes Descriptor, but device gives 18bytes during enumeration

Operating System

Windows 10

Board

CH32F103C8T6

Firmware

webusb-serial

What happened ?

CH32F103C8T6 is very similar to STM32F103C8T6. I use "make BOARD=stm32f103_bluepill all" to compile and flash image.

after power on, windows host send 80 06 00 01 00 00 40 00๏ผŒ but device send 18 bytes.

How to reproduce ?

  1. CH32F103C8T6 have USB pull up resistant inside. during board_init, enable USB pull up resistant after GIPO init and before USB clock enabel.
  2. compile...
fallow birchBOT
#
csBlueChip
[hathach/tinyusb] Pull request opened: #1122 WiP : MIDI Host

MIDI Host - work in progress

Includes descriptor decoding routines (I'm learning USB as I go)

Some commits can be included immediately as they are generic "bug fixes" ...these commits are flagged "**" because I have no idea how to use git properly (yet)

The MIDI Engine code (~3kloc) [see MIDI folder at root level] cannot be properly integrated, tested, and debugged until I get the basic driver going - which is not going well :( ...but it at least compiles in a test harness :)

fallow birchBOT
fallow birchBOT
#
Daft-Freak
[hathach/tinyusb] Pull request opened: #1123 Handle HID devices with OUT endpoint listed first

While experimenting with HID devices, I found that one of my controllers failed to report anything (a 3rd-party Switch pro controller). It turned out that this device lists its OUT endpoint first and the HID host code was opening that instead of the IN endpoint.

lsusb -v for the device:

Bus 001 Device 093: ID 20d6:a711  Core (Plus) Wired Controller
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1107 add NCM driver in a compatible manner : hathach/tinyusb\#550

Excellent work :+1: :tada: , I have tried it and it works perfectly on Linux. On windows it requires ncm driver (skip for now) and will test with windows later on when adding MS OS 2.0 descriptors. But I am sure it works as well. Thank you @majbthrd and @j4cbo for making this driver possible.

@majbthrd I rename the CFG_TUD_NET to CFG_TUD_ECM_RNDIS, although they both implement network, they are independent, therefore I think it make more sense for each to has its own macro feature. T...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

@kkitayam I need help with the testing, I have tried this on both KL25z and pico with windows. However, I couldn't get the logo displayed. It could be me since I am not familiar with virtualdub. I am on windows 10 with virtualDub 1.10.4 amd64. What I have done:

  • Launch virtualDub, File -> Capture AVI ...
  • Device -> select TinyUSB UVC
  • Didn't see anything
  • Try to change Video -> Set custom format, but vb doesn't allow me to set to anything else.

<img width="293" alt="Screenshot 202...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1118: Add Video class

@hathach Could you try following steps. I had tested the followings. Please note that it is not possible to preview by VirtualDub with this patch. We can record a video stream into a file after that play the video file.

  • Launch virtualDub, File -> Capture AVI ...
  • File -> Set capture file...
    image
    Input a file path to save captured video stream.
  • Device -> USB (Direct Show)
    ![i...
fallow birchBOT
#
dkonigsberg
[hathach/tinyusb] New comment on issue #1039: CDC device receives garbage if it transmits first

I ran into a similar situation, and the Wireshark capture was enlightening. So including that would be quite helpful.
Here's basically what I did:

  • (tinyUSB) Device connected to (Linux PC) host, terminal app not running
  • Device sends a series of lines (short string ended with CRLF) that get stuck in the TX buffer
  • Open terminal app on the host
  • First line gets echoed from the host back to the device, one character per USB message.
  • Terminal app receives the rest of the lines normal...
#
dkonigsberg
[hathach/tinyusb] Issue opened: #1128 Provide a way to reset a CDC device with unsent flushed data

Is your feature request related to a problem? Please describe.
USB CDC does not appear to provide a reliable way of knowing when there is a user application on the host that's actually connected to the device. At best there's the DTR flag, but it cannot always be trusted. As such, the only way to know if you're transmitting data to nowhere is to check after the fact. (Either by getting a 0 response after successive calls to tud_cdc_write_flush() or by waiting on `tud_cdc_tx_complete_c...

fallow birchBOT
#
dhalbert
[hathach/tinyusb] Issue opened: #1129 tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

Operating System

Others

Board

Adafruit MacroPad RP2040

Firmware

circuitpython (post 7.0.0, PR under development) using TinyUSB commit 43aac707

I'm testing this in the BIOS screen on a Dell Latitude E4310, which requires a boot keyboard,, and sends a SET_PROTOCOL. Interestingly, some later Dell BIOS'es no longer require a boot keyboard. I also see this problem on an older MSI motherboard.

What happened ?

I'm implementing boot protocol support in CircuitPython. I set u...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

thanks @dhalbert for a detail issue, I will do my own test. meanwhile can you provide following detail, to see if I could spot any isue in the configuration.

  1. the branch/code for cpy you are working on along with code.py for reproducing purpose.
  2. your configuration descriptor via command lsusb -v -d 239a:
  3. hid descriptor via command sudo usbhid-dump -d 239a | grep -v : | xxd -r -p | hidrd-convert -o spec
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

@kkitayam bravoss !!! it works, sorry, I am new to this vd and didn't figure out the right way to test it. Proceeding with further tests now :+1: :+1: . Display tinyusb log is super nice, however, if size is an issue, we could change to good old color bar pattern or pattern that could be generated without having a huge flash. That would make the example more accessible to other MCUs.

fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

Here's a patch file of the instrumentation of src/class/hid/hid_device.c. I just add an extern float indicator, and then set it to various values at various points in the code:
instrumentation.hid_device.c.patch.txt

CircuitPython changes are here:
https://github.com/dhalbert/circuitpython/tree/hid-boot-protocol. There are two commits on this branch.

boot.py and code.py (renamed for uploading...

fallow birchBOT
#
dkonigsberg
[hathach/tinyusb] New comment on issue #1128: Provide a way to reset a CDC device with unsent flushed data

The use case is wanting to make data sent out through a USB CDC device go to the bitbucket if that device is connected to a host, but that host isn't actually listening. (e.g. device plugged into a PC, but no terminal app has actually opened the resulting serial device on that PC) As far as I can tell, FTDI FT232 devices (which aren't CDC) behave that way, and the CDC device in one of my embedded debug probes does too.

There are two things that need to happen to gracefully deal with this...

fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

To confirm this is not port-specific, I tried the same test (with a slightly different code.py) on a SAMD51 PyGamer, and saw the same issue. I see 0.1 printed as the only indicator value, showing that hidd_control_xfer_cb() was not entered.

Note that because the keyboard report descriptor in use has no report id and is very standard, it is possible to send keyboard reports, and the BIOS will respond. But the callback is not happening.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

@dhalbert I have just tested with one my simple hid_boot_interface here with 1 boot keyboard + 1 boot mouse. Everything works just fine. The issue with your case is the host driver does not follow the specs, the HID is at bInterfaceNumber=3 however, wIndex in its SET_PROTOCOL does not correct set this value. TinyUSB interpreter this as invalid request toward CDC and stall in response.

<img width="672" al...

#
hathach
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

@dhalbert that could cause issue with windows machine that already mounted our board before. I am not sure if windows change their way, but last time I tested: Windows stored binding drivers for interfaces using vid_pid (and probably bcd version), to skip re-analyze the configuration afterwards.

E.g once mounted, windows take notes that this metro board has interface 0 is cdc, next time, it will auto load the cdc driver (usbser) for interface0 without re-analyze the configuration descript...

fallow birchBOT
fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

RIght now our Windows 7 and 8.x drivers require that CDC is at interface 0 (https://github.com/adafruit/Adafruit_Windows_Drivers/pull/5). They have entries like

"%CIRCUIT_PLAYGROUND_EXPRESS% UF2 Bootloader (0018:00)"=DriverInstall, USB\VID_239A&PID_0018&MI_00

Note the MI_00. However, I think I might be able to imitate what Windows 10 does to select a class driver for usbser.sys: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/usb-driver-installation-based-on-c...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1118: Add Video class

@hathach Thank you for confirming this patch on the several boards. That's great it works on your boards!

if size is an issue, we could change to good old color bar pattern or pattern that could be generated without having a huge flash.

Yeah, I am agree with you on the size issue. This weekend I'm going to try to change the video to the generated pattern or somethings to reduce rom size.

Actually, I was going to implement a color bar display but I didn't. Because there were many t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

Actually, I was going to implement a color bar display but I didn't. Because there were many things to consider like as followings, I got tired of doing.
How do I generate color bar patterns? Should I implement BT.2111 or other specification? How do I move color bars? Panning? Zooming? Etc.

@kkitayam wow, color bar actually has more problems than I thought. Actually It is perfectly OK with currently logo implementation. If the color bar take more of your time, we could do it as follow u...

#
hathach
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent
  • If you want to load Usbser.sys automatically, set the class code to 02 and subclass code to 02 in the Device Descriptor. For more information, see USB communications device class. With this approach, you are not required to distribute INF files for your device because the system uses Usbser.inf.
    • If your device specifies class code 02 but a subclass code value other than 02, Usbser.sys does not load automatically. Pnp Manager tries to find a driver. If a suitable driver is not found, ...
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1118: Add Video class

@me-no-dev Thank you for your comment. I am happy that you are interested in this PR!

Could you link me to some docs to see how should I go about changing the format to MJPEG?

Unfortunately, in current status this PR has no support for motion JPEG. To add support for motion JPEG, we need to modify at least _update_streaming_parameters() and _negotiate_streaming_parameters() to handle motion JPEG.

Motion JPEG is a frame-based format, so it should not be too difficult to add supp...

fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

@hathach What I will test is to install a usbser .inf file that uses class and subclass to specify when to load the driver, instead of the current .inf which identifies the device by VID, PID, and interface. So you'll still need to install the driver package, but I hope to stop having to list all the boards in it indvidually. I also should be able to stop having to specify the interface (MI).

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1095: setting keyboard led error

@qingliyu you didn't provide answer to my 2 questions above, especially how do you reproduce the issue.

@dhalbert yeah, it is what it means at current state of the device stack when receiving report via OUT interrupt endpoint. device stack doesn't attempt to parse the report descriptor, and have no idea if report ID is present or not. Therefore, it will present the SET report as it is with report id as 1st byte. When receiving report via control endpoints, the report id and type is explici...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1118: Add Video class

Tested and continue to work great with the color bar. I missed the logo however, the color bar shrink the size from 73KB to 24KB with either RAM or ROM via CFG_EXAMPLE_VIDEO_READONLY is a huge save. It will allow example to run on lots of smaller MCUs. Also the color bar generated code is short and straightforward, which can make it easier for user to do their own customization is a plus.

PS: still doing code review, will merge soon once complete. Only minor changes so far :)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: kkitayam\-add\_uvc
fallow birchBOT
#
dhalbert
[hathach/tinyusb] New comment on issue #1129: tud\_hid\_set\_protocol\_cb\(\) is not called when SET\_PROTOCOL is sent

I tried a device id like:

"USB Serial"=DriverInstall, USB\Class_02&SubClass_02

This does not work because a third-party driver cannot be a class driver: it cannot recognize a device solely by its class (its "Compatible ID"). The .cat file creator complains and throws an error on the above. Instead, a device must be recognized by its complete hardware ID, e.g. USB\VID_0239a&PID_1234. It's not possible to wildcard the PID either.

So I am going to give up on this for now. We ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: linker\-map
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1136 Add linkermap for size analysis
  • linkermap target is added for size analysis, require to install https://github.com/hathach/linkermap
  • ci also include linkermap output for quick and convenient check. Example output is
  • Note -flto can merged all the codes and symbol and mess up the result, therefore NO_LTO=1 should best be used when analyzing size locally.
                                               File |   .text   .data    .bss   Total
-------------------------------------------------------------------...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1122 WiP : MIDI Host

Thank you for your PR and sorry for late response, I have been busy with other work. The PR is still WIP therefore I converted it to draft. Could you update:

  • remove unnecessary files from the PR such as one in _MIDIH.tmp/, and other local used only such as dbg-tusbh.h
  • revert the changes to endpoint (mentioned in review) and audio cs interface (by kasjer)

Note: rp2040 host stack does not work with bulk endpoint just yet, due to the chip limitation that can only carry out 1 bulk tra...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1101 da146xx bus reset and sleep reworked

Sorry for late response, have been busy with other works. To be honest, I still haven't pull out my DA146xx USB board to test with, since I had an issue with flashing its bin previously. Anyway, the changes look good, it mostly to fine tune the bus event handling with precise reset, suspend & resume detection. Therefore I don't think I could do anything better than yours.

PS: If you tested with USCV and has its result, please let me know so that we could update DA146xx status in #1059

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release\-0\.12\.0
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1101: da146xx bus reset and sleep reworked

@kasjer I just re-run the MSC test on nrf52840, it seems to be fine. From the log, device seems to stop response to the Test Unit Ready after BOT MSC Reset. Sometimes a random failure can occur, could you

  1. Re-run the suite to see if still continue to fail
  2. Switch USBCV "Select Test Mode" to Debug and run the only failed test to see if it still fail when running alone.

I am not entirely sure what is wrong, sometime it can be caused by Data toggle mismatched when unstall. Also make s...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1101: da146xx bus reset and sleep reworked

@kasjer no problem at all, I am glad that I could help. Btw, for chapter9 test suite, it is best to test with hid_composite example, since that has remote wakeup attribute set, and the example will attempt to wake system up when suspended while cdc_msc example does not https://github.com/hathach/tinyusb/blob/master/examples/device/hid_composite/src/main.c#L215 . There are 2 tests for this: one host enabled the remote wakeup, another it disables to test if device respect that.

#
csBlueChip
[hathach/tinyusb] New comment on pull request #1122: WiP : MIDI Host

remove unnecessary files

Absolutely! When it is working & tested, you WILL get a CLEAN pull request .

The files in .TMP will ultimately be the MIDI host /examples/, but I want to see the class driver working before I try to use it as a player or synth.

The final version will also NOT contain abominations like : https://github.com/hathach/tinyusb/pull/1122/commits/62b1529f27f694cdd672b64542a92e70cf4c390a#diff-e7025ce0e682cf4e30670612dd559328a733bb6a3ec53e449e51fb7088ef9155R40

.....

fallow birchBOT
#
tannewt
[hathach/tinyusb] Issue opened: #1141 BCM283x \(Raspberry Pi chip\) Support

I'm working on adding TinyUSB support for the DWC USB controller from Synopsys in the Broadcom chips on the Raspberry Pi board (BCM2835, BCM2836, BCM2837 and BCM2711). I've haven't managed to get it working so I wanted to open this issue in case others wanted to help get it going.

My working branch is here: https://github.com/tannewt/tinyusb/tree/rpi I'm targeting the compute module 4 on an IO board first because it has a USB micro B plug on it for device mode.

I've modeled the init seq...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1122: WiP : MIDI Host

...I'm a n00b to "the git(hub) way", and mostly just wanted to make sure I exposed everything here - in case someone else wants to help, or 'steal' some code. [I also need to add MIT headers to all my files]

No problem at all, I am not git expert either, just use some GUI, that make adding file, commit and push easier. I uses git-cola on Linux, but any should do the work.

#
hathach
[hathach/tinyusb] New comment on issue #1095: setting keyboard led error

@qingliyu I see you didn't use the hid_boot_interface as it is, but a custom firmware. It is what confuse me, please make sure you specify it exactly as it is in the bug report. The reason for HID_REPORT_TYPE_INVALID, is lacking of hid parser as mentioned above. For now when encounter this, you need to process the data as how you specify it in the report descriptor i.e read the first byte as report ID if you use report ID for output report. I will try to implement an simple hid parser later ...

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #1142 Video UVC 1\.5 check list

Is your feature request related to a problem? Please describe

UVC is added by #1118 This issue is used to keep track of current status of video class driver on each DCD ports. Once it is all passed, we could close this.

MCU Video Capture Note
nRF52840 :heavy_check_mark:
rp2040 :heavy_check_mark:
KL25z :heavy_check_mark:
SAMD21 :heavy_check_mark:
...
fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on issue #1142: Video UVC 1\.5 check list

Hi @hathach :) I tried UVC last night and found errors in the example descriptor. For one the UUID of the format is wrong (can be seen in dmesg on Linux). Then there are more complaints from the kernel. It is not at all working on Mac and on Windows it shows the camera but fails to init. I will do some more looking into if someone does not do it before me :)

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1142: Video UVC 1\.5 check list

@me-no-dev yeah, I saw my Linux machine complaining about the format as well. haven't tried to find the cause just yet. Please let me know if you could figure out why.

[45883.869206] usb 3-4: Product: TinyUSB Device
[45883.869208] usb 3-4: Manufacturer: TinyUSB
[45883.869209] usb 3-4: SerialNumber: 123456
[45883.877143] uvcvideo: Unknown video format 3231564e-0000-0010-0080-719b3800aa00
[45883.877147] uvcvideo: Found UVC 1.50 device TinyUSB Device (cafe:4020)
[45883.877150] uvc...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1143 Fix GUID of video compression formats

just tested, linux does not complain about the format anymore. Thank you for the PR. Still haven't tried to find an app to test with, will do later on.

[149825.252622] usb 3-3: Product: TinyUSB Device
[149825.252623] usb 3-3: Manufacturer: TinyUSB
[149825.252624] usb 3-3: SerialNumber: 123456
[149825.260633] uvcvideo: Found UVC 1.50 device TinyUSB Device (cafe:4020)
[149825.260637] uvcvideo: No valid video chain found.
fallow birchBOT
#
kilograham
[hathach/tinyusb] Pull request opened: #1145 Address compiler warnings

Consumers of TinyUSB in the RP2040 (or via our stdio support) who wish to set higher warning levels for their project along with -Werror are forced to manually suppress warnings. This change makes life much easier for them

  1. physically suppress warnings in TinyUSB headers using pragmas so they don't break -Werror compilation of external C/C++ source files that include them directly or indirectly
  2. fix all compiler warnings in rp2040 port
  3. add cmake method to rp2040 port to allow an e...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1145: Address compiler warnings

note i didn't go as far as actually fixing all the warnings in TinyUSB itself, though that is something to consider for later

What is the rest of the warnings, I didn't see any with existing build. I normally only run make BOARD=raspberry_pi_pico all maybe I miss some compiler flag ?

examples/device/cdc_msc$ make BOARD=raspberry_pi_pico all
../../rules.mk:154: warning: overriding recipe for target 'clean'
/home/hathach/Dropbox/tinyusb/tinyusb/hw/bsp/rp2040/family.mk:15: warni...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1095: setting keyboard led error

@hathach I seem to understand what you mean๏ผŽUsing TUD_HID_DESCRIPTOR, the ๏ฝ๏ฝƒ will use the control endpoint to transmit. Using TUD_HID_INOUT_DESCRIPTOR, the ๏ฝ๏ฝƒ will use the ๏ผฏ๏ผต๏ผด interruptใ€€endpoint for transmission๏ผŽ

Yeah, it is the case, the device stack does not include an hid parser for now. I will reopen this as reminder to write the parser later on.

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1146 da146xx usb complience

Describe the PR
This resolves to problems that prevent USB3CV compliance test to pass for DA146xx devices.

  • interrupt for EP IN STALL send notification was filling TXFIFO with ZLP that resulted in first command
    wrong response after endpoint was un-stalled.
  • If more data arrived in RX FIFO then were scheduled for reception in dcd_edpt_xfer(), extra bytes were
    left for next read. It resulted in compliance test failure for MSC device.

Now TX FIFO is not filled for stalled endpoint ...

fallow birchBOT
fallow birchBOT
#
mws-rmain
[hathach/tinyusb] Issue opened: #1148 CDC dual port example always echos between ports, but nothing to do with 'cdc\_task\(\)'

Operating System

Windows 10

Board

Curiosity Nano (ATSAMD21G17D)

Firmware

examples/device/cdc_dual_ports

What happened ?

The CDC dual port example is supposed to 'echo' received characters from either port to both ports (lower case to one port, upper case to other port).
When I connect my 'curiosity nano' board (ATSAMD21G17D) to a Windows 10 PC, two additional Comm ports are visible after it enumerates. I open two instances of 'TeraTerm', one attached to each port. Tera...

fallow birchBOT
fallow birchBOT
#
tfx2001
[hathach/tinyusb] Pull request opened: #1149 add rt\-thread software package support

Hi,

This PR based on #637 by supporting RT-Thread RTOS. TinyUSB has been registered to the RT-Thread software packages center. Developers can use TinyUSB more easily by installing the TinyUSB package in package manager center.

This PR includes two SConscript files. RT-Thread uses Scons to organize files rather than CMake or Makefile, so it will not cause any conflicts with existing Makefiles. Meanwhile, this PR also conta...

fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] New comment on pull request #1145: Address compiler warnings

UPDATE: I see, adding those -W option, I will try to fix these warnings within the stack.

yeah gcc is being a bit weird with uint16_t ... so some of them are slightly spurious

(note we don't by default build with higher warnings, however we do test our SDK with them, because some users (and some projects) use higher warning levels by default) (and -Werror)

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-warnings
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1145 Address compiler warnings

yeah gcc is being a bit weird with uint16_t ... so some of them are slightly spurious
(note we don't by default build with higher warnings, however we do test our SDK with them, because some users (and some projects) use higher warning levels by default) (and -Werror)

the more compiler flag, the better, I am making an PR to addrss the -Wcasl-qual after the release https://github.com/hathach/tinyusb/tree/fix-warnings . The warning make sense and worth the effort to resolve. `-Wredu...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1146 da146xx usb complience

Here are test results: This time Chapter 9 tests were run on HID with remote wake up tested. USB3CV.zip

Superb !! great effort to get DA146xx fully passed the USBCV.

For reference behavior I used STM32F407 board that was working as test expected. ~For some reason when MSC tests were run on PCA10056 it was failing almost all tests I'm not sure if this was just my board or some regression snicked in.~ I used Pr...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1150: UVC example: change input terminal type to camera from external

@kkitayam it has improvement, linux now attempt to GET_DEF(PROBE), I have no idea what that means now, but definitely better pre-PR

[207416.877205] usb 3-4: new full-speed USB device number 87 using xhci_hcd
[207417.043275] usb 3-4: New USB device found, idVendor=cafe, idProduct=4020, bcdDevice= 1.00
[207417.043279] usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[207417.043280] usb 3-4: Product: TinyUSB Device
[207417.043281] usb 3-4: Manufacturer: TinyUSB
[2...
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1149 add rt\-thread software package support

Thanks for your PR to improve the rt-thread port. I am not familiar with SConscript, but I will give a try whenever I could. However, there is a few changes I would like to make

  • the rt-thread/README.md is very helpful, but it should be added to the docs/ instead https://github.com/hathach/tinyusb/tree/master/docs/reference
  • all the *.c and tusb_congifg.h under rt-thread must be removed. These are application specific files in the usb stack point of view and shouldn't be placed u...
fallow birchBOT
fallow birchBOT
#
mws-rmain
[hathach/tinyusb] New comment on issue #1148: CDC dual port example always echos between ports, but nothing to do with 'cdc\_task\(\)'

The problem turned out to be a broken installation of 'com0com' I had installed long ago. The two com ports created by com0com don't appear in the list of ports in device manager (Win10/64bit), but do appear in the TeraTerm serial port list. Somehow (because Win10 doesn't list them in device manager?) windows sees them as 'free to allocate' (although they were still serviced by com0com... very odd).
I fixed this temporarily by pushing the TinyUSB serial ports to different port numbers, and...

fallow birchBOT
#
mws-rmain
[hathach/tinyusb] New comment on issue #1148: CDC dual port example always echos between ports, but nothing to do with 'cdc\_task\(\)'

Thanks, Dan.
Seems like some interesting & useful utilities at that link. I'll be bookmarking it for general reference, and I've downloaded the cleanup tool to help me clean up ports right now.
In my case, I found the installation program for com0com I used & used it to 'de-install'. The build was old (circa 2016), so that may have played a part in Win10-64b not properly/fully recognizing it's ports. I think it was prudent to use this specific tool to un-install, then clean up generally, gi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.12\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1150: UVC example: change input terminal type to camera from external

@me-no-dev I haven't tested with esp32s2. One note that although using the same synopsys dwc as stm32, stm32 driver receive more update and implementation to support ISO transfer and other improvement by other contributors. I have an plan to sync the driver of esp32s2 and/or unify the synopsys dwc2 ( since it is very common) but haven't got time to do so. I will try to pull out the esp32s2 to test with uvc/uac later on. It probably needs to have some fifo allocation update etc ...

#
me-no-dev
[hathach/tinyusb] New comment on pull request #1150: UVC example: change input terminal type to camera from external

@hathach it's not an S2 driver problem. I am using BULK endpoints (grabbed a descriptor from a working camera). It's something that TinyUSB does not like about the descriptor, because other devices work fine (and SET_CONFIG is ACKed).
Question is more, do you have any idea what TinyUSB might not like in the descriptor (it is parsed OK by the OS and all... working camera descriptor)

#
hathach
[hathach/tinyusb] New comment on pull request #1150: UVC example: change input terminal type to camera from external

@hathach it's not an S2 driver problem. I am using BULK endpoints (grabbed a descriptor from a working camera). It's something that TinyUSB does not like about the descriptor, because other devices work fine (and SET_CONFIG is ACKed). Question is more, do you have any idea what TinyUSB might not like in the descriptor (it is parsed OK by the OS and all... working camera descriptor)

if the config parser spot something unusual, it will normally output through the uart log. Could you enable...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #1150: UVC example: change input terminal type to camera from external

I doubt this is chip specific :) here is the descriptor:

const uint8_t jpeg_cam_descriptor[] = {
    // Interface Association   Video/Interface Collection
    0x08,        // bLength
    0x0B,        // bDescriptorType (Interface Association Descriptor)
    0x00,        // bFirstInterface 0
    0x02,        // bInterfaceCount 2
    0x0E,        // bFunctionClass 14 (Video)
    0x03,        // bFunctionSubClass 3 (Interface Collection)
    0x00,        // bFunctionProtocol 0
...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] Pull request opened: #1153 net\_lwip\_webserver: allow users to enable LWIP\_IP6 if desired

net_lwip_webserver and ./lib/networking/ code is tweaked to allow the user to enable LWIP_IP6 if desired.

To allow legacy code to compile, lwip's ip_addr_t maps into the newer ip4_addr_t type when LWIP_IP4 is enabled but LWIP_IP6 is not enabled. However, if both LWIP_IP4 and LWIP_IP6 are enabled, ip_addr_t maps to a struct with a union for both ip4_addr_t and ip6_addr_t. Since the ./lib/networking/ code was written for IPv4 only and presumes IP4-only lwip, the previous code breaks. Some...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1149: add rt\-thread software package support

RT-Thread is not just a kernel. RT-Thread contents a device driver framework layer which will provide a uniform API for users. These *.c files port for device driver framework rather than a specific application.
If it's not appropriate to place them in osal/rt-thread, where should I place them?

yes, and device driver framework should be placed on top of the usb stack not inside it. I am not familiar enough with rt-thread to give suggestion.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Issue opened: #1154 NRF5x startup race condition between VBUS interrupt and stack initialization

Operating System

Linux

Board

pca10095 should be same for pca10056 or other NRF

Firmware

TinyUSB 0.12.0

What happened ?

Board initialization for NRF5x (board_init() or equivalent) enables VBUS interrupt.
Later USB stack is initialized in tusb_init().
If VBUS interrupt fires before tusb_init() finishes, it can enable normal USB interrupt before tusb_init() would do it.
Then normal USB interrupt tries to post BUS RESET event and _usbd_q may not be ready yet and that...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1149 add rt\-thread software package support

Thank you for your patience in explaining. So I move them out of the tinyusb/src and make a new folder sys/rt-thread to place them. Please review.

No problems, however this is still not correct way to add these, in fact we cannot put these in this repo. Sorry if I am not making it clear enough. Files such as descriptors, msc device which implement callbacks are application scope. Although you tried to make it easier for rt-thread user, those still belongs to application and canno...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: tannewt\-rpi
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1150 UVC example: change input terminal type to camera from external

Just tested and it works great. Linux no longer complains about unsupported request. I still haven't found an application similar to virtualdub but this PR is already great enough to merge

[  253.418744] usb 3-2: new full-speed USB device number 11 using xhci_hcd
[  253.595921] usb 3-2: New USB device found, idVendor=cafe, idProduct=4020, bcdDevice= 1.00
[  253.595922] usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  253.595923] usb 3-2: Product: TinyUSB Device...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kamathba
[hathach/tinyusb] New comment on issue #884: net\_lwip\_webserver reaches "endpoint busy" race condition on STM32F411DISCO

This does seem to be resolved on the latest master. Webserver is functional and original problem can't be reproduced.

[ 1518.835363] usb 1-1.1.1: new full-speed USB device number 15 using xhci_hcd
[ 1518.949582] usb 1-1.1.1: New USB device found, idVendor=cafe, idProduct=4020, bcdDevice= 1.01
[ 1518.949585] usb 1-1.1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1518.949586] usb 1-1.1.1: Product: TinyUSB Device
[ 1518.949587] usb 1-1.1.1: Manufacturer: TinyUSB
[ 1...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rm\-ep\-size\-bitfield
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1160 msp430x5xx: Set base of transmit\_packet buffer earlier to avoid increโ€ฆ

Superb ! Thank you for looking at this, this is my bad, I didn't pay attention enough to variable queued_len (got changes).

Yeah, you are right, msp430 does not support ISO transfer. Though the dcd_edpt_xfer_fifo()` can still be useful, it allows the driver such as cdc to interact directly using fifo rather than an continuous linear buffer as a middle-man. I haven't got time to make use of that, but we could optimize that later on.

fallow birchBOT
#
todbot
[hathach/tinyusb] Pull request opened: #1162 Properly handle Program Change and Channel Aftertouch messages

Describe the PR
MIDI Program Change and Channel Aftertouch messages are not currently handled. They are sent correctly by accident, depending on leniency of host OS version and if tud_midi_n_stream_write() is called with a buffer containing a whole message buffer and not byte-by-byte. These types of MIDI messages are 2-bytes long (instead of the common 3-bytes) and tud_midi_n_stream_write() doesn't have case to handle them. This PR adds that case.

Additional context
See issu...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: generalize\-synopsys\-dwc2
#
hathach
[hathach/tinyusb] Pull request opened: #1163 Generalize synopsys dwc2

Describe the PR
Generalize Synopsys DWC2 driver, implement #382 . New driver is at synopsys/dwc2 For the time being, application can still pick the existing driver e.g st/synopsys/dcd_synopsys.c for stm32. Using this generalized driver is user choice until proven reliably.

MCUs that use DWC2

  • ST STM32 (F4, F7, H7 etc ..) OTG
  • Espressif ESP32 S2/S3
  • Giga GDVF103
  • Silabs EFM32
  • Broadcom bcm28/27 on RPi

Ref: linux driver for dwc https://github.com/torvalds/linux/tree/mast...

fallow birchBOT
fallow birchBOT
placid crown
#

Not sure if anyone but bots live here, but does anyone have suggestions for reliably compiling tinyusb on MacOS? Out of the box TinyUSB doesn't compile because MacOS ships with rather ancient 2006 version of GNU Make 3.81 and TinyUSB's makefile uses newer features. I can install Make 4.3 as "gmake" with homebrew and build for SAMD21 with gmake BOARD=itsybitsy_m0 but I cannot gmake BOARD=raspberrypi_pico. It gives the error:

bok4bok3:~/projects/adafruit/tinyusb-todbot/examples/device/midi_test/
% gmake BOARD=raspberry_pi_pico
../../rules.mk:154: warning: overriding recipe for target 'clean'
/Users/tod/projects/adafruit/tinyusb-todbot/hw/bsp/rp2040/family.mk:15: warning: ignoring old recipe for target 'clean'
gmake -C _build/raspberry_pi_pico
gmake[1]: Entering directory '/Users/tod/projects/adafruit/tinyusb-todbot/examples/device/midi_test/_build/raspberry_pi_pico'
gmake[1]: *** No targets specified and no makefile found.  Stop.
gmake[1]: Leaving directory '/Users/tod/projects/adafruit/tinyusb-todbot/examples/device/midi_test/_build/raspberry_pi_pico'
gmake: *** [/Users/tod/projects/adafruit/tinyusb-todbot/hw/bsp/rp2040/family.mk:12: all] Error 2

I can build with the pico-sdk otherwise just fine. I'm cool with MacOS being an unsupported build platform for TinyUSB but it seems so close!

glacial stratus
#

I thought homebrew would just do that

placid crown
#

and yes, that is the make I have installed

glacial stratus
placid crown
#

yes, thanks, but that is not my problem. I am running the latest make

#

I should not have brought it up

glacial stratus
#

right, but it is called gmake, and the sub-builds are using the old make?

#

maybe

placid crown
#

it does not appear to be. I've added latest make to the top of my path and I still get the same error when doing make BOARD=raspberry_pi_pico

#

oh no wait...

#

doing a make clean and it seems to be working now that newer make is at top of path. SIGH. thanks Dan for getting me to check that for the 30th time ๐Ÿ™‚

glacial stratus
#

np ๐Ÿ™‚ my attempts at the past to try to develop on the Mac (only out of necessity) have always led to hair-pulling.

#

case-insensitive filesystems, etc.

placid crown
#

that was my experience several years ago, but it's been pretty good lately. And yeah, both Windows & Mac are guilty of the case-presevering-but-insensitive silliness ๐Ÿ™‚

#

at least Homebrew has made the Python install situation so much better than it was five or so years ago

fallow birchBOT
#
DatanoiseTV
[hathach/tinyusb] Issue opened: #1169 2/3 CDC Endpoints working, can't get 3rd to work

Operating System

Others

Board

RP2040

Firmware

https://forums.raspberrypi.com/viewtopic.php?t=322460

What happened ?

I have forked picoprobe firmware for RP2040, added a 2nd CDC UART Bridge and a SUMP-Logic analyser, but the 3rd CDC Endpoint won't work.

How to reproduce ?

Compile firmware mentioned in Link, upload, try picocom on ttyACM0, ttyACM1, ttyACM2. The ACM on endpoint 3 will make the computer hang.

Debug Log

No response

Screenshots

No response

fallow birchBOT
#
todbot
[hathach/tinyusb] New comment on issue #1169: 2/3 CDC Endpoints working, can't get 3rd to work

Hi,
TinyUSB works fine with three CDC ports. I've created a gist that is a light editing of the examples/device/cdc_dual_ports in current TinyUSB, located here: https://gist.github.com/todbot/d4f4e0111c7829fd55b0c3b68114d9a5

Tested it on a Raspberry Pi Pico connected to a MacOS laptop, all three ports work as expected.

Which version of TinyUSB are you using? I know the pico-sdk used an older fork awhile back.

fallow birchBOT
vital oracle
#

I tried to run hid_composite_freertos on esp32s2 but it results in a fatal fault

unknown.png
vital oracle
#

Any in my other project with TinyUSB on esp32s2, tud_task(); just hangs

#

My log told me it stopped between line 485 and line 494 which makes no sense to me

unknown.png
fallow birchBOT
#
DatanoiseTV
[hathach/tinyusb] New comment on issue #1169: 2/3 CDC Endpoints working, can't get 3rd to work

yeah, please provide:

  1. the git hash of tinyusb you are compiling with. If it matches current git master and issue still exists
  2. provide the project file to compile with in the format similar to this repo's example (whole .c + .h for code and descriptors), you could base your example on the existing dual cdc one here https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_dual_ports
  1. The TinyUSB in my pico-sdk is at d49938d0.
  2. The source is at https://gitlab....
fallow birchBOT
#
DatanoiseTV
[hathach/tinyusb] New comment on issue #1169: 2/3 CDC Endpoints working, can't get 3rd to work 
1. your tinyusb version is too old, please use the one in the github

2. your example need to be more simplified to reduce as much application-code so that we are sure it is stack bug and not app's one. Please modify the stock example to have similar config to see if it has the same issue with 3 cdcs.
  1. Will do asap and try again.
  2. I can do that - the problem seems to be with the 3rd descriptor, because if i put cdc_uart or my logic analyzer code on descriptor 2, then i...
fallow birchBOT
#
DatanoiseTV
[hathach/tinyusb] New comment on issue #1169: 2/3 CDC Endpoints working, can't get 3rd to work

I've tried on HEAD, but compile / link errors are rising - got to sort it out first.

/usr/local/Cellar/arm-none-eabi-gcc/10.3-2021.07/gcc/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: CMakeFiles/picoprobe.dir/Users/x/dev/pico-sdk/lib/tinyusb/src/portable/raspberrypi/rp2040/rp2040_usb.c.obj: in function `_hw_endpoint_start_next_buffer':
rp2040_usb.c:(.text._hw_endpoint_start_next_buffer+0x5c): undefined reference to `tu_u32_low16'
/usr/local/Cellar/arm-none-ea...
glacial stratus
vital oracle
glacial stratus
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1172: Adds support for Adafruit's Trinket M0

it only makes sense if this repo providing board abstraction for application. Unfortunately, I have no intention to do so. The whole bsp and examples in this repo is only used to demonstrate how tinyusb API is used, and prove and test that it works on hardware. These can be changed completely without any notices.

Sum up application and user should write their own bsp init code for their own board. Therefore please remove the weak attribute in the function.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #126: Port STM32 L4

while working on generalizing DWC2 driver, I find out that L4 indeed use an different revision 3.10a vs 2.81a on F407. This revision or at least on L4, both SETUP and XFRC bit is also set on DOEPINT when new set up received (while the on other mcu only SETUP bit is set). This cause dcd to register 2 events for the setup recived (1 for setup, 1 for 0 byte data). which confuse the usbd.

Note; on F7 with revision 3.20a, only SETUP is set, so it is not sure this only happens on L4 with 3.10a,...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #126: Port STM32 L4

Update: this is indeed a bug (or feature) of the dwc2 3.10a where it will set both OUT transfer Complete ISR first, then Setup Complete ISR afterwards in one single setup packet. confirmed in the ST hal code https://github.com/STMicroelectronics/STM32CubeL4/blob/master/Drivers/STM32L4xx_HAL_Driver/Src/stm32l4xx_hal_pcd.c#L2213

I tested with L4P5, which use 3.30a and does not has the same issue. That explain why some could get it running in some variants of L4 mcu.

Some debug logging i...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #126: Port STM32 L4

On this paritcular L476 rev 3.10a (or maybe based on actual configuration), additional transfer complete ISR is triggered in 2 event

  • setup received
  • control write data complete.

This has been addressed by following commit, this could be closed when generic dwc2 branch is merged.
https://github.com/hathach/tinyusb/pull/1163/commits/aa682d730123a1191782b1a160ce25ea20580ee6#diff-1f2490fb8ceeb23801391e207e1972f09dd6a7fbbe431154211cc1896dc363a0R1003-R1023

fallow birchBOT
fallow birchBOT
#
tannewt
[hathach/tinyusb] New comment on pull request #1163: Generalize synopsys dwc2

From what I can tell this is a caching issue, not an interrupt one. The first gig of memory is marked as cachable now. If I change it to non-cacheable then the problem goes away. Does the DWC write to or read from any memory directly? It would need to be invalidated or cleaned if so.

diff --git a/broadcom/mmu.c b/broadcom/mmu.c
index 098c728..3eefaac 100644
--- a/broadcom/mmu.c
+++ b/broadcom/mmu.c
@@ -24,7 +24,7 @@ void setup_mmu_flat_map(void) {
     for (uint64_t i = 1; i ...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1163: Generalize synopsys dwc2

Thanks to Scott hint, I have narrowed it down to

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1178 broadcom/dcd: Fix mynewt build

Describe the PR
dcd_synopsys.c included broadcom/interrupts.h before
preprocessor check whether file should be used.

Since mynewt build does not include all folders it resulted in build
error.

Now offending include is moved few lines after preprocessor check.

Additional context
No change in logic.
No build should be negatively affected by this change.

fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New branch created: perigoso\-patch\-1
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1178: broadcom/dcd: Fix mynewt build

Why also guard the common include and the USE_SOF define?

newt build system and other build system with auto-generate makefile such as arduino include all (dcd) sources files by default. When BCM2711 is not its target mcu, the include path of broadcom peripherals is not set and not even checkout. It is typical for dcd driver to check for mcu supported before including its peripheral header.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-xmc4500
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1182 Update bth for IAD support

Describe the PR
IAD was missing from BT interface descriptor macro.
This in itself did not matter much but it is in the specification so descriptor is updated now.

With missing IAD BT driver handled open separately for both interfaces.
For some time now BT is assumed to have 2 associated interfaces even when IAD is missing.
This inferred association resulted in only one call to btd_open() and second interface was no
handled at all.
This in turn resulted in assertion f...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1014: Port STM32 G4

I have an G474 nucleo and add bsp support for it (blinky and button work fine)

However, the board does not has usb connector and need to use usb breakout cable similar to the nucleo070 board. I tried a bit but couldn't get usb clock/pin set up probably. At the moment, I don't have time to go through its datasheet. If anyone could get the hardware side correct, I could get the rest running.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] Pull request opened: #1183 Add support for TI MSP\-EXP432E401Y

Describe the PR
Add support for MSP-EXP432E401Y as a DCD.

This patch has no support for followings.

  • Handling the dedicated DMA for USB
  • Handling ULPI for high speed PHY

I have checked that following examples work with Windows 10.

  • cdc_msc
  • cdc_msc_freertos
  • net_lwip_webserver
  • uac2_headset
  • video_capture

And I did the USB3CV test for CH.9, HID and MSC. CH.9 and HID passed, but MSC failed.

Additional context
This d...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1183 Add support for TI MSP\-EXP432E401Y

Brilliant work, indeed, this mentor graphic is used widely on most of TI arm mcu. A quick google show that other TI also use this

  • TMS320F28069
  • Stellaris LM3S
  • TM4C (tiva C), the msp432E is actually a re-branded from tm4c-129x

I have an TM4c123x launchpad board and could help to test it out, give me a bit of time to get its bsp set up. Btw the core is called "USB 2.0 MULTI-POINT DUAL-ROLE CONTROLLER". Databook for is actually downloadable online by googling musbmhdrc

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1183: Add support for TI MSP\-EXP432E401Y

no worry about DMA, FIFO based actually can help to reduce the interim buffer from class driver e.g CDC. Although it is less idea on mcu with large SRAM, it give option to run it more efficiently on smaller mcu. I have an plan to drop class driver interim EP Buffer on supported DCD later on (selectable).

For ULPI, not really an issue as well, those requires board with external PHY and the software setup/config is pretty straightforward from my exp with stm32h743. Those can wait :)

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1183: Add support for TI MSP\-EXP432E401Y

Thank you for your comments. After https://github.com/hathach/ti_driver/pull/4 is merged, I will update the submodule for TI driver and status to ready for review.

FIFO based actually can help to reduce the interim buffer from class driver e.g CDC. Although it is less idea on mcu with large SRAM, it give option to run it more efficiently on smaller mcu. I have an plan to drop class driver interim EP Buffer on supported DCD later on (selectable).

Yeah, I agree and that's good.

Actu...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1183: Add support for TI MSP\-EXP432E401Y

Thank you for your comments. After hathach/ti_driver#4 is merged, I will update the submodule for TI driver and status to ready for review.

merged !!

Actually, I didn't have boards with support for high speed, so I bought the board. But, I had not been know an optional board needed. disappointed After implement this patch, I have know it...

Yeah, I totally understand your feeling from my own experience. They didn't make it very clear from the feature page.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1183 Add support for TI MSP\-EXP432E401Y

Superb!! Although I don't have an msp432e to test with, but the dcd musb work flawlessly with tiva-C tm4c123 testing with cdc_msc and net_lwip_webserver (bsp is cherry-picked from #670). I did push the changes and enable ci for both msp432e & tm4c123. So please pull first if you still plan to push more code

I haven't looked at the code thoroughly, but it looks great as usual. Except the hacking generalized code I just added for tm4c. This PR is great enough for the merge. @kkitayam please ...

fallow birchBOT
fallow birchBOT
faint nexus
#

@robust walrus here i am ๐Ÿ™‚
i can find the usb related config files in micropython, but i cant find anything (even with search) in the circuitpython repo. what am i missing?

robust walrus
#

what OS are you on?

#

wireshark can sometimes help with getting descriptors setup

faint nexus
#

let me have a look

#

linux

robust walrus
#

k, I'm on linux too

faint nexus
#

here is my lsbusb -v output for my pro micro which i succesfully use with hid-project library as hid and serial device at the same time

๐Ÿ“Ž SPOILER_message.txt
robust walrus
#

we do have newer configurable composite descriptors but the static bits shouldn't be too weird

faint nexus
#

it all looks relatively simple, it's just so much new at the same time ๐Ÿ˜‰

robust walrus
#

ya, USB isn't simple

#

how is the new tinyusb descriptor failing?

faint nexus
#

mh, i just tried to jerry rig the cdc component into my already working (and copied) hid code

#

so now its not really connecting and lsusb tells me it cant read the usb descriptors

robust walrus
#

have you tried wireshark?

#

that may give you more info

faint nexus
#

no not yet. let me install it

robust walrus
#

I usually have a beagle usb sniffer to help debug as well

faint nexus
#

Invalid descriptor length: 5

#

first hint ๐Ÿ™‚ thx to wireshark

robust walrus
#

๐Ÿ˜„

faint nexus
#

@robust walrus

unknown.png
#

do you know which number this is in code?

glacial stratus
#

we should look at the USB descriptor definitions in your C code

faint nexus
#

aha! i found my mistake
#define CONFIG_TOTAL_LEN (TUD_CONFIG_DESC_LEN + TUD_HID_DESC_LEN) -> #define CONFIG_TOTAL_LEN (TUD_CONFIG_DESC_LEN + TUD_HID_DESC_LEN + TUD_CDC_DESC_LEN)

#

now probably have something missing in my code, because the usb "handshake" is not really working now.

fallow birchBOT
faint nexus
fallow birchBOT
faint nexus
#

@robust walrus sorry to ping you again
i got the serial communication working and i am already debugging through it. now my hid commands are doing nothing. do you have a tip for me on how to debug it? Could/should i debug that with wireshark?
lsusb seems to report everything correctly now

robust walrus
#

dan has done our HID stuff

faint nexus
#

danh?

robust walrus
#

yup

faint nexus
#

@glacial stratus hey ๐Ÿ™‚ sorry to bother you this directly. do you mind helping me out?

glacial stratus
#

np. do the HID devices show up on the host?

faint nexus
#

cdc device showing up and working, hid showing up, but not working

glacial stratus
#

what is the host computer? is it linux?

faint nexus
#

yes

glacial stratus
faint nexus
#

ok. give me a sec

glacial stratus
#

can you turn off the CDC descriptors for now, so you can just see the bad HID descriptors?

faint nexus
#

the hid alone worked, so i believe that i do something wrong when using both togehter

glacial stratus
#

this is fishy iInterface 4 (error)

#

then how about the CDC without HID?

faint nexus
#

let me try that real quick

#

ok, i need to comment out all the hid stuff, or it wont compile. thats a bit much now because i have to go to the gym in 15mins.
can i come back to you later?

#

before i leave @glacial stratus ```
0x09, // bLength
0x02, // bDescriptorType (Configuration)
0x64, 0x00, // wTotalLength 100
0x03, // bNumInterfaces 3
0x01, // bConfigurationValue
0x00, // iConfiguration (String Index)
0xA0, // bmAttributes Remote Wakeup
0x32, // bMaxPower 100mA

0x08, // bLength
0x0B, // bDescriptorType (Unknown)
0x00, 0x02, 0x02, 0x02, 0x00, 0x00,
0x09, // bLength
0x04, // bDescriptorType (Interface)
0x00, // bInterfaceNumber 0
0x00, // bAlternateSetting
0x01, // bNumEndpoints 1
0x02, // bInterfaceClass
0x02, // bInterfaceSubClass
0x00, // bInterfaceProtocol
0x04, // iInterface (String Index)

0x05, // bLength
0x24, // bDescriptorType (Dependant on Type)
0x00, 0x20, 0x01,
0x05, // bLength
0x24, // bDescriptorType (Dependant on Type)
0x01, 0x00, 0x01,
0x04, // bLength
0x24, // bDescriptorType (Dependant on Type)
0x02, 0x02,
0x05, // bLength
0x24, // bDescriptorType (Dependant on Type)
0x06, 0x00, 0x01,
0x07, // bLength
0x05, // bDescriptorType (Endpoint)
0x81, // bEndpointAddress (IN/D2H)
0x03, // bmAttributes (Interrupt)
0x08, 0x00, // wMaxPacketSize 8
0x10, // bInterval 16 (unit depends on device speed)

0x09, // bLength
0x04, // bDescriptorType (Interface)
0x01, // bInterfaceNumber 1
0x00, // bAlternateSetting
0x02, // bNumEndpoints 2
0x0A, // bInterfaceClass
0x00, // bInterfaceSubClass
0x00, // bInterfaceProtocol
0x00, // iInterface (String Index)

0x07, // bLength
0x05, // bDescriptorType (Endpoint)
0x02, // bEndpointAddress (OUT/H2D)
0x02, // bmAttributes (Bulk)
0x40, 0x00, // wMaxPacketSize 64
0x00, // bInterval 0 (unit depends on device speed)

0x07, // bLength
0x05, // bDescriptorType (Endpoint)
0x82, // bEndpointAddress (IN/D2H)
0x02, // bmAttributes (Bulk)
0x40, 0x00, // wMaxPacketSize 64
0x00, // bInterval 0 (unit depends on device speed)

0x09, // bLength
0x04, // bDescriptorType (Interface)
0x02, // bInterfaceNumber 2
0x00, // bAlternateSetting
0x01, // bNumEndpoints 1
0x03, // bInterfaceClass
0x00, // bInterfaceSubClass
0x00, // bInterfaceProtocol
0x00, // iInterface (String Index)

0x09, // bLength
0x21, // bDescriptorType (HID)
0x11, 0x01, // bcdHID 1.11
0x00, // bCountryCode
0x01, // bNumDescriptors
0x22, // bDescriptorType[0] (HID)
0x5C, 0x00, // wDescriptorLength[0] 92

0x07, // bLength
0x05, // bDescriptorType (Endpoint)
0x81, // bEndpointAddress (IN/D2H)
0x03, // bmAttributes (Interrupt)
0x10, 0x00, // wMaxPacketSize 16
0x05, // bInterval 5 (unit depends on device speed)

// 100 bytes

faint nexus
glacial stratus
#

it's easier to look over. I can compare it with our own similar descriptors

#

are you away for a while?

faint nexus
#

yeah sorry :/ max 3 hours. going to the gym+groceries with my wife

faint nexus
#

@glacial stratus i just compared the usb report of my working freedeck with my pi pico. there are some sublte changes

glacial stratus
#

sorry, i was interrupted by a bunch of things and didn't get to look at this yet

#

also you can see the lsusb if you install CircuitPython on the Pi Pico. That will be similar

#

This should not be "unknown":

0x08,        // bLength
0x0B,        // bDescriptorType (Unknown)
0x00, 0x02, 0x02, 0x02, 0x00, 0x00,
#

i am out for the evening in a few minutes, sri

faint nexus
#

im comparing it against circuitpython right now!

glacial stratus
#

circuitpython has midi also, but that should be straightfoward

faint nexus
#

left -> circuitPython

unknown.png
glacial stratus
#

ok, I thought that was fishy, but apparently not ๐Ÿ™‚

faint nexus
#

im currently changing the usb_descriptor.c step by step and copying the hex dump from wireshark to compare it ๐Ÿ™‚

faint nexus
faint nexus
#

i slowly changed my code to his code until i came to thid define #define EPNUM_HID 0x84

#

in my code it was 0x81. and i also have this defined in my code #define EPNUM_CDC_NOTIF 0x81 #define EPNUM_CDC_OUT 0x02 #define EPNUM_CDC_IN 0x82
so i upped the number to 0x84 and then it worked also with my code. i could even lower it to 0x83. makes kinda sense now ๐Ÿ˜„

fallow birchBOT
fallow birchBOT
#
TheMindVirus
[hathach/tinyusb] Issue opened: #1186 TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

Operating System

Windows 10

Board

Raspberry Pi Pico RP2040 and Adafruit Macropad RP2040

Firmware

Pico C SDK Firmware Examples (and the same in Arduino IDE)

What happened ?

Set up
Standard Raspberry Pi Pico RP2040 and also Adafruit Macropad RP2040
Windows 10 Pro with Pico SDK, Recommended ARM GCC and additionally Arduino IDE
Windows 10 Pro Runtime OS Device Manager and additionally Windows 10 on ARM with the same universal device behaviour

Describe the bug...

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #1187 tud\_cdc\_connected\(\) or tud\_cdc\_line\_state\_cb\(\) problem when unplug USB connector

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

Originally posted by mastupristi November 11, 2021
hi,
I'm using tinyUsb 0.12.0, on i.MX RT1051.
I'm successfully using the tud_cdc_line_state_cb() callback to be notified when on the PC I connect/disconnect to the ttyACM0 (on PC I use minicom).
The scenario is: with the usb cable plugged in I run minicom and the tud_cdc_line_state_cb() is called with dtr=1. In the moment I quit minicom the `tud_cdc_li...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rppicomidi
[hathach/tinyusb] Issue opened: #1192 Error on plug and unplug of keyboard from USB Host

Operating System

Others

Board

raspberry pi pico (rp2040)

Firmware

examples/host/cdc_msc_hid/ master branch commit 6f59a2c

I am developing in Visual Studio Code and using a picoprobe for debug and serial console display.

What happened ?

The first time you plug a keyboard to the pico board, the keyboard works fine. The second time, the host fails to request a report and the keyboard does not work.

I did some digging on this and have two commits that seem to fix the ...

fallow birchBOT
#
rppicomidi
[hathach/tinyusb] Pull request opened: #1193 Implement usbh replug on pico

This pull request resolves issue #1192 in my testing.

When I was debugging the issue, I found that the host could not send report requests because the endpoint was claimed already. The first commit implements hcd_device_close() more completely so the hardware does not think the endpoints are doing anything and the second commit clears the claimed and busy flags for the device endpoints.

I am very new to this project. Is directly clearing the claimed and busy flags safe?

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-dwc2\-XCVRDLY
vital oracle
#

For some reason my tud_task() is blocking my code

#

I'm in ESP32S3 with FreeRTOS. ESP-IDF 4.4. Latest TinyUSB master branch

#

I spent last 8hrs tring to figure this out but got no luck

fallow birchBOT
#
203Null
[hathach/tinyusb] Issue opened: #1196 Issues with ESP32\-S3

Operating System

Windows 10

Board

ESP32-S3-DevKitC-1

Firmware

examples\device\cdc_msc_freertos

What happened ?

tud_task() caused a crash in examples\device\cdc_msc_freertos

How to reproduce ?

Compile the example for espressif_addax_1. (I know it's not the same board, but I can't tell any difference)

Debug Log

ESP-ROM:esp32s3-20210327
Build:Mar 27 2021
rst:0xc (RTC_SW_CPU_RST),boot:0x8 (SPI_FAST_FLASH_BOOT)
Saved PC:0x4201ee3e
0x4201ee3e: esp_pm_imp...

robust walrus
#

@vital oracle I think the expectation is that tud_task runs in its own freertos task on esp. that's the case in circuitpython

vital oracle
#

I believe I tried both and both are not working but I will have to double check

robust walrus
#

circuitpython runs it off of app_main

vital oracle
#

Official examples runs it in itโ€™s own task (Well the example doesnโ€™t work for me, soโ€ฆ.)

robust walrus
vital oracle
#

So it does run in itโ€™s own task

robust walrus
#

ya

vital oracle
#

This did not result in a crash

#

But "TUSB Task" debug log only printed once

#

For some reason

#

This is a crash

#

After change #define USBD_STACK_SIZE (3configMINIMAL_STACK_SIZE/2) to (3configMINIMAL_STACK_SIZE) there no longer is a crash

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1196: Issues with ESP32\-S3

currently, the tud_task() won't return, it will pend until there is new event. I have been thinking to tweak this behavior a bit, may do it later on. This issue is now closed, since it is not bug but a stack overflow.

I guess it is a bug for the examples but not the stack.

yeah, you are right, I don't have any esp3s3 now for testing, will update it later one when testing with one.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
faint nexus
#

hey, can anybody help me with putting my tud_task in a seperate thread? im running it on a pi pico

robust walrus
#

what are you using to manage threads? in CP we don't have it in a separate thread

fallow birchBOT
#
LYC584520
[hathach/tinyusb] Issue opened: #1200 tud\_hid\_report\(\) can't send report after hot pluged

Operating System

Windows 10

Board

STM32F405

Firmware

examples/device/hid_generic_inout
F405RG1.zip

What happened ?

I tested tinyUSB example on a STM32F405 board with OTG_HS full speed port. It works fine the first time plugged in, when i hot pluged, tud_hid_report() can't send report decause of failure of tud_hid_ready().

How to reproduce ?

Increase the sending interval.

Debug Log

_No response...

faint nexus
#

works like a charm

#

@robust walrus

#

but now i got a py-serial problem ๐Ÿ˜…
i programmed a serial api wrapper which completely works with the arduino version of my code.
also the web-serial code i have for the webapp still works just fine. using echo, stty and cat also works as before. but py serial just does not want to read the serial input

robust walrus
#

glad you got it working!

faint nexus
#

thx

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
tannewt
[hathach/tinyusb] Issue opened: #1201 Broadcom USB address

Operating System

Linux

Board

Pi Zero 2W

Firmware

CircuitPython: https://github.com/tannewt/circuitpython/tree/rpi/

What happened ?

usb_init hangs

How to reproduce ?

Run CircuitPython on the Zero 2W (BCM2837). It's USB is at a different address than the BCM2711. I think it's that address for the BCM2836 as well. How do you want to manage the different locations? Should the client code set it instead of having TinyUSB do it?

diff --git a/src/portable/sy...
fallow birchBOT
faint nexus
#

its me again!

#

๐Ÿ˜„

#

i have found (some time ago) some unexpected behaviour with tinyusb.
when i write (from pc to pico) to cdc, i also have to have the read channel open (on pc) or else my serial data is ignored

#

this is not really good, because i cant send a big data set in one command with pyserial

faint nexus
#

@glacial stratus maybe you have some input for me again

glacial stratus
# faint nexus ๐Ÿ˜„

Yes, data will be discarded if no one is reading on the host side. Are you expecting it to buffer before you open the serial port on the host side?

faint nexus
#

no

#

im expecting it to still read data from the pc

#

while the pc is not reading

#

because the pico isnt even writing anything in this timeframe

glacial stratus
#

Could you explain the scenario in more detail? I don't think I understand.

faint nexus
#

i have the pc, with a library written in python (which uses pyserial)

i have a pico with c++ and tinyusb.
The pico has an ssd1306 oled attached.
Now i want to send data through serial with the library to the pico (which displays it on the oled).
its 1KB + some header bytes.

#

its perfectly working if i use
echo -e ".......data here........." > /dev/ttyACM0
and stty ....config here... /dev/ttyACM0 && cat /dev/ttyACM0 in another terminal

#

the echo and stty_cat method does not work if i dont open the /dev/ttyACM0 with cat.
then the pico ignores the data send by the pc

#

do you have a clearer picture now? i can give you more details if you want

glacial stratus
#

what is in your stty ... command?

faint nexus
#

stty -F /dev/ttyACM0 cs8 4000000 ignbrk -brkint -icrnl -imaxbel -opost -onlcr -isig -icanon -iexten -echo -echoe -echok -echoctl -echoke noflsh -ixon -crtscts && cat /dev/ttyACM0

#

pyserial script does also not work correctly while i have cat running, dunno if that has something to do with exclusive mode or so

faint nexus
glacial stratus
#

so if you just use pyserial, without any of the other stuff, then the pico does not receive anything?

faint nexus
#

it receives the first 2 bytes or so

#

then it does not behave correctly

glacial stratus
#

are you using Arduino or the SDK with raw tinyusb?

faint nexus
#

sdk with raw tiny

glacial stratus
#

does it work with pyserial if you use Arduino or CircuitPython?

#

could you point to your program?

faint nexus
#

sure thing, give me a sec

#

more specifically this line

#

this o_debug command just outputs to my oled. and in the not working case i get -286331154

glacial stratus
#

where is the odebug output going: back on the serial port, or to some uart

#

ah ok

faint nexus
#

with the cat/echo method i get 3

#

which is the start header for my serial api

glacial stratus
#

The loop in read_serial_binary() is going to try to combine_bytes(buf, available), even if it reads fewer bytes than the available amount. do you mean combine_bytes(buf, i)?

faint nexus
#

probably!

#

๐Ÿ‘€ let me change that real quick

glacial stratus
#

also if you send, say "123\r\n", it will eat the "123\r", and not process the \n, and then process that the next time around.

faint nexus
#

ok, first of all. THANK YOU

#

it works

fallow birchBOT
#
TheMindVirus
[hathach/tinyusb] New comment on issue #1186: TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

Here is the current status of uac2_headset on the latest pico-sdk with the latest tinyusb:

uac2_headset_current_status
I play a low frequency sine wave through it just so you can see the digital artifacts that seem to be occurring at random intervals.
It is almost as if extraneous data is being written to the same USB endpoint, or it needs to be buffered again to reduce jitter.

...

fallow birchBOT
#
nikisalli
[hathach/tinyusb] Issue opened: #1205 USB CDC device crashes when under heavy load

Operating System

Linux

Board

custom rp2040 board

Firmware

this will stop receiving or writing data after 20 seconds when being put under stress using cat /dev/urandom | pv > /dev/ttyACM1 or cat /dev/urandom | pv -L 14400 > /dev/ttyACM1 to limit the throughput

main.c

#include 
#include 
#include 

uint32_t get_time_ms(){
    return to_ms_since_boot(get_absolute_time());
}

int main (void) {
    tusb_init();

    char buf[200];

    while (1) {
      ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: bcm\-dwc2\-address
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-issue\-tempate
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1200: tud\_hid\_report\(\) can't send report after hot pluged

Please provide details on

  • How to Reproduce must have Exact steps in chronological order, details should be specific e.g if you use a command/script to test with, please post it as well.
  • Also which exact board of stm32f405

the code is preferably compiled like one in example folder and re-viewable for people to comment on. The easiest way is

  • Fork this repo, checkout a new branch
  • Add your-own-example based on stock one
  • Push and post it here.
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1205: USB CDC device crashes when under heavy load

thank you for the issue

  1. can this be reproduced with the stock example /examples/device/cdc_msc or cdc_dual_ports ? If not, then please add an example based on those with minimal changes so that the example is readily for compiling and testing. (it is how I normally test/develop the stack). Also that makes it easier to review/comment on your specific line of code. The easiest way is
    • Fork this repo, checkout a new branch
    • Add your-own-example based on stock one
    • Push and...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1186: TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

Thanks for opening the issue, UAC2 is tricky, and there is still lots of work to get it working flawlessly. To make the issue reproducible for me and others, can you

  • Provide the compile-ready example based on one of the audio example. adapt the example to create "audio_2i2o" can have lots of variants. While we want to make sure to test with the same firmware on the same hardware as much as possible. The code should be reviewable so that other can comment on specific line of code as well ...
fallow birchBOT
#
TheMindVirus
[hathach/tinyusb] New comment on issue #1186: TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

I have made the following fork of TinyUSB combined with Pico-SDK: https://github.com/TheMindVirus/tinyusb
It's actually Pico-SDK but the fork is TinyUSB for tracking it here. It is a snapshot, no Pull Request is to come from it.
It is also not an archival fork/branch but it should almost be treated as such. I have versions of Pico-SDK and TinyUSB
which are completely different but the version numbers says they're identical. (Cached vs. Non-Cached Version Hashing?)

GitHub was a nightmare...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-nrf\-easydma\-race
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1186: TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

I still don't get how to reproduce your issue

  1. Which example firmware I should compile, please provide link to your fork example
  2. Why do you need to fork the pico-sdk, did you make any changes to the sdk.
  3. Can you provide audio tool and steps to reproducing the capture

Note: all the info should be posted directly here.

Please let me know if there are updates to Audio/Video for RP2040 at a later stage.

just follow the development on this repo or checkout the release note.

fallow birchBOT
#
TheMindVirus
[hathach/tinyusb] New comment on issue #1186: TinyUSB Audio in Pico\-SDK is flawed: https://github\.com/raspberrypi/pico\-sdk/issues/653

The issue mainly seems to relate to Audio Formats in the USB Descriptor and what's expected by apps.
ASIO issues have occurred but the jitter has occurred with non-ASIO apps and ASIO has sometimes worked.
It may have something to do with the mic interleaving 1 channel from 2 but that's usually a normal case.
It may also have something to do with extra buffering when it does work, but will also temperamentally
throw device exclusivity and sharing errors (not very conducive to the audio wor...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
KarlK90
[hathach/tinyusb] New comment on issue #1022: GD32VF103 issue with MSC

Hi @hathach out of curiosity I ran the MSC demo again with the latest changes to master and...

[Sa Nov 27 12:25:14 2021]  sdc:
[Sa Nov 27 12:25:14 2021] sd 9:0:0:0: [sdc] Attached SCSI removable disk
[Sa Nov 27 12:26:27 2021] usb 3-4.3.4: USB disconnect, device number 20
[Sa Nov 27 12:26:28 2021] usb 3-4.3.4: new full-speed USB device number 21 using xhci_hcd
[Sa Nov 27 12:26:28 2021] usb 3-4.3.4: New USB device found, idVendor=cafe, idProduct=4003, bcdDevice= 1.00
[Sa Nov 27 12:...
fallow birchBOT
paper maple
#

I guess this is why the folks at the Raspberry Pi Foundation told me to raise the issue in Thachโ€™s repo:
#tinyusb message

So this is what youโ€™ve been doing all alongโ€ฆ

Also, later in the same comment Iโ€™ve attached a zip file of my audio test which partially worked:
https://github.com/hathach/tinyusb/files/7589177/PicoTinyUSBAudioTest.zip

The audio_2i2o source is similar to uac2_headset with an extra mic channel, ideally with stereo separation (phase inversion) or maybe reverb. It may one day make a useful โ€œ2i2oโ€ or โ€œusbioโ€ module for circuitpythonโ€ฆ

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1022: GD32VF103 issue with MSC

@KarlK90 great to hear that works, actually I did test it out with gd32 when doing new dwc2 driver. The msc drive does show up, so thing is definitely improved. However, there is still issue here and there. It may not work as well as other ports and I haven't got time to look further at this port. Let me know if you see any issue with gd32

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-gamepad\-comment
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-esp\-stack
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-doc
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1193 Implement usbh replug on pico

Thank you very much for the PR. I have been busy with other works, and only have time to review this now. It is a great fix. host stack apparently needs more dev time. Though I found the while() with find_first loop is not sufficient. We are better with just 1 for loop to close endpoint.

Therefore I have update the PR (also rebased since master has several updates).

fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1213: Add a HCD driver for MSP\-EXP432E401Y

I have updated this patch for handling a HUB. However, the enumeration process with a HUB still fails.
I guess some race condition occur on a control transfer. Current hcd_musb.c assumes that a new transaction will not be requested(calling hcd_setup_send/hcd_edpt_xfer) until the previous transaction has been completed in a control transfer. However, it does appear to be requested.

I'm not familiar with USB host processing and EHCI/OHCI. It seems that ehci.c and ohci.c has a some...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #1216: Update doc

Thanks, it takes me too much time to edit the table with retext app. Which app do you use to edit rst file ?

I have some restructuredtext extensions on vscode, i made the table in csv and one of the extensions formated it to rst, i honestly dont know which did what
To edit Is a bit harder, never had to deal with a big table like this so never really looked into it, usually just do it by hand (this one is too big to be dealing with that though)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1216: Update doc

There are other supported table formats, maybe CSV would be good here, very simple. I chose this because it allowed some fancier things like joined rows for the same manufacturer (which i think works great)

yeah, I agree, this format look great, though editing it is a bit of a pain. though I get used to it already.

In the table LPC43xx missed highspeed support :)

right, will correct it next

fallow birchBOT
fallow birchBOT
#
rppicomidi
[hathach/tinyusb] Pull request opened: #1219 Midihost

Describe the PR
This pull request adds MIDI host functionality to tinyusb.

Additional context
This code is a work in progress and should be treated as a draft. I am submitting it as a pull request in hopes it will be helpful.

Working now

  • Compiles and loads on a RP2040 board in the Visual Studio Code IDE
  • Both devices I have tried enumerate correctly (Yamaha Reface CS, Korg nanoKONTROL Studio)
  • The code will correctly format a MIDI message and send it to the device ...
fallow birchBOT
#
t123yh
[hathach/tinyusb] Pull request opened: #1220 Add support for Allwinner F1C100s family

Allwinner F1Cx00s family is a series of SoCs with Mentor MUSB controller and HS phy. It comes with a slightly different register space layout, and some quirks, so it's not multiplexed with the existing musb support library.

This porting currently requires to be compiled with https://github.com/hongxuyao/F1C100s_with_Keil_RTX4_emWin5 . Support for Keil RTX4 is also added in this pull request.

There is a working CDC loopback demo project at https://github.com/t123yh/F1C100s_RTX4_USB .

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

Superb !! Thank you very muhc, this is great PR. This would be great option to run TinyUSB on another popular SOC besides rpi broadcom. As required for maintaining the driver, could you please:

  • Tell which board you are testing with, I am planning to order and Sipeed Lichee Nano to test with your PR.
  • Add mcu and bsp files so that existing example could run on the actual hardware. This is actually very important, it not only provides proof of concept but also ease the maintaining/dev...
fallow birchBOT
#
t123yh
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

Hi hathach,

Thanks very much for your response!

I'm indeed testing with a Lichee Pi Nano, but it's more convenient to use a Widora V200 (Now called MangoPi-R3c). MangoPi-R3c have two USB ports for OTG and UART and comes with dedicated RESET and BOOT button, which brings a lot convenience to development.

Now a basic example is provided here: https://github.com/t123yh/F1C100s_RTX4_USB, which requires Keil to be compiled. I'll try to port it to the BSPs in TinyMCU later.

I forgot to ...

fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1221 nrf5x: Fix race condition during startup

Describe the PR
When NRF5x device is reset by software (after DFU for example),
power event is ready from the beginning.
When power interrupt is triggered before tud_init() finished
USBD_IRQn is enabled before it would be enabled in tud_init().
This in turn may result in BUS RESET event being sent from
USB interrupt to USB task when queue is not initialized yet.
This scenario often happens in Mynewt build where queue creation
takes more time.

To prevent this scenario USBD_IRQn ...

fallow birchBOT
#
scoudreau
[hathach/tinyusb] Pull request opened: #1222 Remove unused\-parameter errors when LOGGER=swo

Describe the PR
Remove errors when compiling with LOGGER=swo.
All arguments of sys_read() must be used in function, otherwise it triggers "unused-parameter" errors.

Additional context
Before this patch, error was:

hw/bsp/board.c: In function '_read':
hw/bsp/board.c:126:44: error: unused parameter 'buf' [-Werror=unused-parameter]
126 | TU_ATTR_USED int sys_read (int fhdl, char *buf, size_t count)
| ~~~~^
compilation terminat...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: test\_doc
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: chipidea\-controller
#
hathach
[hathach/tinyusb] New branch created: fix\-s3\-ci
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1223 temporarily skip s3 build on ci

Describe the PR
Temporarily skip S3 in ci build since it has strange issue

CMakeFiles/cdc_msc_freertos.elf.dir/project/src/device/usbd_control.c.obj: in function `usbd_control_reset':
usbd_control.c:(.text+0x1fe): dangerous relocation: call8: call target out of range: memset
CMakeFiles/cdc_msc_freertos.elf.dir/project/src/device/usbd_control.c.obj: in function `usbd_control_set_request':
usbd_control.c:(.text+0x231): dangerous relocation: call8: call target out of range: memcp...
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1224 rename transdimension to chipidea

Describe the PR
controller used by lpc18,43 and imxrt is more commonly known as chipidea (highspeed) in linux project. Rename transdimension to chipidea (still keeping the old file for compatible with warnings).

acquisition history: --> means bought.

ARC vusb fs/hs core --> Transdimension --> Chipidea CI13210 (fsotg), CI13410 (hsotg) --> MIPS --> Synopsys

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Kevincoooool
[hathach/tinyusb] Issue opened: #1230 Add a winusb example

**Is your feature request related to the problem? Please describe. **
A clear and concise description of the problem. predecessor. I always feel frustrated when [...]
Hello, I am currently using esp32s3 as a DAPLink debugger, it works normally when using HID, but I want to use WIFI as a wireless debugger, but when using HID with WIFI TCP, it is very slow because of the 1ms limit of HID , So I thought of the winusb daplink, I tried to modify the webusb_serial example, but win10 cannot recogn...

fallow birchBOT
#
vmilea
[hathach/tinyusb] Issue opened: #1231 Need accurate SOF event on RP2040 for explicit feedback

First of all, thanks for TinyUSB! It's an awesome little library.

I'm implementing a sound card using the RP2040. The device provides an asynchronous output endpoint and an explicit feedback endpoint to manage the data rate.

The feedback method is described in 5.12.4.2 of the USB 2.0 spec:

To generate the desired data rate Ff, the device must measure its actual sampling rate Fs, referenced to the USB notion of time, i.e., the USB (micro)frame frequency. [...] A sink can determin...

#
vmilea
[hathach/tinyusb] Issue opened: #1232 Endpoints are not being closed on RP2040

Operating System

Others

Board

Raspberry Pi Pico

Firmware

What happened ?

The dcd_edpt_close() implementation in dcd_rp2040.c is incomplete. It was probably meant to call hw_endpoint_close, but that code remains commented out.

With USB audio playback it's common for the endpoints to close and reopen as needed. During silence, the driver selects alternate setting 0 to conserve bandwidth and the endpoint is closed. Then it's reopened when playback starts.

Bec...

#
vmilea
[hathach/tinyusb] Issue opened: #1234 Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

The Windows driver for USB Audio 2.0 seems to disregard the spec and expects 16.16 format instead of 10.14 on my full-speed device. Interestingly, on Linux the ALSA driver supports either format. So for now I'm calling tud_audio_n_fb_set(feedback << 2) to force 16.16 format everywhere. This works but is a bit hacky.

Could we have a config flag to disable the format conversion in tud_audio_n_fb_set()?

#
HiFiPhile
[hathach/tinyusb] New comment on issue #1231: Need accurate SOF event on RP2040 for explicit feedback

I've implemented a 32bit/384kHz sound card on LPC4357 which runs perfectly without glitch at about 10% CPU usage.

In fact the way of feedback calculation in the spec is not optimal, as you said the jitter of 1-2 us was causing audio glitchs.

What I'm using and proved reliable is measure the sample count of the out buffer in every tud_audio_rx_done_pre_read_cb, and use this count to calculate feedback value.
Here is my snippet:

bool tud_audio_rx_done_pre_read_cb(uint8_t rhport, ...
fallow birchBOT
#
vmilea
[hathach/tinyusb] New comment on issue #1231: Need accurate SOF event on RP2040 for explicit feedback

Thanks! This looks viable provided you have the magic constants figured out (min, max, threshold). It's the sort of code I was hoping for in the device examples. :)

That said, the SOF way definitely works once you mitigate the jitter. It's running glitch-free with a small TinyUSB patch on the Raspberry Pi Pico.

To be clear, the project I'm working on is for my own entertainment - to learn and see how far I can push cheap hardware. I'm aiming for low audio latency, and the advantage of t...

fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #1220: Add support for Allwinner F1C100s family

Please let me know why this operation is needed. I would like to know if there is a bug in dcd_musb.c

I had designed dcd_msub.c that EPIDX register must be written when accessing the registers for FIFO settings(TXFIFOSZ, RXFIFOSZ, TXFIFOADD, and RXFIFOADD). My understanding is EPIDX effects only these registers. So, there is no need to keep the EPIDX value for a long time. If the EPIDX value needs to save and restore, I missed something condition.

fallow birchBOT
#
t123yh
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

Just played with the msc. It seems that there're a few STALLs before the disk is properly detected. Seems that the cause is the code below. I'm not familiar with msc, so I don't know what's happening.

if ( p_msc->stage == MSC_STAGE_STATUS )
  {
    // skip status if epin is currently stalled, will do it when received Clear Stall request
    if ( !usbd_edpt_stalled(rhport,  p_msc->ep_in) )
    {
      if ( (p_cbw->total_bytes > p_msc->xferred_len) && is_data_in(p_cbw->dir) )
     ...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

@HiFiPhile yeah it has been a while true! How are you all good?

@vmilea The driver can not know in advance if it is operated in full or high speed mode. Hence, the driver was designed such that the feedback value is always formatted in 16.16 format and in case of full speed mode, the driver takes care of reforamting the value to the specified 10.14 format. This way, the user does not need to care about the format with respect to the speed setting, just always set the value in 16.16 format....

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1230: Add a winusb example

No, we cannot have an example for every user scenario or class driver combination. I don't have enough time to maintain them all. Besides webusb example already did exactly binding winUSB driver. If you have issue problem to get it work, you could open an discussion providing all your setup/code and what is your issue/finding, maybe people that already done that could help.

fallow birchBOT
#
vmilea
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

@PanRe The API design is fine, it's just that the reformatting to 10.14 sometimes gets in the way. I'm proposing something like CFG_TUD_AUDIO_ENABLE_FEEDBACK_FORMAT_CORRECTION so it can be disabled if needed.

This is to work around a bug in the actual Windows driver. When passing 10.14 format on my full-speed device it refuses the value:

[USBAudio2]feedback value 0x000b0651 is out of range [0x002c0000,0x002d0000], ignoring value

The driver is expecting instead a 16.16 val...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

@vmilea Ah yeah now i see. Would you file a PR therefore? However, it is up to @hathach to decide if the PR is accepted. I would say it would be reasonable to do as you proposed. But i would prefer CFG_TUD_AUDIO_DISABLE_FEEDBACK_FORMAT_CORRECTION since this renders to enable a non-default setting in the driver. And please explicitly describe in the comments what it is good for (as you did above).
By the way, do you have a working minimal speaker example which can be used to test for this ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

BSP support is now added. No RTOS is required.

Please see README.md for details.

Currently tested with audio_test and hid_generic_inout and cdc_msc. audio_test is working. cdc_msc is not working, only echoing the first character.

Superb !! That is great, too bad, my tiny200 haven't shipped to me just yet for trying this out. This will make things super easy to support and maintain F1C in the...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

I've a guess but doesn't have a board to test with for the moment.

In XMOS's lib they use 3 bytes feedback for FS and 4 bytes for HS.

if (busSpeed == XUD_SPEED_HS)
  {
      XUD_SetReady_In(ep_aud_fb, fb_clocks, 4);
  }
  else
  {
      XUD_SetReady_In(ep_aud_fb, fb_clocks, 3);
  }

Maybe Windows use the byte length to decide coding format.

@vmilea Could you try to change 4 to 3 to see what happens ?
https://github.com/hathach/tinyusb/blob/f8288be03f28ad7b944e6925f494...

fallow birchBOT
#
vmilea
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

Would you file a PR therefore?

Done.

By the way, do you have a working minimal speaker example which can be used to test for this bug? If yes, it would be really nice if you could file a PR with such. I think other people would be glad for support!

I don't right now. It's not too difficult to create one with dummy output and fixed feedback value, but without real audio output the bug can only be checked through Windows driver logs.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

@t123yh in general, tool should be installed separately by user and added to PATH similarly to gcc toolchain or openocd. You could also make it as makefile variable to pass through command line e.g we can put it in the board/family readme doc.

# default to mksunxi is in PATH
MKSUNXI ?= mksunxi

if user need to, it can be passed to makefile as make MKSUNXI=path-to-tool. Let me know if that make sense to you.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1233 Handle the closing of endpoints on RP2040

Thank you for your PR, all changes look great, except for the one with hw_endpoint_xfer_continue(). I think we should return true instead to notify actual happened event previously, even though endpoint is closed now (it probably doesn't make any difference with ISO endpoint). Though I am open to all suggestion.

PS: On a side note, I actually have an plan to remove dcd_edpt_close() since it causes quite a bit of trouble with other dcd. It is better with just reserving the highest bandwid...

#
hathach
[hathach/tinyusb] New comment on issue #1231: Need accurate SOF event on RP2040 for explicit feedback

Here is my current implementation: vmilea@bf61702. The SOF interrupt is enabled only when dcd_sof_cb() is defined, so there is zero overhead unless used.

thanks, IMHO, sof interrupt must be actively enabled/disabled e.g when going into low power like wfi/wfe or when audio interface is not active. We don't want to have SOF triggered on every 1 ms in those scenario. This should be an tud_ API that applie...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1233: Handle the closing of endpoints on RP2040

If data is actually transferred via bus, it should be submitted to higher layer usbd/class driver. It would be their choice to whether process or ignore data. dcd shouldn't assume that.

My understanding is endpoints are closed in response to a control transfer on EP0, by which time all transfers on the endpoint being closed should have completed. So handling USB_INTS_BUFF_STATUS before USB_INTS_SETUP_REQ in the IRQ should prevent the transfer-after-close situation.

Yes, but since ...

fallow birchBOT
#
vmilea
[hathach/tinyusb] New review comment on pull request #1233: Handle the closing of endpoints on RP2040

It's a difficult topic. I've never seen a transfer event being delivered after the EP was closed. This change was a precaution based on the comment from usb.c. Do you agree to roll back to original panic()? If it comes up in practice, then it will be loud and clear and easier to deal with.

I propose also updating IRQ to handle buff_status before setup_req. This should take care of transfer completing immediately before EP close, even if there's still a chance for races like you said.

#
hathach
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

thank you @vmilea for the issue and @HiFiPhile and @PanRe for helpful input. PR #1235 look good, though I would like to get more info with your example and set up for reproducing purpose, specially with descriptor. Which could potentially cause windows driver confusion. Would you mind provide

  • your windows build version
  • Your minimal code that cause the issue (best to be on github for other to comment on line of code). It is best to modify one of stock audio examples if possible, otherw...
fallow birchBOT
#
atdicapf
[hathach/tinyusb] New comment on issue #1014: Port STM32 G4

I have an g474 eval with a similar clock setup.
Here are the rcc settings that should work:


  /** Initializes the RCC Oscillators according to the specified parameters
  * in the RCC_OscInitTypeDef structure.
  */
  RCC_OscInitStruct.OscillatorType = RCC_OSCILLATORTYPE_HSI48|RCC_OSCILLATORTYPE_HSE;
  RCC_OscInitStruct.HSEState = RCC_HSE_ON;
  RCC_OscInitStruct.HSI48State = RCC_HSI48_ON;
  RCC_OscInitStruct.PLL.PLLState = RCC_PLL_ON;
  RCC_OscInitStruct.PLL.PLLSource = RCC_PL...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1233: Handle the closing of endpoints on RP2040

It's a difficult topic. I've never seen a transfer event being delivered after the EP was closed. This change was a precaution based on the comment from usb.c. Do you agree to roll back to original panic()? If it comes up in practice, then it will be loud and clear and easier to deal with.

yeah sure, if you haven't run into this scenario. It is best to leave it as it is. I have an tendency to not write code for event that isn't happened yet (to avoid having code that isn't run).

I p...

#
hathach
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

I've written a Python version to avoid the need of installing mksunxi. Now it will build a flashable image that you can write to SPI. README.md is updated to reflect the changes.

great works, do you have a need to merge it asap ? my board from aliexpress could take 2 more weeks to arrive. I would like to have hand-on testing and could make some cosmetic changes if needed. But we could merge it earlier if this blocks your work.

#
hathach
[hathach/tinyusb] New branch created: g4\-nucleo
fallow birchBOT
#
t123yh
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

great works, do you have a need to merge it asap ?

No need, it's better to merge after you have tested the whole thing. I don't think it's currently stable enough to be merged. I can just work on my own repo before merging.

BTW, after fixing a bug (commit 527036b) that causes MMU and cache not initialized when executing from FEL, serial performance test reaches 15.7MB/s, which is a lot better than previous tests.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

No need, it's better to merge after you have tested the whole thing. I don't think it's currently stable enough to be merged. I can just work on my own repo before merging.

great, I prefer to have some local testing as well.

BTW, after fixing a bug (commit 527036b) that causes MMU and cache not initialized when executing from FEL, serial performance test reaches 15.7MB/s, which is a lot better than...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ftdigdm
[hathach/tinyusb] Pull request opened: #1238 Port ft90x

Describe the PR
Add support for the Bridgetek FT90x and FT93x devices.

The FT90x and FT93x series are complete System-On-Chip 32-bit RISC microcontrollers for embedded applications featuring a high level of integration and low power consumption.

Additional context
Documentation is available at https://brtchip.com/ft90x/ and https://brtchip.com/ft93x/
The port requires to be compiled by the GNU ft32-elf- Toolchain which downloaded from http://brtchip.com/ft9xx-toolchain/

C...

fallow birchBOT
#
philippgurtner
[hathach/tinyusb] New comment on issue #1014: Port STM32 G4

Hi all
@atdicapf Thanks a lot :)
Your version works for me to.

@hathach on cd76193 you forget to take something:

  • board.h l 91: RCC_USBCLKSOURCE_HSI48 not RCC_USBCLKSOURCE_PLL

family.c: __HAL_RCC_USB_CLK_ENABLE(); is the important

Thanks all you for the great solutions :)

Something i wondering about: with HSE it works but same settings with HSI not...Idk why, both generated with cubemx...

fallow birchBOT
fallow birchBOT
#
vmilea
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

Your minimal code that cause the issue

Here is the test code. It's based on uac2_headset, tested on RP2040 and should work on other MCUs. The audio sink runs at 44100Hz, it discards incoming samples and sends a slightly skewed feedback rate of 44.125.

Follow these instructions to capture driver logs: https://matthewvaneerde.wordpress.com/2017/10/23/how-to-gather-and-read-logs-for-microsofts-usb-audi...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1014: Port STM32 G4

@philippgurtner I am glad it works for you, I have updated the BSP though It stills does not work for me. https://github.com/hathach/tinyusb/commit/51acc3e1b90f42ebb80881a143fe36a4ce45821c . Would you mind telling Which board you are using. It could be hardware setup on my side since g4 nucleo don't have usb and I have to use break out cable https://www.adafruit.com/product/4448 Green is D+, white is D-

![image](https://user-images.githubusercontent.com/249515/145340982-63408e86-820b-467d...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
philippgurtner
[hathach/tinyusb] New comment on issue #1014: Port STM32 G4

Hi
I Think you mixed up D+ & D-
PA12 (CN10 p 12) is D+ (green)
PA11 (CN10 p 14) is D- (white)
Schematic

I found my "flag" :D
In board_init() we need to call HAL_InitTick(TICK_INT_PRIORITY); or at least set uwTickPrio = TICK_INT_PRIORITY;
Inside HAL_RCC_OscConfig(&RCC_OscInitStruct); in board_clock_init(): HAL_InitTick(uwTickPrio); get called and it needs uwTickPrio, otherwise systick is not...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rppicomidi
[hathach/tinyusb] New comment on pull request #1219: Midihost

I pushed changes that show the Raspberry Pi Pico as MIDI host supporting both IN and OUT endpoints at the same time. It's showing proof of life, but after a short while the system gets in a state where it will neither send nor receive until I unplug and re-plug the MIDI device. I am investigating.

fallow birchBOT
#
t123yh
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

@kkitayam Hi,

I am playing with gud on F1C100s today. I doubt if there's a bug in the logic of musb dcd driver around TU_LOG1("Drop CONTROL_STAGE_ACK\n");.

Consider the following situation:

  1. Host sent a CONTROL SETUP IN (req1) with wLength > 0;
  2. Device responds with wLength = 0 DATA OUT in respond to req1;
  3. Host responds with STATUS OUT (musb handles this automatically);
  4. Another CONTROL SETUP IN (req2) is sent immediately by host, s...
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

@t123yh
Thank you for your comments!

I am playing with gud on F1C100s today. I doubt if there's a bug in the logic of musb dcd driver around TU_LOG1("Drop CONTROL_STAGE_ACK\n");.

Consider the following situation:

I will get back to you on that after I will understand the sequence shown by you.

I feel CONTROL IN transfer is very complex because MUSB has no feature to respond with NAK for STATUS OUT requested by HOST. It takes time to understand.

fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #1220: Add support for Allwinner F1C100s family

Make some adjustments to process_ep0 so that if _dcd.status_out is 1 when entering process_ep0 -> USB_CSRL0_RXRDY, send a dcd_event_xfer_complete immediately to notify the stack;

I guess this way is good. I would consider whether the way works for other conditions.

If this adjustments are applied, after the step 24 of C) The next SETUP request comes before TUD calls dcd_xfer() for current STATUS OUT , DCD will enqueue DCD_EVENT_XFER_COMPLETE to event queue. Therefore DCD g...

fallow birchBOT
vital oracle
#

Did anyone tried TinyUSB with NeoPixel on ESP32S2?

#

I'm getting some artifact for some reason

#

All I can tell is that this happens while USB is communlicating

#

I checked the RMT signal generated with logic analyzer, some packet is corrupted and the signal has some extra data at the end

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
geekbozu
[hathach/tinyusb] New comment on issue #1234: Allow passing feedback value unchanged through tud\_audio\_n\_fb\_set

I feel like we have been working on a similar project...I fought with this a week or 2 ago.
I use an stm32f411 core.

The issue is windows actually ignores the speed of the device and checks the bcdUSB field.
When the bcdUsb field says we are a USB2.X the UAC2 driver assumes we are a high speed device and uses a 16.16 format.
When setting bcdUSB to 1.X, it uses the 10.14 format expected on a Full Speed device.

My solution was to just make a separate function that took in boolean to s...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
bm16ton
[hathach/tinyusb] Pull request opened: #1245 initial portenta h7 support

Initial support for Portenta H7.

Very easy and simple additions to get the Portenta H7 up and running. I put it into its own folder, not sure if thats correct but between the two cores of diff archs and the weirdness the dual cores seem to bring compared to single core brothers thought it made sense. The i2c pmic gets written to very early init by arduino/mbed I added ruff initial and untested code for that in family.c, but its not tested/trustworth atm. Everything seems ok, the examples ...

fallow birchBOT
fallow birchBOT