#tinyusb

1 messages · Page 19 of 1

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enhance\-tusb\-config
fallow birchBOT
#
tore-espressif
[hathach/tinyusb] Pull request opened: #1487 cdc: Fix autoflush for FIFO < MPS

Describe the PR
If CDC TX buffer size is configured to be less than bulk packet size, the autoflushing condition is never reached.

Changes:

  1. TX buff is automatically flushed when TX FIFO is full
  2. Zero-length-package is sent if the whole transfer length is integer multiple of MaxPacketSize defined in EP descriptor (rather than fixed 64/512 bytes)

Additional context
Found out during https://github.com/espressif/esp-idf/issues/9040

fallow birchBOT
#
pm-mic
[hathach/tinyusb] Issue opened: #1488 RP2040 host msc example non\-functional \(with fatfs\)

Operating System

Windows 10

Board

raspberry pi pico

Firmware

examples/host/cdc_msc_hid

What happened ?

When trying the msc host example with the fatfs implementation based on the example code, one first runs into the following code at line 97 and 107:
if ( TUSB_ERROR_NONE != tuh_msc_read10(usb_addr, 0, buff, sector, count) ) return RES_ERROR;
Which needs to be correct to:
if ( tuh_msc_read10(usb_addr, 0, buff, sector, count, NULL) ) return RES_ERROR;
in order...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1489 nrf5x: Fix DMA access

Describe the PR
There were two problems:

  • dma_running flag could be checked in USB interrupt (not set yet) then higher priority
    interrupt could start transfer, check dma_running (not set yet) set it to true start
    DMA; then when USB interrupt continues it starts another DMA that is not allowed
  • when DMA is started some registers can't be safely accessed, read can yield invalid
    values (SIZE.EPOUT, SIZE.EPISO)
    current implementation could start DMA for one OUT endpoint then ...
fallow birchBOT
#
Ryzee119
[hathach/tinyusb] Pull request opened: #1491 OHCI usbh, tweaks and improvements

Describe the PR
A number of tweaks and improves to the OHCI usb host backend

Additional context

  • Allows configurable root hub ports. I am testing with hardware that has 4 ports. This is working successfully. Fixes for port reset, port speed, port connection status to direct them to the correct rhport.
  • Currently we assume cold boot (OHCI is reset state). This may not be the case if we come from a bootloader etc. This handles SMM mode (Ref OHCI spec 5.1.1.3.3) and Bios mode (Re...
fallow birchBOT
fallow birchBOT
#
blukk
[hathach/tinyusb] Issue opened: #1493 Keypress not being registered

Operating System

Others

Board

ESP32-S2

Firmware

Keyboard TinyUSB sample

What happened ?

On some devices, a keyboard press is not being registered, for example, an XBOX. While scanning an input is not detected.
It looks the debouncing time is too short in this case. Where to change the debouncing timing, in which library. I am using the keyboard example.

How to reproduce ?

Scan a button on an Xbox game. The press will not be detected. Normal keyboard inputs work ...

fallow birchBOT
#
tfx2001
[hathach/tinyusb] Issue opened: #1494 STM32L475 will not send ACK packets after data stage finished

Operating System

Windows 10

Board

STM32L475VET6

Firmware

custom firmware, basically CDC.

What happened ?

During device enumeration, after data stage of SET_LINE_CODING, it won't send ACK packet. After checking the log, I think the XFRC bit should not be cleared when OTEPSPR is set but STPKTRX is cleared.

By changing
https://github.com/hathach/tinyusb/blob/fa895ed3dc46d5aa5e11b19ff07beb6fcfc62655/src/portable/synopsys/dwc2/dcd_dwc2.c#L1038

to `if (doepint...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1495 Better support multiple controllers configuration

Describe the PR

  • Enhance configuration for multiple controllers e.g port0 for device, port1 for host and/or allow dynamic switching device/host role (not fully implemented yet). Previously CFG_TUSB_RHPORTx_MODE is used to fix device/host support.
  • CFG_TUD_ENABLED/CFG_TUH_ENABLED and CFG_TUD_MAX_SPEED/CFG_TUH_MAX_SPEED can now be used instead of CFG_TUSB_RHPORTx_MODE
  • tud_init(rhport), tuh_init(rhport) is used explicitly instead of tusb_init()
  • backward compatible, everything that ...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-sof\-fastfunc
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Hi guys, I Also stumbled over missing isoc support on fsdev.
For my current "fist test" I would be fine if there's no dma-support for now, could we split this issue or is it mandatory to support dma in order to get isoc transfers running?
I'm willing to help with implementation and test but maybe I'd need someone to discuss my changes as I'm not that deep into fsdev driver and tinyusb stack up to now.
I'll first try to comment in that untested stuff and to adopt the changed routines.
I...

fallow birchBOT
#
leptun
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

@HiFiPhile I think that is correct. The stm32f103rc for example doesn't have any way to connect the DMA to the USB. It also doesn't have an internal dma controller.
I also checked the stm32g474re and it's the same in this sense. That one has a much more sophisticated DMA controller, but even that one can't connect to the USB (although I noticed in one of the diagrams there is some extra FIFO, but I didn't read more into that).

As far as I know, there is no stm32 that actually can talk to ...

fallow birchBOT
#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

@HiFiPhile @leptun : Mhh. You may be right, but it could also be that m2m dma is still possible as the pma memory can be accessed from within the normal adressing-space. So for my understanding there only needs to be a dma-connection if requests of an periperal need to be made which would not be the case for pma.
Nevertheless there should also be a way to implement isocronous support without dma.
I'll first try to also add the ff-api support to the driver as already proposed by the "comme...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1494: STM32L475 will not send ACK packets after data stage finished

this is mostly tested with my L476 discovery board. These line of codes are done when doing generic dwc2 driver #1163 with tons of testing (trial/error). Maybe I didn't fully resolve this issue with L4 series just yet (possibly an race condition that is less likely to happen on my L476 discovery board due to clock/hw set up etc..). I don't have official dwc2 specs and the stm manual are not very helpful on this particular issue.

I kind of forget the detail, #126 may contain some useful in...

fallow birchBOT
#
Ryzee119
[hathach/tinyusb] Issue opened: #1497 Device Address or EP index greater than 15 will cause OHCI driver to crash

Operating System

Windows 11

Board

OHCI

Firmware

This index is only 4 bits and stores the device address or an index of an endpoint in ed_pool. As soon as the value in index is >15 it will overflow and cause OHCI hardware to crash.

I can see we've had to squeeze it in the reserved area to fit within a gtd, so not sure on a good fix for it. Ive confirmed this is the issue by temporarily increasing the index field size, by reducing the expected_bytes field.

https:/...

fallow birchBOT
fallow birchBOT
#
mauriciocirelli
[hathach/tinyusb] New comment on issue #1476: No DCD\_EVENT\_UNPLUGGED event for STM32 FSdev

It seems that STM32H7B3 is using synopsys dwc2 driver, not stm32_fsdev driver.

Dear, thank you for pointing this out.
I have confirmed that I am using the synopsys dwc2 driver.

However, debugging dcd_int_handler function I have confirmed that the following code is not being executed when I unplug the device from the computer:

dcd_event_bus_signal(rhport, DCD_EVENT_UNPLUGGED, true);

I have enabled VBUS sensing in CubeMX and it is directly connected from the USB connector to ...

fallow birchBOT
fallow birchBOT
#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Sure:
#define AUDIO_CTRL_ID_SPK_INPUT_STREAM 0x01
#define AUDIO_CTRL_ID_SPK_FUNIT 0x02
#define AUDIO_CTRL_ID_SPK_OUTPUT 0x03
#define AUDIO_CTRL_ID_MIC_INPUT 0x04
#define AUDIO_CTRL_ID_MIC_FUNIT 0x05
#define AUDIO_CTRL_ID_MIC_OUTPUT_STREAM 0x06
#define AUDIO_CTRL_ID_CLOCK 0x41
#define AUDIO_CTRL_ID_CLOCKSEL 0x40

#define AUDIO_NUM_INTERFACES 0x03
#define AUDIO_NUM_INCHANNELS 0x02
#define AUDIO_NUM_OUTCHANNELS 0x02

#define TUD_AUDIO_CTRL_TOTAL...

#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Same descriptor is working properly with stm32l4 + dwc2
I'm wondering if the "doublebuffering" is needed in order to support isoc-audio as it seems that maybe every 2nd pice of data is not handled.
I'm also wondering if it's supported by the fsdev that there are 2 isoc-descriptors with 64 byte in each urb. Maybe one of them is not handled properly.

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

I'm wondering if the "doublebuffering" is needed in order to support isoc-audio as it seems that maybe every 2nd pice of data is not handled.

I don't think it's the cause. As there is no ack or retry for ISO transfer, host will continue to send even device can't handle it properly.
I remember Windows continued to send even if I paused the execution of LPC4337.
In your case host is sending only half of the data.

Seems like feature unit is missing in descriptors.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-tuh\_config\-port\-specific\-setup
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Hi @Iktek , I believe DMA is not supported on fsdev after reading reference manual and ST driver, I could be wrong.

The peripheral cannot make DMA requests, but the operating system/tinyusb can periodically initiate "MEM2MEM" transfers as needed (preferably using the double-buffer mode of the USB peripheral). Handling DMA complete interrupts manually shouldn't be so hard to do. Error handling (i.e., when USB disconnects happen) could be complicated if a DMA transfer is in progress in the...

#
pigrew
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Same descriptor is working properly with stm32l4 + dwc2 I'm wondering if the "doublebuffering" is needed in order to support isoc-audio as it seems that maybe every 2nd pice of data is not handled.

I think stm32_fsdev must use double-buffering, based on the reference manual section 23.4.4 isochronous transfers:

Isochronous endpoints implement double-buffering to ease application software development, using both ‘transmission’ and ‘reception’ packet memory areas to manage buffer ...

fallow birchBOT
#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

The peripheral cannot make DMA requests, but the operating system/tinyusb can periodically initiate "MEM2MEM" transfers as needed
I agree.

I think a busy-loop will not be a solution which would speed up much as irq is still blocked during memcpy.
I don't expect the dma-transfer being much faster then the manual memcpy. I'ts only worth being used if we could make it asyncronous.

I'll have a look these days if double-buffering is doable easy.
I think dma is not mandatory for now b...

fallow birchBOT
#
Iktek
[hathach/tinyusb] New comment on issue #1249: stm32\_fsdev isochronous support

Ok, i digged in a bit and things seem even more complicated as thought before:
Double-buffered isoc-endpoints can't be bedirectional. So one would have to use 2 endpoint indices here.
As the driver states endpoint id and ix are mixed up all-over-the-world, so it would be hard to get them devided again.
Unfortunately UAC2 needs the sync endpoint being on the same address ( 0x01 <->0x81 ) as the corresponding data-endpoint.. so we have a no-go here.

In addition my customer phone me he w...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-rp2040\-ramfunc
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1497: Device Address or EP index greater than 15 will cause OHCI driver to crash

you are right, I have written this long ago for NXP LPC MCU, and never thought it would need to support more than 16 devices. I actually prefer the solution 2, even though we need a few extra code to access the custom data array (probably 2 bytes per TD), but in general it save lots more SRAM. It may not be a lot but less is better since TinyUSB is expected to run on small MCU as well.

I propose a couple solutions:

  • Expand the td struct to include this custom data. To maintain 16...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ClarkyKent
[hathach/tinyusb] Issue opened: #1503 synopsys dcd\_dwc2 VBUS handling

Currently I am using STM32h743x MCU which is powered by battery and i am using TinyUSB with FreeRTOS OS for CDC. If there is no USB when board is powered up, it tries to connect by calling dcd_connect() . By doing this MCU enters in reset and loops between USB connect and reset.

Proposed solution
It should be handled like it is done in one of the PR #1094 . At least if VBUS sensing is enabled.

We should be able to get an interrupt on SRQINT in OTG_GINTSTS.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: revert\-sof\-rename
fallow birchBOT
#
Ryzee119
[hathach/tinyusb] New comment on pull request #1491: OHCI usbh, tweaks and improvements

No rush at all

I will follow up with proper periodic schedule handling. I may put this in a #ifdef guard so it can be disabled by the users as it uses a bit of RAM, however this will allows transfers to respect bIntervals and spreads transfers across frames to maximise bandwidth.

And I have isochronous support locally, however we need a host isochronous sample to demonstrate :)

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-dynamic\-rhport
fallow birchBOT
fallow birchBOT
#
TravisRo
[hathach/tinyusb] Pull request opened: #1507 Add CH341 emulation class driver

Describe the PR
Adds CH341 USB to serial emulation class.

Additional context
The CDC driver (for windows at-least) is problematic which is probably why all of the USB to serial IC manufacturers use their own proprietary driver. In my case, I was trying to implement an ESP32 programmer with a CDC interface only to discover that the windows CDC driver (usbser.sys) doesn't handle the RTS signal properly so there was no way to get it to work without modifying the esp scripts.

This...

fallow birchBOT
rapid agate
#

Is this normal?

unknown.png
odd swan
rapid agate
#

I did its still blank lol

odd swan
#

Weird lol

rapid agate
odd swan
#

Communication device class

rapid agate
#

Ooohh

#

I've been hitting my head against the wall for the past months on this project:
Emulating a proprietary arcade machine controller. I have all the lsusb -vv output here:
I'm currently at a point where the endpoint is 'in use' (everything except . I'm using the webusb_serial example as a template)
(the red is what i want to match, the green is what the avr shows)

unknown.png
#

I'm so close, I just need to get a better understanding of endpoints and how they're made, and used.

#

I'm not sure if the CDC type is the way I should be going with this... idk what I'm doing

#

How do I just expose a buffer and not connect to it in tinyusb?

#

Sorry I should clarify, I just want to make these endpoints:

unknown.png
odd swan
#

I see, I’m not super familiar with TinyUSB but you might find help faster by asking in #help-with-projects this channel usually isn’t very trafficked

#

It’s mostly for core development for TinyUSB

rapid agate
#

Ah ok, good point

odd swan
#

You might also post an issue on their GitHub with what you have so far and how you’re stuck

rapid agate
#

Oo right theres a discussions tab! Thanks

odd swan
#

You’re welcome 🙂

fallow birchBOT
#
liamfraser
[hathach/tinyusb] Pull request opened: #1509 RP2040 HCD Improvements \(Hub \+ Keyboard \+ Mouse working\)

Improvements to RP2040 HCD driver. The main issue this PR fixes is that interrupt endpoints were sometimes sending packets to the tinyusb host stack that the stack had not requested. This would result in hangs / crashes / corrupted data structures.

We now disable interrupt endpoint polling unless the host stack has requested a packet. The other improvements were things noticed while debugging this issue. In particular you should check for a stall received before dealing with any other pen...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #1511 un\-roll recursive call when unplug an hub device

Is your feature request related to a problem? Please describe.
PR #1480 add support for multiple-level hub using recursive call of process_device_unplugged()

However in limited MCU, recursive call chain can cause stack overflow. We should find an way to un-roll the recursive chain. After all, the device loop is rather small (4-10) only.

Describe the solution you'd like
It is always possible to un-roll an recursive chain to a loop with/without an queue. We could use a status (d...

fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] Pull request opened: #1513 add tud\_queue\_send\_cb

In the Pico SDK for stdio over USB, (by default) we call TinyUSB in a low priority IRQ (so the user does not have to have a polling loop).

Currently this IRQ is called every 1ms which is pretty wasteful. This change adds a callback which can be hooked to know when there is something in the queue that needs processing.

Note, i don't know if:

  1. i called this the right thing
  2. whether it should be defined somewhere else (if other ports might find it useful)
  3. it performs the callba...
#
liamfraser
[hathach/tinyusb] New review comment on pull request #1509: RP2040 HCD Improvements \(Hub \+ Keyboard \+ Mouse working\)

Good point. I implemented this a while ago and rebased it, so maybe it is no longer necessary. In a comment here https://github.com/liamfraser/tinyusb/commit/a38b54d1f2d2b3e756eea475f7114f888ad960fc#commitcomment-68710466 you mention there was an issue with queueing multiple transfers that is now fixed. I remember seeing a race condition at the time so that could have fixed it.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1513 add tud\_queue\_send\_cb

I don't think this is the right way to address the issue with pico stdio. There is other place that use queue API as well. I think the better approach would be having USB IRQ as shared IRQ (currently exclusive) and pico-sdk installed its own irq to detect if there is a new usb event and call tud_task() later in main thread

https://github.com/hathach/tinyusb/blob/80121303eb80a1847ad314cb87774e6e390754c6/src/portable/raspberrypi/rp2040/dcd_rp2040.c#L366

I have done something similar to th...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-example\-with\-highspeed
#
hathach
[hathach/tinyusb] Pull request opened: #1516 correct bulk size for highspeed endpoint in dynamic\_configuration and usbtmc exmaples

Describe the PR
fix #1457, close #1459
bulk endpoint size must be 512 for highspeed and 64 for FS, dynamic_configuration and usbtmc examples hard coded to 64 and cause an assert in the stack

[ 4949.159993] usb 3-1: USB disconnect, device number 51
[ 4949.484276] usb 3-1: new high-speed USB device number 52 using xhci_hcd
[ 4949.633227] usb 3-1: config 1 interface 0 altsetting 0 bulk endpoint 0x1 has invalid maxpacket 64
[ 4949.633230] usb 3-1: config 1 interface 0 altsetting ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1457: some examples don't work for imxrt: cdc\_msc\_freertos, dynamic\_configuration, hid\_composite\_freertos, usbtmc

Thanks for filing the issue, I put up a test today. The issue is not caused by mis-configured JTAG but rather the example incorrect bulk size of usb descriptor. For Highspeed the bulk endpoint size must be 512, dyanmic_configuration and usbtmc are hard-coded it into 64 (FS). kernel message does show this issue,

[ 4949.159993] usb 3-1: USB disconnect, device number 51
[ 4949.484276] usb 3-1: new high-speed USB device number 52 using xhci_hcd
[ 4949.633227] usb 3-1: config 1 interface...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ccrome
[hathach/tinyusb] New comment on issue #1457: some examples don't work for imxrt: cdc\_msc\_freertos, dynamic\_configuration, hid\_composite\_freertos, usbtmc

Thanks for filing the issue, I put up a test today. The issue is not caused by mis-configured JTAG but rather the example incorrect bulk size of usb descriptor. For Highspeed the bulk endpoint size must be 512, dyanmic_configuration and usbtmc are hard-coded it into 64 (FS). kernel message does show this issue,

Ah ha! Thanks for the fix.

fallow birchBOT
fallow birchBOT
#
tmplt
[hathach/tinyusb] Issue opened: #1520 SAMx7x CDC\-MSC example does not link with LOG=2

Operating System

Linux

Board

SAM V71 Xplained Pro

Firmware

examples/device/cdc_msc @ e0d7c16788f15c72c5a7837656d8b6d3ed28c3e0

What happened ?

Upon building with

$ cd examples/device/cdc_msc
$ make BOARD=same70_xplained LOG=2 all

linking fails with

LINK _build/same70_xplained/cdc_msc.elf
/nix/store/l3rvj8w9ci8wj34kmsvga1ijikmngz0y-gcc-arm-embedded-10.3.1/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: /nix/store/l3rvj8w9ci...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #1516: correct bulk size for highspeed endpoint in dynamic\_configuration and usbtmc exmaples

@hathach, perhaps you can explain this to me?

Will this cause any issues when a high-speed device is talking to a full-speed host (or using a full-speed hub)?

Since it would be a full-speed connection, the packets shouldn't be more than 64 bytes, but the descriptor will statically report a maxPacketLen of 512?

(I'm not so familiar with high-speed USB...)

#
perlindgren
[hathach/tinyusb] New comment on issue #1520: SAMx7x CDC\-MSC example does not link with LOG=2

I tested under arch (manjaro).

After a bit of tool-chain fiddling I was able to reproduce the error:

LINK _build/same70_xplained/cdc_msc.elf
/usr/lib/gcc/arm-none-eabi/12.1.0/../../../../arm-none-eabi/bin/ld: /usr/lib/gcc/arm-none-eabi/12.1.0/../../../../arm-none-eabi/lib/thumb/v7e-m+fp/hard/libnosys.a(sbrk.o): in function `_sbrk':
sbrk.c:(.text._sbrk+0x18): undefined reference to `end'
collect2: error: ld returned 1 exit status
make: *** [../../rules.mk:100: _build/same70_xplain...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1516: correct bulk size for highspeed endpoint in dynamic\_configuration and usbtmc exmaples

For complete compatible with FS hub/host, highspeed-capable device must prepare 2 configuration descriptors: fs and hs and return correct one according to the actual link speed. When HS-capable device working in FS link, it may need to answer to the get_other_speed_configuration() from host. I did implement all of this for cdc_msc example sometime ago

https://github.com/hathach/tinyusb/blob/ae8b8f0c93885e3078f12c9ef00d65faa835d507/examples/device/cdc_msc/src/usb_descriptors.c#L143-L233
...

fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #1516: correct bulk size for highspeed endpoint in dynamic\_configuration and usbtmc exmaples

PS: I will update the usbtmc example later to also support this scenario :)

Thanks! I didn't want to create more work for you (but on the other hand, I don't have any HS devices to test...)

I unfortunately used USBTMCD_MAX_PACKET_SIZE a bunch of times in the driver, too. These have to be changed to be based on the value in the endpoint descriptor table....

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] New comment on pull request #1521: Re\-add some warning suppression for rp2040

Yeah; they can certainly be fixed... this file shows what we do a test SDK compile with (which seems to about match the sensible limit of warning options that our users use)

https://github.com/raspberrypi/pico-sdk/blob/426e46126b5a1efaea4544cdb71ab81b61983034/test/kitchen_sink/CMakeLists.txt#L52

You can reproduce by

  • cloning the SDK and cd pico-sdk
  • doing a git submodule update
  • mkdir build
  • cd build
  • cmake -DPICO_SDK_TESTS_ENABLED ..
  • make or make -j<procs>
    ...
fallow birchBOT
fallow birchBOT
#
arilink
[hathach/tinyusb] Issue opened: #1525 USB HS Device Qualifier Descriptor Callback

Operating System

Windows 10

Board

STM32F407 USB HS+USB3300PHY

Firmware

V1.3.0

What happened ?

Does tingusb support STM32 f4+usb3300 high-speed devices? If yes, is there a device qualifier descriptor callback?

How to reproduce ?

I have a new project that needs to use USB high-speed transmission, but it is found that high-speed devices need device qualification descriptors, but tinyusb does not find the corresponding callback function. How can I solve it?

Debug...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
LouisCARRIOU
[hathach/tinyusb] Issue opened: #1527 ESP32 audio microphone

Operating System

Windows 10

Board

ESP32-S3

Firmware

examples/device/audio_4_channel_mic

I also tried with the freertos like https://github.com/kaspernyhus/tinyusb/tree/audio_test_freertos/examples/device/audio_test_freertos

What happened ?

usb device is well recognise, so I tried it and fill the i2s_dummy_buffer with rand() to make a white noise, but

NO SOUND IS RECORDED onto the computer

I also tried with the tud_audio_write_support_ff , and the tud_audio_wri...

fallow birchBOT
fallow birchBOT
#
ClarkyKent
[hathach/tinyusb] Issue opened: #1528 synopsys dcd\_dwc2 device mode bug

Operating System

Linux

Board

STM32H743x

Firmware

I am using custom FW where FreeRTOS is used and have 2 CDC in device mode. Vbus sensing is enabled.

What happened ?

If I power on the board with USB already connected. Everything is fine. 2 USB com ports get detected on host machine(Linux/Windows) and everything woks fine as intended.
But if I power on our board without USB(as board has a battery as main source of power) and I do not attach USB, STM32H743 resets itself...

#
ClarkyKent
[hathach/tinyusb] New comment on issue #1528: synopsys dcd\_dwc2 device mode bug

I have kind of found the solution to this. so replying here.

Once I have removed this following line in function dcd_init() everything workas as inteneded.
// Clear A override, force B Valid
//dwc2->gotgctl = (dwc2->gotgctl & ~GOTGCTL_AVALOEN) | GOTGCTL_BVALOEN | GOTGCTL_BVALOVAL;

Even-though MCU is powered on and stack BLE is initialized, it does not resets itself anymore. and if i connect an USB , it starts to enumerate and it shows USB device on HOST machine.

I do not kn...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] Issue opened: #1529 USBTMC triggers assertion soon after configuration, due to extra CLEAR\_FEATURE\(ENDPT\_HALT\)

Operating System

Windows 10

Board

stm32f070rb

Firmware

master branch (ae8b8f0c93885e3078f12c9ef00d65faa835d507)
Driver is NI VISA for windows v21.5

What happened ?

Summary: Soon after device configuration, the host sends a CLEAR_FEATURE(ENDPOINT_HALT) on the USBTMC bulk-out endpoint, triggering an assertion that a transfer is being started on a busy endpoint (usbd_edpt_xfer:1243).

At configuration, the class driver initiates a bulk-in transfer, so the endpoint ...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1529: USBTMC triggers assertion soon after configuration, due to extra CLEAR\_FEATURE\(ENDPT\_HALT\)

Ok, USB 2.0 spec confirms that it's OK to send extra ClearFeature(ENDPOINT_HALT), and in that case, the data toggle should be reset, so that's what I'll do (implement by stalling and then unstalling endpoint):

USB 2.0 spec 9.4.5:

Forendpoints using data toggle, regardless of whether an endpoint has the Halt feature set, a
ClearFeature(ENDPOINT_HALT) request always results in the data toggle being reinitialized to DATA0.

It also states that the DTOG's should be reset if set_configura...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1529: USBTMC triggers assertion soon after configuration, due to extra CLEAR\_FEATURE\(ENDPT\_HALT\)

@hathach This is starting to look more like a device stack issue. Would you mind looking into the stack, and then I can fix the USBTMC code in particular?

When clear_feature(endpoint_halt) is requested on an endpoint, usbd_edpt_clear_stall is then called:

https://github.com/hathach/tinyusb/blob/4639cac85cf959c3bfed091c02dce1345f067c7a/src/device/usbd.c#L822-L825

But, endpt_clear_stall does nothing when the endpoint is not stalled:

https://github.com/hathach/tinyusb/blob/4639...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] Pull request opened: #1531 USBTMC: Fixes and support for high\-speed USB

This updates USBTMC so that it should work with USB high-speed (untested, I don't have a HS device handy...).

It also fixes a few existing bugs:

  1. Updates python test code to use newer versions of pyvisa
  2. Manually stalls and unstalls an endpoint when receiving clear_feature(ENDPOINT_HALT), fixes #1529
  3. Reads the max packet size from the endpoint descriptors, instead of using a compile-time define.

The fix for the endpoint halt clearing likely should be put in the USBD core itse...

fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1529: USBTMC triggers assertion soon after configuration, due to extra CLEAR\_FEATURE\(ENDPT\_HALT\)

One solution would be to modify usbd.c starting at:

https://github.com/hathach/tinyusb/blob/4639cac85cf959c3bfed091c02dce1345f067c7a/src/device/usbd.c#L817

to be:

          case TUSB_REQ_SET_FEATURE:
          {
            if ( TUSB_REQ_FEATURE_EDPT_HALT == p_request->wValue )
            {
              // USB spec requires DTOG to be reset upon clear(EP_HALT),
              // and transfer buffers to be cleared.

              usbd...
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] Issue opened: #1532 USBTMC: Return busy status if interrupt\-in endpoint is busy

Operating System

Windows 10

Board

STM32

Firmware

4639cac85cf959c3bfed091c02dce1345f067c7a usbtmc example

What happened ?

USB488_bREQUEST_READ_STATUS_BYTE should return USB488_STATUS_INTERRUPT_IN_BUSY when interrupt-in endpoint is busy. Currently, it will trigger an assertion.

I will submit PR once other USBTMC work is merged.

How to reproduce ?

Unsure....

Debug Log as txt file

No response

Screenshots

No response

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hid\-report\-len\-uint16
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-more\-warnings
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1534 Add more warnings

Describe the PR

  • increase more warnings option, all ports get -Wnull-dereference -Wuninitialized -Wunused -Wredundant-decls.
  • rp2040 include an additional -Wconversion (pretty troublesome on other ports due to mcu driver). example.cmake is added for holding common examples such as warnings (may move some bsp cmake later on).
  • dual example for rp2040 is an exception since pio-usb has to fix its warnings first.
  • fix freertos build with stm32g4 and stm32wb (also added to ci).
    ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1521: Re\-add some warning suppression for rp2040

I have been doing more tests with various gcc version. In sum up gcc 9 and prior will throw incorrect warnings with Wconversion. gcc 10/11 or later fixed this issue. Therefore I just push some more update to the PR with the version check

if (CMAKE_C_COMPILER_VERSION VERSION_LESS 10.0)

In general, all example will skip the Wconversion option with gcc9, also the suppress_tinyusb_warnings() function will do nothing if the gcc is 10 or later. And the "-Wno-stringop-overflow -Wno-array-bound...

fallow birchBOT
fallow birchBOT
#
robert-hh
[hathach/tinyusb] New comment on pull request #1535: samd: Fix a lock\-up situation at high traffic\.

Thank you for the swift response.
It affects SAM21 and SAMD51 boards. Tested (or to better say failed) with Adafruit ItsysBitsy M4 Express, Adafruit ItsysBitsy M0 Express, Adafruit Feather M4 Express, and Seeed XIAO. But the problem will appear on any SAMD21 and SAMD51 board. With the change, it works fine on these boards. And I use these with a MicroPython port.

One thing which is to be considered: the MicroPython port uses tinyusb v0.12.0. The PR is against the recent master, which i...

fallow birchBOT
#
robert-hh
[hathach/tinyusb] Pull request opened: #1536 samd: Fix a lock\-up situation at high traffic\.

This is the companion PR #1535 as a branch to version 0.12.0. I'm not sure if that is the right way, but at least it changes the right file.

This PR fixes a transmit lock-up, which happens, when data is received
and sent at the same time at moderate to high speeds, like code
which just echoes incoming data.

In my case, an issue was reported here:
https://github.com/micropython/micropython/issues/8521

Describe the PR
A clear and concise description of what t...

fallow birchBOT
#
robert-hh
[hathach/tinyusb] New comment on pull request #1535: samd: Fix a lock\-up situation at high traffic\.

tud_task() can still be used as it previously use (defined as inline function). There is no need to make any changes to application for this regards.

Thank you for merging and the hint. I got an link error using the master branch. tud_task() is part of a common "busy-wait" macro. So probably the #include is missing. Either way the code has to be changed, and the version of the RP2040 lib as well.

fallow birchBOT
#
robert-hh
[hathach/tinyusb] New comment on pull request #1536: samd: Fix a lock\-up situation at high traffic\.

The MicroyPython project uses tinyusb for five different MCU families. All work fine with v0.12.0. I'm taking some care of two of them, mimxrt and samd. The maintainer of MicroPython does not want to have different commits of the same library for different MCU ports. When switching a library version, all ports have to be tested against that and eventually changed. Someone has to do it, and it will take time, in which the fix for SAMD is not available. I can of course use a local copy of the c...

#
hathach
[hathach/tinyusb] New comment on pull request #1535: samd: Fix a lock\-up situation at high traffic\.

tud_task() can still be used as it previously use (defined as inline function). There is no need to make any changes to application for this regards.

Thank you for merging and the hint. I got an link error using the master branch. tud_task() is part of a common "busy-wait" macro. So probably the #include is missing. Either way the code has to be changed, and the version of the RP2040 lib as well.

probably due to the fact that tud_task() is an inline function. For rp2040, you may...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on pull request #1531: USBTMC: Fixes and support for high\-speed USB

Great. Let me know if you have any questions.

Do you use Windows? If not, I believe that Linux comes with a kernel driver for USBTMC, which will operate with python's pyvisa library. On Windows, the driver I mentioned comes with the "NI MAX" software that allows manual interaction with the device. In the tinyusb USBTMC example, I do have a python script that runs a number of testcases using pyvisa (which is how I found this bug, though it is intermittent).

I'm also contemplating creatin...

fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #892: DCD SAM3U Support

finally tried running this

when I connected in high speed I got constant bus resets to high speed

USBD init on controller 0
sizeof(usbd_device_t) = 47
CDC init
MSC init
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Speed
USBD Bus Reset : High Spe...
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #892: DCD SAM3U Support

Full speed HID composite

USBD init on controller 0
sizeof(usbd_device_t) = 47
HID init
USBD Bus Reset : Full Speed

USBD Setup Received 80 06 00 01 00 00 40 00 
  Get Descriptor Device
!USBD Xfer Complete on EP 80 with 18 bytes
  Queue EP 00 with 0 bytes ...
USBD Xfer Complete on EP 00 with 0 bytes
USBD Bus Reset : Full Speed

USBD Setup Received 00 05 7D 00 00 00 00 00 
  Set Address
USBD Xfer Complete on EP 80 with 0 bytes
  dcd_edpt0_status_complete: complete set addre...
fallow birchBOT
#
pigrew
[hathach/tinyusb] Pull request opened: #1537 When clearing an endpoint stall, reset DTOG

According to the USB spec, the DTOG of an endpoint should always be reset to DATA0 when receiving CLEAR_FEATURE(ENDPOINT_HALT), regardless of if the endpoint had been stalled (See citations in #1529).

I believe the attached changes should be made to USBD to facilitate this requirement.

However, some issues to discuss are:

  1. When stalling endpoints (even when not in response to a control request), do we need to purge the event queue from transfers on that endpoint?
  2. When SET_CONFI...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: improve\-ci
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: ci\-parallel\-build
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] New comment on pull request #1541: comment out example\.cmake warnings which break builds of rp2040 sdk or older compilers

Note also, that lots of code like

# Example common such as compiler warnings
include(${CMAKE_CURRENT_SOURCE_DIR}/../../example.cmake)

was added to each example CMakeLists.txt, however there was a function call in each, e.g.

# Example common such as compiler warnings
# Configure compilation flags and libraries for the example... see the corresponding function
# in hw/bsp/FAMILY/family.cmake for details.
family_configure_device_example(${PROJECT})

which would s...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1541: comment out example\.cmake warnings which break builds of rp2040 sdk or older compilers

which would seem like a better place to have allowed each port to specify warnings if it wanted to

Yeah, I agree, it is a better place to add warnings. Though since family.cmake is also used by pico-sdk for and I am not sure if the family_configure_device_example/family_configure_host_example() function are used by other sdk examples and/or user projects. I play a bit safe by only introducing these warnings to tinyusb's examples only, we can refactor this later on.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-rp2040\-remote\-wakeup
#
hathach
[hathach/tinyusb] New comment on pull request #1541: comment out example\.cmake warnings which break builds of rp2040 sdk or older compilers

Update: when build with LOG eanbled e.g make BOARD=raspberry_pi_pico LOG=2 I got

 error: "CFG_TUSB_DEBUG" redefined [-Werror]

due to the macro are defined in 2 places

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1406: HITL setup

more update: hardware in the loop may be possible with github self-hosted
https://docs.github.com/en/actions/hosting-your-own-runners/adding-self-hosted-runners

basically, we will have to setup and local machine and install an github self-host app to connect to github. It will run as an ci instance, we could attach physical device then check the enumeration of new firmware e.g dual cdc example should have both /dev/ttyACM0 & ttyACM1 appeared etc ..

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1406: HITL setup

I think it would be a great thing to do. I have a python script that I run with my USBTMC class driver that verifies a number of conditions (but certainly could be expanded). Using libusb probably would help, as we could more easily test various corner cases, like aborts in the middle of transmissions. (In fact, I lately found a few bugs using my test script...).

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1406: HITL setup

Self Hosted runners

Based on the documentation, this sounds like a questionable idea. The docs suggest only using this for private repositories... I think our "workflow" currently runs when anyone creates a PR, so that could overload the private system, or folks even could run malicious code on the microcontroller... I don't know if there is a way to restrict the workflow to be only when maintainers approve?

Even if it's not automatically run, the hardware-rich testing is a good idea....

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1543: mimxrt: Add/change definitions for MIMXRT11XX boards\.

I just look at 1100 overview, I think we probably don't need an extra define for OPT_MCU_MIMXRT11XX, since NXP/Freescale did a great job with their mcusdk. We could rename this one to simply OPT_MCU_MIMXRT (to also account for rt600/500 in the future as well), the existing one is defined to new one to also allow backward-compatible. And we will update all example to use the new one. Over-time user will migrate (or not)

#define OPT_MCU_MIMXRT          700
#define OPT_MCU_MIMXRT10X...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1543: mimxrt: Add/change definitions for MIMXRT11XX boards\.

On a third thought: Maybe we leave the substitution in TinyUSB. Otherwise a note would be required, and it has to be considered in every potential use of MIMXRT11XX. Even if there is little hope for success, I'll make that PR at NXP.

I think the current ifdef in ci_hs_imxrt.h is working great, I don't think NXP would change this as well. I will make an update for those skip/only.txt in the examples

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

(I've force-pushed this branch with a revision to clean up handling of default control pipe.)

I've convinced myself that this patch removes some bugs, but we still need to examine how endpoint halts interact with class libraries and in-progress transfers.

In particular, I'm worried about race conditions like:

  1. Host sends BULK OUT packets (packet 1 through 4 of 8 packet transfer), and device class handles these packets.
  2. Host sends BULK OUT packet (perhaps the 5th packet of an 8 ...
fallow birchBOT
#
s-ol
[hathach/tinyusb] New comment on pull request #1219: Midihost

I'm also interested in this, it would be good to have an update on the host API status from you, @hathach.

If the host API changed but is stable again I might also try my hand at changing this PR over if @rppicomidi isn't on it already, although I'm much less familiar with tinyusb or the changes at this point.

fallow birchBOT
fallow birchBOT
fallow birchBOT
slender pond
#

Hello. Is it possible to have usb host support for Adafruit ESP32? in particular I'm testing Adafruit Qt Py ESP32-S2. If not, is it planned? or there's a deeper reason like some micro missing, like max3421? Thanks!

fallow birchBOT
#
diminDDL
[hathach/tinyusb] Issue opened: #1547 Example for using multiple TMC ports on one device

While trying to port a project from LUFA to tinyUSB I can't seem to find a way to open several TMC ports on a single device. For example the cdc_dual_ports example had a function that allows the user to select whichever port would be addressed uint32_t tud_cdc_n_write(uint8_t itf, void const* buffer, uint32_t bufsize) I couldn't find anything similar for TMC however. I would like to be wrong but there does not ...

fallow birchBOT
fallow birchBOT
#
MrGreensWorkshop
[hathach/tinyusb] Issue opened: #1548 CDC doesn't respect no flow control setting \(flow control always on\)

Operating System

Others

Board

Raspberry pi pico

Firmware

just simple app to test cdc behavior.

https://github.com/MrGreensWorkshop/RasPiPicoSDK_cdc_test

  • Download
  • Compile and run. (or just use binary named PicoTest.uf2)
  • use Terminal.exe app to check DTR behavior.

What happened ?

Handshake setting is set to none. But to receive data we need to enable to DTR. When handshake is off, we shouldn't be force to enable DTR to receive data. or any other flow control...

fallow birchBOT
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1547: Example for using multiple TMC ports on one device

API-wise, I'm not sure which way to go.... The major question is if the application or TinyUSB should be responsible for the allocation of the class' data structures. I'm contemplating something for memory allocation like:

bool usbtmc_connect_cb(uint32_t config, uint32_t itf, struct tmc_state **state ); // app may malloc or return static memory address
void usbtmc_disconnect_cb(uint32_t config, uint32_t itf, struct tmc_state **state ); // app should free the memory here, if needed
`...
fallow birchBOT
#
diminDDL
[hathach/tinyusb] New comment on issue #1547: Example for using multiple TMC ports on one device

I am not qualified to answer questions on how the library is supposed to be implemented. My only experience with tinyUSB so far has been just messing with the examples and without a deeper knowledge of the USB protocol I am not even sure if I can really do anything else, or contribute in any meaningful way. (Unfortunately the tinyUSB docs are quite minimal.) On the part about other USB libraries the place where I even got the idea for multiple TMC ports is this project https://github.com/xyph...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1547: Example for using multiple TMC ports on one device

It looks like that project only supports a single interface at a time.

I'm starting to believe that TMC is not a great protocol to use for USB-GPIB adapters. VXI-11.2 (or perhaps HiSLIP) is a better match. These could be done using ethernet over USB (RNDIS, ECM, etc...) Also note that each USB488 interface needs 2 endpoints, and most USB devices are limited to 6 or 8 endpoints... so 2 or 3 TMC interfaces per USB device.

robust walrus
#

ideally you should be able to do both device and host at the same time

#

its not planned from the adafruit side but I don't know if espressif is working on it

#

(or has it working)

tight turret
#

I am new to this community so hopefully I am asking this in the right channel. I am working on a project using an ESP32-S2 running CircuitPython (CP). I am currently using the TinyS2 for development but am in the process of designing a custom PCB that will be more suited to the specific hardware requirements of the project. In an effort to validate the process I will need to work through to set up CP on a fresh ESP32-S2 microcontroller I swapped the original one out on one of my dev TinyS2 boars as a test platform to sort out getting this process defined and CP up and running on a fresh ESP32-S2. I am unable to get any response from the test board over USB. Windows 10 does not even see a USB device in device manager. I am also not getting any response from the default board UART. I am assuming that in order to get CP up and running I need to first install TinyUSB? I have had no issues updating firmware on a different TinyS2 board using esptool by putting the board in boot mode and using the TinyUSB virtual COM port that shows up in boot mode. I have done this type of thing many times on Micropython ESP32 based projects where I simply push in the code over the UART interface but the native USB workflow is a bit new to me and any help on this would be greatly appreciated. I have looked for documentation on this and honestly struggling to fully understand exactly what dependencies I need to get sorted and specifically what process I need to go through once the dependencies are all put in place and proven functional. I appreciate any help on this and I am happy to provide any additional information if needed.

glacial stratus
tight turret
#

@glacial stratus thanks for the quick reply. To further clarify, I almost never use UF2 and have exclusively uses a batch file I made to call esptool.py to install a target .bin, this process works fine on two different TinyS2s that were right out of the box however I changed the actual ESP32-S2 microcontroller chip on one of my TinyS2 dev boards for the sole propose of proving out how to take a blank freshly installed ESP32-S2 chip from nothing to a functional CPython firmware instal as I am designing a custom board for this specific project and I will need to have a working process to get CPython up and running on the new boards. The issue I am having is that the blank ESP32-S2 does not respond to the boot/reset button sequence to get it into boot mode which means I do not have a USB virtual com port to push the .bin file to. I tried using the UART pins connected through a know previously working line driver setup but on both the fully functioning OEM TinyS2 and the other TinyS2 that I replaced the microcontroller on esptool.py fails to connect to the ESP32-S2. I have never built my own CPython .bin but plan to for this board. I suspect that a fresh “blank” ESP32-S2 does not have TinyUSB installed/configured so I have no way to activate the USB COM that shows up in boot mode which seams to be the only com port I am currently able to push the .bin file to. I hope all that makes sense and once again, I appreciate your help!

glacial stratus
tight turret
#

@glacial stratus ah, okay. So the com port that shows up in boot mode has nothing to do with TinyUSB but rather an independent CDC function that ROM activates in boot mode? If this is the case, I am guessing that TinyUSB gets installed as part of the CPython .bin file which makes sense as that is when the mass storage and repl CDC shows up as they are all handled with TinyUSB? I inspected the soldering very closely and even fixed a few pins that lacked sufficient solder but I did have to get the chip pretty hot to hot air work the thermal ground pad. I think you are correct that this is a chip issue. I will pop a new one on and see how it goes. Thank again for your support!

glacial stratus
#

The combined.bin file from the TinyUF2 repo includes TinyUF2 and the partition table (note: TinyUF2, not TinyUSB: TinyUF2 is built with TinyUSB).

#

however, the circuitpython .bin does not include TinyUF2

tight turret
#

@glacial stratus understood, thanks for the nomenclature clarification, this has been so helpful. Much appreciated!

glacial stratus
#

good luck!

tight turret
#

@glacial stratus I put a new MCU on the board but this time I used an oven to keep the heat under control. I was able to get it all up and running. I wanted to say thanks again for the support!

fallow birchBOT
#
MatiMcFly
[hathach/tinyusb] New comment on issue #435: "Set Address failed" error on Windows

I am experiencing the exact same problem. Is there already a workaround available that doesn't involve fiddling around with drivers?

I'm trying to implement a composite device that has RNDIS capabilities and a serial interface. This works fine as long as I only provide one configuration descriptor.
As soon as I add a second configuration (for CDC_ECM support since Mac OSX devices don't support RNDIS), my windows PC will only pick the very first interface it sees in a descriptor.

After...

fallow birchBOT
fallow birchBOT
#
TravisRo
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

This has been done intentionally. They use the DTR signal to detect when the PC/host has actually opened or closed the com port. I agree, it causes problems it some cases. Most of the arduino CDC implementations do this as well; it is fairly common.

I have a pull request submitted that adds a CH341 emulation class driver which would solve your problem.
https://github.com/hathach/tinyusb/pull/1507

You can get this from my fork here: [https://github.com/TravisRo/tinyusb/tree/ma...

fallow birchBOT
fallow birchBOT
#
MrGreensWorkshop
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

Thank you for responding my inquiry. Yes I checked the code. And Thank you for the PR #1507

When people use MCU which support USB, and if serial port is needed using CDC is common to use instead of using USB serial converters. When it happens, you expect using CDC to be the same as using a USB serial converter. Using DTR to detect connection shouldn't be implemented. We can't expect all application to raise DTR when open serial port. That's why I raise this issue.

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #1543 mimxrt: Change the definitions for MIMXRT boards\.

thank you for you PR. I change my mind a bit, and re-add the OPT_MCU_MIMXRT11XX. Application should continue to use either OPT_MCU_MIMXRT10XX or OPT_MCU_MIMXRT11XX , the OPT_MCU_MIMXRT is used internally. Although they have no differences now, but in the future, NXP may just introduce some breaking changes e.g to rt1200, so we are better to be safe.

It is a bit late, since it has a compile issue with rt1050 when bumping up mcu-sdk and I have to switch to troubleshoot other issue. Tu...

fallow birchBOT
#
MrGreensWorkshop
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

I saw in #482 too. I think author of this repo only tested in VT100 terminals like PuTTY or Teraterm. That's why he thinks its ok, but it's not.

PuTTY or Teraterm terminals are made for VT100 etc., not exactly plain text transmission. You can use if you want. But those are uses other pins too. DTR -> DSR and DSR <- DTR. That's the problem.

Asking host application for DSR on is reduce the compatibility with other apps if user is explicitly select no flow control.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1543: mimxrt: Change the definitions for MIMXRT boards\.

Thank you for merging. I have tested it with both a MIMXRT1170EVK and a MIMXRT1050_EVKB board. Both work. In the Makefile I use OPT_MCU_MIMXRT, being happy that there is one difference less ni the Makefile for the boards.

no problems, I am the one to say thanks. Everything is working well now. The bsp/imxrt can continue to use the OPT_MCU_MIMXRT that would be no problem at all. I mean in other applications, user should use the more specific MCU macros. It is not a matter now, but N...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-old\-gcc
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kilograham
[hathach/tinyusb] Pull request opened: #1554 Rework CMake example warnings some more
  • Remove example.cmake and it's calls from each example, as we already have family_ CMake functions that configure examples
  • Added new CMake function to add the warnings to a target, and (conditiaonlly) called it from the rp2040 family.cmake allowing turning warnings off if it breaks some future SDK release.
  • Note: I did not add this to any other family.cmake since there don't seem to be any that define the family_configure_xxx_example` functions
fallow birchBOT
#
DNedic
[hathach/tinyusb] Issue opened: #1558 tud\_cdc\_rx\_cb is not called

Operating System

Linux

Board

STM32 boards

Firmware

examples/device/cdc_msc_freertos

What happened ?

Using the cdc_msc_freertos example compiled with either ESP-IDF v4.4.1 or latest master with an STM32 chip, when copying files to the MSC device the tud_cdc_rx_cb is not being called.

How to reproduce ?

  1. Grab the TinyUSB repo
  2. Set up ESP-IDF and export environment
  3. Build example using TinyUSB make build system
  4. Start a debug session and place a breakpoint...
solemn shoal
#

Hey guys! I am super new to this and I've never done anything tinyusb related. I was working on a project and the goal was to have a board that's running CircuitPy to be able to detect what kind of Operating System the host it's being connected to is running. So for example, if I plug the board into a Mac, the board should figure out that it's running MacOS. Consequently, if I plug it to a Windows machine, it should know that it's running Windows etc. Would it be possible to achieve something of this sort by analysing the data packets that are being sent back and forth between the device and the host during a USB enumeration phase? From my understanding, each host OS has some unique patterns in which the data exchange is being made. Would we be able to tell from those patterns what OS the host is running? I was thinking of somehow rewriting some of the steps in the enumeration phase in order to trace back the patterns and assign them to a specific OS

fallow birchBOT
#
focus-martin
[hathach/tinyusb] Issue opened: #1559 rule\.mk line 94 \- A subdirectory or file already exists

Operating System

Windows 10

Board

lpcxpresso55s28

Firmware

examples/device/hid_generic_inout

What happened ?

I am trying to compile the hid_generic_inout device example but the following error appears:

A subdirectory or file _build\lpcxpresso55s28\obj\examples\device\hid_generic_inout\src\ already exists.

I understand that the problem is when the command promt mkdir is executed from rule.mk file or something similar.

How to reproduce ?

Following th...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\_warning2
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1554: Rework CMake example warnings some more

@kilograham though there are another issue when compiling with LOG=2 in tinyusb example:

make BOARD=raspberry_pi_pico LOG=2

<command-line>: error: "CFG_TUSB_DEBUG" redefined [-Werror]

The CFG_TUSB_DEBUG are defined twice in

https://github.com/hathach/tinyusb/blob/1a8c3a863bb1d172364ffe80029620fa75efc7a4/hw/bsp/rp2040/family.cmake#L121-L123
https://github.com/hathach/tinyusb/blob/1a8c3a863bb1d172364ffe80029620fa75efc7a4/hw/bsp/rp2040/family.cmake#L55-L59

I could ...

fallow birchBOT
robust walrus
solemn shoal
robust walrus
#

you'd probably want to do it in tinyusb

solemn shoal
#

Fair enough. I'll dig around the project and see what I can come up with

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: revert\-hid\-callback\-len\-temporarily
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #435: "Set Address failed" error on Windows

It seems that windows 10 decides that our descriptors aren't correct and refuse to proceed with enumerate. I still haven't tried this out

@MatiMcFly your issue is different, in this issue, device isn't got it address assigned yet. Double check your descriptor, length, type etc... You could create your own issue with detail of setup/code/log for reproducing/troubleshooting.

#
hathach
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

CDC should still send & receive data even if DTTR/RTS aren't set. Could you try the stock example from this repo examples/device/cdc_msc to see if it could echo back. cd to the example directory and run

make BOARD=raspberry_pi_pico

If yes, then the issue is pico-sdk making use of the connect() API which return the state of DTR. In that case you should ask rpi team to remove that check.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

Kind of you are right it's their problem. I think there must be better implementation for tud_cdc_connected don't you think so?

Let me know if you figure out the better way to determine there is a connected client, I am happy to make the changes.

Note: there is a difference in cdc behavior when dtr is not set, the tx buffer will become overwritable, i.e if tx fifo is full, it will be overwritten. more details of this behavior is discussed in previous issue/pr mentioned above.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release\-0\.14\.0
fallow birchBOT
#
MrGreensWorkshop
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

I made some changes and test it's behavior.

https://github.com/raspberrypi/pico-sdk/blob/master/src/rp2_common/pico_stdio_usb/stdio_usb.c

first changed this

bool stdio_usb_connected(void) {
    return true;
}

and renamed tud_cdc_connected() to stdio_usb_connected()

When port is opened all data in tx buffer output to terminal.
This is not problem because when handling data on pc we can flush buffer.

Is there any other concerns?

#
hathach
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

as mentioned above, the only difference in behavior is tx fifo can be overwritten when dtr is not set. When dtr is set, tinyusb will blocking wait for tx fifo to be sent since it is certain there is waiting client. In other words, If you send too many data in short period, there maybe some missing.

connected() is option, going to support dtr or not is up to stdio integration i.e rpi team. For the changes you propose is within pico-sdk, you should ask them to see if it is acceptable or not.

fallow birchBOT
fallow birchBOT
#
MrGreensWorkshop
[hathach/tinyusb] New comment on issue #1548: CDC doesn't respect no flow control setting \(DTR control needed to receive data\)

I open the this PR on pico-SDK.

Clearly tud_cdc_connected used by choice of pico-sdk team.

though more and more terminal use dtr as connected nowadays.

About that. It is also mentioned in #482.

Universal Serial Bus Communications Class Subclass Specification for PSTN Devices for Abstract Control Model (ACM) ..

PSTN Devices are mostly modems. Most of time we need flow control to control data flow. Let's not confuse with m...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
mjan-jansson
[hathach/tinyusb] Issue opened: #1572 CDC: Hung once rx fifo queue is sufficient full

Operating System

RaspberryPi OS

Board

RaspberyPi Pico

Firmware

Pico is running Pico SDK 1.4.0
The RPI4 is running Linux dev1 5.10.103-v7l+

What happened ?

The board runs as a USB device. It has a loop which write 20 times more data than it reads, over the CDC serial port. When using some USB hosts (but not all), the board will eventually hang and not be able to send any data.

I believe that this is what is happening when running the loop mentioned above:

  1. The ho...
fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1572: CDC: Hung once rx fifo queue is sufficient full

One could argue that neither RPi4 nor the Pico is at fault here. I am reasoning that the RP2040 MCU should silently ignore the OUT packets until it is ready to accept more data. By not responding to the OUT packets, the host should treat this as a failed transmission (data error), so host should retry but perhaps not forever? After some retries, the devices would be declared broken. On the other hand, not being able to accept data for long periods of time could be an acceptable scenario for ...

#
mjan-jansson
[hathach/tinyusb] New comment on issue #1572: CDC: Hung once rx fifo queue is sufficient full

From my (quite recently acquired) understanding of USB, I'd like to suggest a solution.

I think the problem is that the OUT endpoint is not being "armed" in step 4 above. Even though the rx fifo queue is full, the hardware buffer should be setup to receive more OUT packets. Once the host tries to send another OUT packet, it should be replied with a NAK until there is room in the fifo queue to accept more data. Unless the hardware think the buffer is already full, it would reply with an AC...

fallow birchBOT
#
pigrew
[hathach/tinyusb] New comment on issue #1572: CDC: Hung once rx fifo queue is sufficient full

I have a RP2040 somewhere, but I'm not familiar with its USB peripheral. I've also not used the FIFO transfers in TinyUSB.... (I only have experience with the block transfer modes).

It would be trickier programming, but the device code could let the HW buffer fill up while the SW FIFO is full. Once the HW buffer is full, the peripheral should automatically NAK future transfers. If it never NAKs when one or both buffers are full, than that certainly is a problem.

You may be able to...