#tinyusb

1 messages ยท Page 6 of 1

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: labeler-perm
#
[hathach/tinyusb] New branch created: labeler-pull_request_target
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

@clhenry Just to be clear, @hathach may be very busy, and while I am a collaborator, I mostly focus on backend stuff. I want to wait for @hathach to be less busy so he can give guidance on "sometimes no OS needs a delay" problem.

You're already expected to instantiate an interrupt handler yourself and place a call into tud_int_handler in your application. I'm not against adding a function like e.g. `tud_de...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

I'm tried to added support AT32F415 on TinyUSB, it just for in case if there are people want something to choose between CherryUSB.

I've try follow everything, it did get compiled the firmware out. But flashing to the MCU doesn't seem to work, since it just sending error about USB not recognized. If you have some free time, could you take a look for review. Thanks

Notes:
Your project of CherryUF2 is really good and it work great. Oh btw, can I reuse UF2_FAMILY_ID on your CherryUF2?

fallow birchBOT
#

Changing to a for statement, I agree that eliminating the need for conditional compilation is beneficial. However, considering execution speed, sticking with the original code that uses bitwise operations might be advantageous. In my estimation, itโ€™s unlikely that multiple bits in BRDYSTS will be set simultaneously. Therefore, the for statement would mostly be looping without doing. By using bitwise operations, the loop can be executed only the number of bits that are set in BRDYSTS, avoi...

fallow birchBOT
fallow birchBOT
#

FWIW I'm seeing the exact same issues. I've been testing with a pico and 8bitdo wireless adapter and when it's connected during boot, though tuh_hid_mount_cb is called, subsequently, tuh_hid_report_received_cb is never called.

If I boot without the adapter connected, tuh_hid_report_received_cb does get called, though only dpad change triggers - pressing any other button doesn't seem to trigger the callback (though if I hold a button, such as "START" and then press the dpad, I can see...

fallow birchBOT
#

Typically found a workaroundโ€ฆsort ofโ€ฆ the very next moment. Not sure how far this is useful, but works for my 8bitdo wireless adapter.

If I put the adapter in to "sega genesis mini" mode, I'm getting all the buttons: dpad left + dpad up + select.

This is the hid report (which is slightly different to the usual ones I've seen on the adapter):

05 01 09 04 A1 01 A1 02 75 08 95 05 15 00 26 FF 
00 35 00 46 FF 00 09 30 09 30 09 30 09 30 09 31 
81 02 75 04 95 01 25 07 46 3B 10 65 14 ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Operating System

Linux

Board

n.a.

Firmware

n.a.

What happened ?

I'm trying to package tinyusb for inclusion in Debian. I was thus reading through all the copyright of the included files and found this:

**  (c)Copyright Ac6.
**  You may use this file as-is or modify it according to the needs of your
**  project. Distribution of this file (unmodified or modified) is not
**  permitted. Ac6 permit registered System Workbench for MCU users the
**  rights to distr...
fallow birchBOT
fallow birchBOT
#

It's an old issue from ST who hasn't update their license for years.

Okay. Then I have to exclude those, sadly.

Another small nit I found is in hw/bsp/stm32g0/boards/stm32g0b1nucleo/board.h which says:

Copyright (c) 2034, HiFiPhile

I guess that's a typo and that should say 2024?

I don't it's a good idea to make a Debian package as build system artifacts are in the source folder

You mean they are getting placed there when building? Because they are not kept in git and...

fallow birchBOT
fallow birchBOT
#

Yes if you use CMake only.

Okay, that is what I'd like to use this for. As you point out, it doesn't make sense to package this for use-cases that require the source directory being writable. Those who need that can either cp -a the files from /usr/src/tinyusb/ or git clone as usual.

I have another copyright question. The following files claim they are auto-generated:

hw/bsp/lpc11/boards/lpcxpresso11u37/lpc11u37.ld
hw/bsp/lpc11/boards/lpcxpresso11u68/lpc11u68.ld
hw/bsp...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: build-clang
fallow birchBOT
#

ๆ„Ÿ่ฐขๆ‚จ็š„ PR๏ผŒไฝ†ๅฎƒๆ›ดๅƒๆ˜ฏไธ€ไธช็คบไพ‹้…็ฝฎ๏ผŒๅบ”่ฏฅๆทปๅŠ ๅˆฐ rt-thread ่€Œไธๆ˜ฏ tinyusbใ€‚

ไฝฟ็”จๆ‚จ็š„ๅฎๅชไผšไฝฟไบ‹ๆƒ…ๅ˜ๅพ—ๆ›ดๅŠ ๅคๆ‚๏ผŒ้œ€่ฆๆฃ€ๆŸฅๆ›ดๅคšๆกไปถๅนถไธ”ไป…ๆ”ฏๆŒ CDC+MSC๏ผŒๅฆ‚ๆžœๆœ‰ไบบๅชๆ˜ฏๆƒณ่ฆ 2*CDC ๆ€ŽไนˆๅŠž๏ผŸ ๅบ”ไธ“้—จ็ผ–ๅ†™็”ณ่ฏทใ€‚tusb_descriptor.c/.h

Hello, by doing this you can add the tinyusb repo as the rtthread package to the project. This form is similar to the LVGL project: https://github.com/lvgl/lvgl/tree/master/env_support/rt-thread

fallow birchBOT
#

Hello, by doing this you can add the tinyusb repo as the rtthread package to the project. This form is similar to the LVGL project: https://github.com/lvgl/lvgl/tree/master/env_support/rt-thread

Tinyusb has much more configurations than LVGL, it's impossible to cover every use case in a single tusb_config.h and tusb_descriptor.c/.h. That's why every example has its own configurations.

For example if you compare tusb_descriptor.c from video_capture and usb_msc examples there ...

fallow birchBOT
#

ๆ‚จๅฅฝ๏ผŒ้€š่ฟ‡่ฟ™ๆ ทๅš๏ผŒๆ‚จๅฏไปฅๅฐ† tinyusb ๅญ˜ๅ‚จๅบ“ไฝœไธบ rtthread ๅŒ…ๆทปๅŠ ๅˆฐ้กน็›ฎไธญใ€‚ๆญค่กจๅ•็ฑปไผผไบŽ LVGL ้กน็›ฎ๏ผšhttps://github.com/lvgl/lvgl/tree/master/env_support/rt-thread

Tinyusb ็š„้…็ฝฎๆฏ” LVGL ๅคšๅพ—ๅคš๏ผŒไธๅฏ่ƒฝๅœจๅ•ไธช ๅ’Œ ไธญๆถต็›–ๆ‰€ๆœ‰็”จไพ‹ใ€‚่ฟ™ๅฐฑๆ˜ฏไธบไป€ไนˆๆฏไธช็คบไพ‹้ƒฝๆœ‰่‡ชๅทฑ็š„้…็ฝฎใ€‚tusb_config.h``tusb_descriptor.c/.h

ไพ‹ๅฆ‚๏ผŒๅฆ‚ๆžœๆฏ”่พƒ from ๅ’Œ example๏ผŒๅˆ™ๅ‡ ไนŽๆฒกๆœ‰ไปปไฝ•ๅ…ฑๅŒ็‚นใ€‚tusb_descriptor.c``video_capture``usb_msc

ๅบ”ๅˆ ้™ค่ฟ™ไบ›ๆ–‡ไปถใ€‚

OK.

fallow birchBOT
#

Operating System

Windows 11

Board

ra8d1_evk

Firmware

device cdc_msc

What happened ?

image

How to reproduce ?

add dcd_rusb.c to ra8d1 project

void hal_entry(void) {
  board_init();

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

  if (board_init_after_tusb) {
    board_init_after_tusb();
  }

  while (1) {
    tud_task();...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: nrf-code-format
fallow birchBOT
#

่ฟ™ไธช้—ฎ้ข˜ไนŸๅฏไปฅๅœจRA6M5/ๅ…ถไป–RA็ณปๅˆ—MCUๅนณๅฐไธŠ้‡็Žฐใ€‚

This problem can also be reproduced on other RA series MCU platforms.

Please provide specific board information. Make sure you use the stock example from tinyusb repo, the 1st seems to use other examples.

fallow birchBOT
#

Hello, by doing this you can add the tinyusb repo as the rtthread package to the project. This form is similar to the LVGL project: https://github.com/lvgl/lvgl/tree/master/env_support/rt-thread

Tinyusb has much more configurations than LVGL, it's impossible to cover every use case in a single tusb_config.h and tusb_descriptor.c/.h. That's why every example has its own configurations.

For example if you compare tusb_descriptor.c from video_capture and usb_msc examp...

fallow birchBOT
#

For what it's worth, here is the final copyright file in DEP5 format. Note, that not all files in the Files-Excluded field are interesting for you because Debian's rules are more strict than the rules that you are subject to. I omitted the copyright texts themselves for brevity.

Format: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: tinyusb
Upstream-Contact: https://github.com/hathach/tinyusb/issues/
Source: https://github.com/hathach/tinyusb
#...
fallow birchBOT
#

For U5 (maybe also ESP32-S3 who failed HIL) I've to reserve an excessive amount of space like 90 words in order to make it work, otherwise packet ending will be corrupted like my 1st comment.

@hathach I doubt it has something to do with new feature like dma_dynamic, ST hasn't update their comment for U5 in HAL driver:

When DMA is used 3n * FIFO locations should be reserved for internal DMA registers */

I think I need help from somebody knowing dwc2 internal structures...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Operating System

Windows 10

Board

Lichee Nano (Allwinner f1c100s)

Firmware

portable/sunxi/dcd_sunxi_musb.c

OS: ucos2

What happened ?

Losing half of bandwidth. Half of the packets wouldn't trigger interrupts.

Interrupt would be triggered by packet n, but wouldn't triggered by packet n+1.

How to reproduce ?

Receive data by hid set-report.

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

tusb.log
...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

ๆˆ‘ๆŽจ้€ไบ† pre-commit ็š„ไฟฎๅค็จ‹ๅบใ€‚็œ‹่ตทๆฅไธ้”™๏ผŒ่ฏทๆณจๆ„๏ผŒ็”ฑไบŽๆˆ‘่ฟ˜ไธ็Ÿฅ้“ๅฆ‚ไฝ•ไฝฟ็”จ rtthread๏ผŒๆˆ‘ๅฐ†ๆ— ๆณ•็ปดๆŠคไปฃ็ ๏ผŒ่ฏทๆไบค PR ไปฅๅธฎๅŠฉไฝฟๅ…ถไฟๆŒๆœ€ๆ–ฐ็Šถๆ€ใ€‚

No problem, I am an official member of rtthread and can help you maintain it.

fallow birchBOT
#
[hathach/tinyusb] New branch created: add-esp32-max3421e
fallow birchBOT
fallow birchBOT
#

dcache code should be removed and add MPU suggestion to make usb ram non cacheable:

  • Not all internal buffers are aligned to cache line size and has size of multiple cache line size, speculative read or cache eviction of adjacent variables could lead to racing with DMA.
  • Frequent cache clean invalidate hurt performance
  • In most cases Cortex-M7 recommend use DTCM where cache is not used
fallow birchBOT
fallow birchBOT
#

_Right now the app would not be informed if there was an issue due to the fasle positives. Any data received for a dedicated OUT endpoint would wrongly flagged as INVALID even there wasn't a communication issue.

Due to this the behavior between a dedicated OUT endpoint and if there is none, so that the data is transferred over the control endpoint, is different which isn't good in my opinion._

The callback is basically only there to pass the result state and so to may provide additional...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Related area

wch ch32v20x

Hardware specification

wch ch32v20x

Is your feature request related to a problem?

hello , when tinyusb will support wch ch32v/f full speed usb host, thanks

Describe the solution you'd like

no

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, dicussion and documentation.
fallow birchBOT
fallow birchBOT
#

Hi, sorry for huge delay. I'm not an expert of NCM class but I'd like to move the things on.

Compared to RNDIS current NCM implementation is problematic, with STM32F723, #2564 applied:

MSS vs Mbit/s RNDIS NCM
100 7.25 7.04
400 21.4 6.75
800 34.8 6.97
1450 34.8 8.17

On the bus I observed high delay between OUT and IN transfer, also between 2 OUT transfers.
![image](https://github.com/hathach/tinyusb/assets/4375114/7a2b92bb-b...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Describe the PR
The send break capability bit is needed for serial break support with Linux and possibly MacOS hosts. A recent Linux kernel patch made it check the ACM capability bits before sending a serial break. Older kernels didn't check and would always send a serial break.

Additional context
See https://forums.raspberrypi.com/viewtopic.php?t=369851#p2216659 for original discussion.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Out of curiosity: did you test different TCP_WND with RNDIS as well?

Here is RNDIS on Arch Linux:

MSS vs Mbps default x2 x4
100 7.48 7.54 7.74
200 14.7 14.1 14.7
400 25.6 27.8 27.2
800 38.8 41.8 50.9
1450 38.8 65.4 71.9

At high MSS throughput is little higher than my previous test... so TCP_WND helps RNDIS as well. On Windows 10 there isn't much difference, always at ~11Mbps @1450.

And the other poi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: update-cal-version-num
fallow birchBOT
#
[hathach/tinyusb] New branch created: ci-update
fallow birchBOT
fallow birchBOT
#

Yes, I had the feeling as well and as far as I remember I found a bug in iperf sources but was too busy/lazy to put the fix into their merge machinery.

You can give the attached file a try.

lwiperf.txt

Another point concerning buffer/frame sizes: I'm currently checking Zephyr sources. They do not transmit frames from device -> host which are > NET_ETH_MAX_FRAME_SIZE, which is 1500+header_size

fallow birchBOT
#

Operating System

Others

Board

STM32F401CC

Firmware

See https://github.com/manuelbl/JavaDoesUSB/blob/main/test-devices/loopback-stm32/src/vendor_custom.c

What happened ?

I am maintaining code with a custom device class implementation that has to support changing the alternate interface settings. When the alternate interface is changed, the code closes the current endpoints (in reverse order) and opens the interfaces of the selected interface.

Until recently, this has ...

#

Possibly, it was a deliberate decision that usbd_edpt_close() does not free the TX FIFO RAM.

Yes. usbd_edpt_close() will be removed later.

I am maintaining code with a custom device class implementation that has to support changing the alternate interface settings.

Your implementation is out of USB specification.
These FIFO alloc/free routines are used for ISO endpoints where EP size changes in each alt settings, they are deprecated since too buggy and replaced by `dcd_edpt_i...

fallow birchBOT
#

I got some major throughput regression updating LWIP to master, @ 800 MSS it went down to 37Mbps from 46 Mbps.

I tried your lwiperf but it's not better, instead of having 0bps iperf just hung.

Log shows:

lwiperf_tcp_poll
...
lwiperf_tcp_poll
lwiperf_tx_start_impl
lwiperf_tcp_client_connected
lwiperf_tcp_client_send_more a
lwiperf_tcp_client_send_more b
lwiperf_tcp_poll
...
lwiperf_tcp_poll
lwiperf_tcp_client_send_more end time

Revert LWIP to 2.1.2, another f...

fallow birchBOT
#

It seems you are switching bulk and interrupt ep with alt settings.

Alternate settings are mean to be used to adjust bandwidth allocation, such as in UAC class.

While it's not forbidden, AFAIK there is no standard class defined by USB-IF has such behavior. It's impossible to maintain a stack supporting all kind of behaviors.

For your case there are 2 ways:

  • Use Set configuration to make major changes
  • dcd_edpt_iso_alloc() and dcd_edpt_iso_activate() should work
fallow birchBOT
#

@HiFiPhile I agree that it's mainly used for adjusting the bandwidth. The only exceptions that I'm aware are the DFU and the NCM classes. DFU is very simple as it only uses the control endpoint. With NCM, I'm not really familiar.

It's reasonable decision to restrict alternate interface to bandwidth adjustment. It would be even better if it was documented. Is there a place where this could be added? I would submit a PR.

Thanks for the pointing out dcd_edpt_iso_alloc() and `dcd_edpt_iso...

fallow birchBOT
#

It's reasonable decision to restrict alternate interface to bandwidth adjustment. It would be even better if it was documented. Is there a place where this could be added?

I agree there isn't much documentation for advanced usage. And I don't have idea where it should be put...

If you use NCM you can give a try the new driver https://github.com/hathach/tinyusb/pull/2227


@hathach Should we rename dcd_edpt_iso_alloc() and dcd_edpt_iso_activate() to cover all endpoint types ?...

fallow birchBOT
#

On the PI Pico, depending on your use case, this issue may be worked around by sensing VBUS instead; GPIO 24 is hardwired for that on the Pico. (WL_GPIO 2 on the PicoW) This will only work if VBUS is fed exclusively by USB though.

Good to know; but in my case the +v USB pin is cut and the Pico (actually Seeed XIAO RP2040) is externally powered so this wouldn't be a suitable workaround.

fallow birchBOT
#

Interesting... when I implemented the driver, I did a lot of performance testing. And honestly: a lot was also guess work. One of the assumptions was, that having at least two buffers for each RX/TX would be of benefit, because while one frame is sent, the other can be filled (TX) or while a received frame is being handled it should be a good idea to have one concurrently receiving new data.

And I'm almost sure, that on my relatively slow RP2040 that was the case: I'm getting there aroun...

fallow birchBOT
#

And I'm almost sure, that on my relatively slow RP2040 that was the case: I'm getting there around 5MBit/s in both directions, so the link is at 50% usage.

Could you make test if current settings works well in your case ?

Nevertheless, I have the feeling we are hunting some performance issues (which are optimizations and perhaps further to investigate).
Any real reason to not merge the driver?

Well main reason is lacking of ressource, even my own PR's are missing from review.

...

fallow birchBOT
fallow birchBOT
#

Gosh... the number of screws to turn tends to drive me crazy: on my device, if setting CFG_TUD_NCM_*_NTB_MAX_SIZE=2048 then iperf produces retries. This can be circumvented by setting wNtbOutMaxDatagrams=1, but this is actually not the intention. So the 3200 are not randomly selected. But don't ask me, why the 2048 length produces errors.

So here are my results (number=buffer-size, n=x means number of buffers):

| MSS vs Mbps | org | 2048/n=1 | 3200/n=1 |
| ---- | ---- | ---- | ---- ...

fallow birchBOT
#

fighting with the parameters and trying to understand... that's the current outcome:

#ifndef CFG_TUD_NCM_IN_NTB_MAX_SIZE
    /// must be >> MTU
    #define CFG_TUD_NCM_IN_NTB_MAX_SIZE        (2 * TCP_MSS + 100)     // can be set to 2048 without impact
#endif
#ifndef CFG_TUD_NCM_OUT_NTB_MAX_SIZE
    /// must be >> MTU
    #define CFG_TUD_NCM_OUT_NTB_MAX_SIZE       (2 * TCP_MSS + 100)     // can be set to smaller values if wNtbOutMaxDatagrams==1
#endif

Meaning: CFG_TUD_...

fallow birchBOT
#

I've tried this PR in my project directly. I'm using an stm32f722ze, OTG_HS peripheral with internal FS phy, a single CDC interface with nothing of note in terms of config. ep0 is 64B, CDC bulk are also 64B. I'm using GCC12.3 with -O0 and only ICACHE enabled.

Unfortunately, as is, the PR did not work. During enumeration a broken ep0 xfer corrupts a big chunk of the sram through the dma controller. I am also using the MPU, so I know it's not the CPU that does this:
![image](https://github....

fallow birchBOT
#

I tried catching the moment where the xfer length gets corrupted. I added this. It's probably not correct, however the CDC does seem to work correctly now and the USB enumerates properly.

Humm that's interesting... Just checked ghwcfg registers they are the same as F723, so the only difference is F723 has an internal HS phy.

#

The epout interrupt seems to be triggering twice. Example:

with this PR:

USBD Setup Received 80 06 02 03 09 04 FF 00 
  Get Descriptor String[2]
  Queue EP 80 with 30 bytes ...
USBD Xfer Complete on EP 80 with 30 bytes
  Queue EP 00 with 0 bytes ...
USBD Xfer Complete on EP 00 with 0 bytes
USBD Xfer Complete on EP 00 with 0 bytes

with latest master:

USBD Setup Received 80 06 02 03 09 04 FF 00 
  Get Descriptor String[2]
  Queue EP 80 with 30 bytes ...
USBD Xfer...
fallow birchBOT
#

@HiFiPhile
https://github.com/leptun/Avionus_Firmware/tree/tusb_dma
Here is the code that I am using. I've created a branch where I've disabled pretty much anything that is unrelated to usb. You should be able to get the log on the SWO trace. I am also initializing almost no peripheral, so you can probably run it on the stm32f723 eval board. It's using the HSE at 24MHz. You might have to change that in App/config.hpp. Let me know if this also triggers the bug for you.
To build the project...

#

Perhaps a parameter for wNtbOutMaxDatagrams should be added to allow the regular user as well to enter parameter hell!?

Yes why not.

So the current configuration isn't there for no reason, at least with my configuration. I've done also intensive tests with SystemView and outcome was the configuration you can see in the repo.

If you agree we can set NTB default at (2 * TCP_MSS + 100) and N=1 with a comment mentioning increasing N may increase performance in trade of RAM usage...

fallow birchBOT
fallow birchBOT
#

Humm.. seems out of RAM ,as HS needs more buffer:

C:/ST/STM32CubeIDE_1.15.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.11.3.rel1.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe:E:\mcu\stm32f7\Avionus_Firmware\STM32F722ZETX_FLASH.ld:370 cannot move location counter backwards (from 000000002003ec68 to 000000002003e800)
collect2.exe: error: ld returned 1 exit status
make: *** [makefile:155: Av...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Huh, I did notice it enumerated slower, but I thought that was just my PC acting up since I have tons of endpoints active on the same root hub. But you are right, there are more bus resets than there should be. I don't think I noticed this behaviour on the disco with the HS phy.
This is what it looks like now on the logs:
dwc2_dma.txt
Weird that SWO didn't work.

fallow birchBOT
#

Ha ! Endpoint transfer is queued before it's opened, seems in DMA mode it's more sensitive.

Maybe we will add more assertion.

 krpc_error_t KrpcClient::krpc_close() {
-	tud_cdc_n_read_flush(0);
-	tud_cdc_n_write_clear(0);
+	if(tud_ready()){
+		tud_cdc_n_read_flush(0);
+		tud_cdc_n_write_clear(0);
+	}
 	return KRPC_OK;
 }
fallow birchBOT
#

Heh, nice catch! Some assertion for this scenario might be helpful, though I'm not sure if this should go in the CDC class or in the usbd driver.
Thanks a lot for helping out with getting this PR working with my project. If I notice any other issue with it, I'll let you know :)

Now I guess it's time for me to go back to finding out why the performance of stm32_fsdev is attrocious. Might be related to the fact that the data is copied around 3 or 4 times by the CPU, might be because double ...

fallow birchBOT
#

I realized that I couldn't push more than ~70KB/s of CDC data in a loopback on the same interface. I tried using the xfer_ff in the CDC so that one of the copies is avoided, but that didn't help at all. I really hope I won't have to get double buffering working.

That's really bad, I got more than 500KB/s in CDC OUT transfer with a G0B1, which makes me think double buffer is not necessary. Besides it's really a pain to manage double buffer in fsdev.

Let's continue in a discussion.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Describe the PR
The PR fixes two race conditions in the dcd_nrf5x driver. The first one fixes a function invocation from edpt_dma_start() which is called also from interrupt context, the second one (DI/EI) is required to protect a code section from interrupts.

Additional context
The actual problems (crashes/hangups) appeared during repeated connect / disconnect to a CDC-ACM on the nRF5x. The above changes fixed the situation.

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: add-name-usbd-class-driver
fallow birchBOT
#

Describe the PR
Due to the nature of quirk I'm not sure where to put...

This 1st OS detection quirk mainly resolve UAC class issue. Windows and OSX demand different feedback endpoint size for FS as Windows doesn't implement UAC spec correctly (Linux is compatible with both).
So there needs a way to adjust Configuration Descriptor on the fly.

#

@Marcus2060 @kf6gpe @rhysmorgan134

A quirk is come out which (hopefully) resolve UAC feedback format issue, test welcomed.

Now it's possible to use different Config descriptors:

uint8_t const desc_configuration_default[] =
{
    // Config number, interface count, string index, total length, attribute, power in mA
    TUD_CONFIG_DESCRIPTOR(1, ITF_NUM_TOTAL, 0, CONFIG_TOTAL_LEN, TUSB_DESC_CONFIG_ATT_REMOTE_WAKEUP, 500),
    // Interface number, Alternate count, starting string...
fallow birchBOT
#

Describe the PR
This MR provides a build configuration define that allows an application to prevent clearing of the CDC TX fifo buffer on port setup / reset.

This means that an application can write data to the CDC port before the USB is connected and available, eg logging data right from application startup. This buffered data will then be flushed down the CDC port on the next write or tud_cdc_write_flush(); after the CDC is connected.

Additional context
Related information...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

@rgrr could you please tell me more about how you tested this? Was there any OS used or is it bare metal configuration? Maybe you have some logs from USB analyzer that can be viewed to see exact sequence that triggered problems?

No, unfortunately I have no logs from a USB analyzer.

My testcase was a program under windows, USB nRF dongle connected to the PC with CDC-ACM in it. The dongle is more or less a gateway between a UART based packet protocol and BLE.

The test program basica...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: rework-ci
fallow birchBOT
fallow birchBOT
#

The application it self is mainloop based. The mainloop das the call to "tud_task()", everything else in the CDC-ACM handling is done via the callbacks. "proc_soc()" (some power handling of the nRF driver, part of the TinyUSB implementation) is also done from the mainloop.

The CDC handler itself use the regular callbacks.

So... no, I do no calls from interrupt context, everything is done from the mainloop.

fallow birchBOT
fallow birchBOT
#

Hi, I don't have those information. I'm using comtestserial to interact with the CDC port. I had success moving DSR with this function:


void set_dsr(uint8_t itf, bool value) {

    cdcd_interface_t* p_cdc = &_cdcd_itf[itf];

    uint8_t packet[10];

    packet[0] = 0xA1;                        //   bmRequestType
    packet[1] = CDC_NOTIF_SERIAL_STATE;                //   bNotification
    packet[2] = 0x00;                        //   wValue
    p...
fallow birchBOT
#

USB 2.0 specification:

 A bulk transfer is complete when the endpoint does one of the following:
โ€ข Has transferred exactly the amount of data expected
โ€ข Transfers a packet with a payload size less than wMaxPacketSize or transfers a zero-length packet
When a bulk transfer is complete, the Host Controller retires the current IRP and advances to the next IRP.
If a data payload is received that is larger than expected, all pending bulk IRPs for that endpoint will be
aborted/retired.
`...
fallow birchBOT
#

@rgrr First change where true is changed to is_in_isr() is reasonable and to me, and does fix locking issue where FIFO used for queue in osal_none.h can be clobbered when xfer started from non-interrupt context tries to add message without disabling USB interrupt then then fires.

The second part that blocks all interrupts for duration of two calls is not clear. It's not obvious why it should fix anything.
The only way I can see that it could fix problem is when dcd_edpt_xfer() is ca...

fallow birchBOT
#

Operating System

Windows 10

Board

STM32F723E-DISCO

Firmware

examples\device\webusb_serial

What happened ?

Receiver stopped working, seems ZLP caused error in console:

application.js:42 Uncaught (in promise) RangeError: Offset is outside the bounds of the DataView
    at DataView.prototype.getInt8 ()
    at port.onReceive (application.js:42:20)
    at serial.js:35:14
                        port.onReceive = data => {
                             ...
fallow birchBOT
fallow birchBOT
#

Related area

I would like to have tinyUSB support USB Host on ESP32-S3

Hardware specification

ESP32-S3

Is your feature request related to a problem?

I have USB MIDI Host working under esp-idf, but I need to port my project to Arduino, and TinyUSB does not yet support ESP32-S3 host.

Describe the solution you'd like

Add host support, and ideally a MIDI example :)

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issu...
fallow birchBOT
#
[hathach/tinyusb] New branch created: fix-cifuzz
fallow birchBOT
#
[hathach/tinyusb] New branch created: more-ci-tweak
fallow birchBOT
#
[hathach/tinyusb] New branch created: circleci-project-setup
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: ci-cache
fallow birchBOT
fallow birchBOT
#

@Marcus2060 @rhysmorgan134
I've setup up a Hackintosh Ventura and tested 3 bytes feedback (3 Bytes sent) && (MaxPacketBytes=3)and it works very well.
Zero click & pop during more than one hour listening:
image

So I'm curious about why it doesn't work in your cases.
Only thing I come up is when 4 bytes are sent 2ms is needed (3+1) instead of 1ms to finish one feedback transfer, maybe it makes O...

fallow birchBOT
#
fallow birchBOT
#

@HiFiPhile Seems you are right, setting my DMA buffers to 64 samples, 128bytes in my case, works fine with 3 bytes set in the transmit function and maxPacketBytes==3.

Are you using the tusb_config.h and descriptors from the example? If not would you mind sharing your ones you used for your test, would be nice for me to just sanity check mine.

Also did you run into any difficulties getting the python script running on OSX?

fallow birchBOT
#

Are you using the tusb_config.h and descriptors from the example

Yes they are from stack example, only difference is enable correction and set wMaxPacketSize=3:

diff --git a/examples/device/uac2_speaker_fb/src/tusb_config.h b/examples/device/uac2_speaker_fb/src/tusb_config.h
index 1cc1031c1..1a1cebca8 100644
--- a/examples/device/uac2_speaker_fb/src/tusb_config.h
+++ b/examples/device/uac2_speaker_fb/src/tusb_config.h
@@ -123,7 +123,7 @@ extern "C" {
 #define CFG_TUD_AUDI...
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: testing
fallow birchBOT
#

Related area

Pre-release

Hardware specification

All

Is your feature request related to a problem?

A testing branch has been added for anyone who wants to play with changes not yet upstreamed:

https://github.com/hathach/tinyusb/tree/testing

Not recommended for production use, forced pushes are expected.

Please leave me a message if you want your PR included.

It's easier than apply patches one by one, also interaction between multiples PRs can be teste...

fallow birchBOT
#
[hathach/tinyusb] New branch created: uac_quirk
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: ci-tweak3
fallow birchBOT
#

Describe the PR

  • enable --one-per-family to build 1 board per family, also skip family if board specified in -b also present
  • minimize ci run for push event
    • only build one board per family
    • skip hil test on both pi4 and hfp
  • full build will be runn for PR event
  • IAR always build 1 board per family regardless of event
  • update build.py to optimize make
  • remove all setup python since we don't really need it
fallow birchBOT
#
[hathach/tinyusb] New branch created: circi-clang
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Sorry, I need to revaluate this one.

The problems where this seemed helpful was to address an issue where the device stuck in the sleep mode. But the issue lied somewhere else. If a DCD_EVENT_BUS_RESET event occurs while on sleep (after tud_suspend_cb() was called) was the internal device state gets wiped but the application don't get informed to be awake nor to be in the unconfigured state again.

#

If a DCD_EVENT_BUS_RESET event occurs while on sleep (after tud_suspend_cb() was called) the internal device state gets wiped but the application don't get informed to be awake nor to be in the unconfigured state again. Not a single callback is triggered.

Do you have a test case ? I'll take a look.

I already gave one... ๐Ÿ˜ธ

Here another one... Like Only enable the device LED when the device is enumerated (tud_mount_cb() was called). Only let them on when the device is enumer...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

I can see where you coming from. Keep in mind that my comment has nothing to do with the usage and is only related to the code readability.

While it's being the same and because you are actually using the unequally operator in the expression for logical states, I don't really see an additional value in this comment. Meaning if I didn't knew what the expression would do the comment wouldn't help me at all. Providing a different view, like to mention that this is basically an expression wh...

fallow birchBOT
fallow birchBOT
#
  • The resume likely works while may MCU dependent. I don't think you can take for granted that every MCU triggers a resume first when a reset occur even that is likely or should be.
  • While a USB bus reset signal normally has a specific duration that is not true for every active USB hub. I have some which send a Single Ended Zero (SE0) continuously when no host is present on the up-facing port instead of having either just D+ or D- pulled up.
    • The DWC2 driver reacts to the start and end ...
fallow birchBOT
#

As mentioned please don't focus on the resume here, better check if tud_umount_cb() is called for a USB bus reset. You should also see that on the shown LED blink rate.

Yes we could do better for tud_umount_cb().

I mainly work with GD32 chips, especially GD32F303 and GD32F425.

That's what I asked for test case, instead of spamming half page.

These chips are not supported, if you need them please make a proper port and make these changes GD32 specific.

fallow birchBOT
#

Please be more precise and more detailed, especially about your questions! Then I didn't need to guess what you may mean. Sadly you even didn't get my point when I'm more detailed so I doubt it would help much if I would response the say way as you.

My complains aren't specific to GD32 chips per se, the DWC2 driver is universal anyway, the initial sleep issue here is likely unrelated and the GD32 chips are already ported.

fallow birchBOT
#

Operating System

Linux

Board

i.MX6SL

Firmware

Custom firmware based on tinyusb v0.16.0 and small changes to portable/chipidea/ci_hs to support i.MX6SL using MSC/CDC interfaces. Issue effects all builds which use EHCI.

What happened ?

The EHCI driver does not check that the requested transfer size (uint16_t, max value of 65535 bytes) does not exceed the limit for a single qTD, which is 16385-20480 bytes depending on the provided buffer's alignment (see section 3.5 of...

fallow birchBOT
#
[hathach/tinyusb] New branch created: max3421-abort-xfer
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: pr2362_rebased
fallow birchBOT
fallow birchBOT
#

What is your problem??? I wrote that I mainly work on GD32 chips. This doesn't mean that I don't have a board which uses this driver! For example I have a STM32F3DISCOVERY as a reference and back in the day I also encountered issues with that. But as I wrote I need to revaluate the need of this PR because due to the other fixes I added. As mentioned I don't mainly work with this chip which means I need to test it again which takes time.

fallow birchBOT
#

You seem like two very knowledgeable gentlemen. Perhaps you can answer my very simple questions and bring this conversation around in a more cordial direction.

I was interested in this pull-request because my STM32F042F6PX device is getting stuck in suspend. It only happens a few times per week and I haven't been able to capture the reason. This pull-request seemed like a good way try something new. And it almost worked. Or perhaps I'm imagining. It has only happened once since. The device...

fallow birchBOT
#

For example I have a STM32F3DISCOVERY as a reference and back in the day I also encountered issues with that.

It would be nice if you state STM32F3 is affected instead of direct to a unsupported chip plus a port.

@wronex Please provide more information, there could other reasons that device stops responding.

How is suspend communicated to the device? Is it a special packet? Is it a special signal voltage combination?

Devices can go into the Suspend state from any powered ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Describe the PR
This PR fills out the stubbed dcd_sof_enable() function for mimxrt, samd and renesas-ra ports.

Additional context
I'm working on a TinyUSB feature in micropython that uses SOF to provide some simple timing / delay shortly after connection of CDC: https://github.com/micropython/micropython/pull/14485

This also relates to https://github.com/hathach/tinyusb/discussions/2595 where it was found a delay is needed after CDC connection before sending / flushing TX data...

fallow birchBOT
#

@HiFiPhile
I don't know how many times is need to mention again that I need to revaluate it before I can say if it's affected or not. Without doing some (cross) checks I can't tell because at this point I don't know that anymore. I set this PR back as a draft and didn't close it for a reason. I had various issues with STM32F3 in the past. In the end a lot of my problems where related how usbd handles the events. But I also had issues where I think that these were related to the dcd_stm32_fs...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#

try it now, you should be able to push to my fork

Thank you, I have push the rebased to your fork. Though it isnt quite working, it keep stalling the get configuration. (stall is set with device qualifier previous, should be clear on setup). I may be due to recent chagnes on master, though it shows that this driver is partially working. I am doing more test and try to fix it if I could.

image

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: fork/pr2362
fallow birchBOT
#

could you please also add dcd_event_sof() to pass event to upper layer ?

Is this different? I noticed they already had something like this?
https://github.com/hathach/tinyusb/blob/ccc7a36043e055ded1f478a979a303e694123187/src/portable/chipidea/ci_hs/dcd_ci_hs.c#L682

My testing from within micropython is using the tud_sof_cb() function which is being called when it's enabled at least.

fallow birchBOT
fallow birchBOT
#

I am testing with cdc_msc stock example. yeah, setting bcdUSB to 2.0 with fullspeed will cause host to request device qualifier --> which tinyusb will stall as an not supported. I think the current driver didn't clear stall correctly. I will revise the driver and fix that later, I think we are getting closed to merge this. I will also cross-checking/cherry-pick with code in #1995 as well.

#

From stm32f0 errata sheet I found something suspicious:

ESOF interrupt timing desynchronized after resume signaling
Description
Upon signaling resume, the device is expected to allow full 3 ms of time to the host or hub for sending the
initial SOF (start of frame) packet, without triggering SUSP interrupt. However, the device only allows two full
milliseconds and unduly triggers SUSP interrupt if it receives the initial packet within the third millisecond.
Workaround
When the devi...
fallow birchBOT
fallow birchBOT
#

Really??? Still blaming and accusations... What is this place? I thought contribution would be welcome. I also do this here in my free time and bought the devices myself where I heard user have issues with.

I would very appreciate if you would just tell me the next time if you have trouble understanding me and in return I will ask you to rephrase the question in more detail manner instead of "spamming" in order to try to answer it in every possible way when that isn't clear to me.

The...

fallow birchBOT
#

Operating System

MacOS

Board

Feather nRF52840 Express

Firmware

examples/HID/hid_boot_keyboard

What happened ?

Building the hid_boot_keyboard sketch on nRF52 (tested with Feather nRF52840 Express, but I think ItsyBitsy nRF52840 has the same problem) with debug level 2 and debug port Serial1 (in the Arduino IDE Tools menu) causes an apparent deadlock during TinyUSB initialization.

My current debugging setup (Blackmagic Probe) doesn't have RTOS or threading support, s...

fallow birchBOT
#

Operating System

Linux

Board

CH32V307 (using both the SCDZ devboard and a custom board)

Firmware

Provided at https://github.com/PoroCYon/tinyusb-bug-repro --- both a CH32V307 version, and an RP2040 version which does functions correctly.

What happened ?

On the CH32V307, using DFU, the following effects may be observed:

  • The data buffer received by the DFU functions is 64 bytes off (can be in either direction)
    • This feels like a race condition thing, as it is very ...
fallow birchBOT
#

Operating System

MacOS

Board

Waveshare RP2040-Zero

Firmware

Custom firmware, representative sample that reproduces the issue at https://github.com/cbrunschen/tinyusb_rp2040_print_device_strings/ , with latest tinyusb as of the time of writing (

tinyusb% git status
On branch master
Your branch is up to date with 'origin/master'.

)

What happened ?

When I have multiple HID devices connected, and one of them is my Microsoft Sidewinder Force Feedback 2 joys...

fallow birchBOT
#

I should add that the Microsoft Sidewinder Force Feedback 2 is not the only device that triggers this behaviour, but it is the device that I have at home that does so, and was also the first device with which I encountered this behaviour.

The other context where I've observed this is when I've had connected, at the same time:

  1. Thrustmaster T.16000M joystick
  2. JustSoaring GliderSim Pro Joystick and pedals
  3. JustSoaring GliderSim ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

You might be correct that it's limited to the Arduino library.

However, upon investigating a bit more, it seems that tusb_hal_nrf_power_event calls TU_LOG from inside an ISR.

Is the tu_printf logging function expected to be ISR-safe? If so, it doesn't seem to be documented as a requirement.

The nRF52 Arduino core seems to have some issues with Serial1 being used from within an ISR.

Examining the state of the FreeRTOS task list suggests that it has gotten corrupted by turni...

#

Is the tu_printf logging function expected to be ISR-safe? If so, it doesn't seem to be documented as a requirement.
The nRF52 Arduino core seems to have some issues with Serial1 being used from within an ISR.

Yes it should be ISR safe, while documentation is a bit lacking...

Meanwhile even for built-in logging interrupt lock is also missing:
https://github.com/hathach/tinyusb/blob/ccc7a36043e055ded1f478a979a303e694123187/hw/bsp/board.c#L49

fallow birchBOT
fallow birchBOT
#

Operating System

Windows 10

Board

All

Firmware

All

What happened ?

Interrupt lock need to be added to log functions, Segger RTT print is not thread safe, calling from ISR could enter deadlock.
Serial logging could also be problematic depending implementation. #2649
https://github.com/hathach/tinyusb/blob/ccc7a36043e055ded1f478a979a303e694123187/hw/bsp/board.c#L51

2 options:

  • Remove all logging from ISR
  • Add interrupt lock, but macros need to be reworked since ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

I've added dcd_event_sof() for the 4 ports now covered in this PR. I think I've got the frame count reading correct but haven't had a chance to test any of these yet. I'll get these tested before calling this PR ready.

I haven't tested renesas changes at all yet as I'm chasing some support to get USB working at all on the renesas evk I've got.

The 4 ports covered at this point are the main ones I'm planning on adding at this time as these (mimx, samd, nrf, renesas) are the only ones I've...

fallow birchBOT
fallow birchBOT
#

I will also look at esp32s3 and esp32s2 are a separate issue, I do want that added too but in expecting some complications from IDF integration. If that's in fact trivial I'll add support for this platform too.

esp32 use dcd_dwc2 which already have sof support, it is little more complicate if you want to try:

# 1. Source ESP-IDF
# Windows
%userprofile%\esp\esp-idf\export.bat
# Linux
. $HOME/esp/esp-idf/export.sh
# 2. Enter example directory
cd tinyusb/examples/device/hid...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

hi hi, thank you everyone for contributing, we are all busy with other fulltime works and is working on this on our own free time without paid. The main reason for most of us is having fun and helping each other.

There is lots of stm32 clone: gd32, ch32 to name a few, they mixed cpu core and usb core and they also use their own usb core in additionn as well. It is nonrmal to assume they behave differently. Also, not everyone speak Enlighs natively, me as an example, I don't use English oft...

fallow birchBOT
fallow birchBOT
#

Thank you very much for your effort and patient. This works perfectly well with both my v203 and v307 dev board. I have update the linker for v20x to support different flash/ram size (by symdef __flash/ram_size), which should work better for more boards than default 64k/20k.

I also change the usbhs and usbfs driver a bit so that it is used correctly with CFG_TUD_MAX_SPEED since high-end ch32 such as v307 support both controller.

Note: v203 also support both usbfs and stm32 fsdev, but t...

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: update-circleci
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Thanks @HiFiPhile that's really interesting about the esp32sX driver! With that info I've been able to get a build of micropython working on the S3 that's using our existing tinyusb submodule and this driver directly, ignoring most of the esp32 usb implementation. It just took a little bit of extra support to manage switching from USB serial/jtag mode to USB OTG mode, but my test code for that seems to be working pretty well so far.
Being able to use the same shared tinyunb intergration code...

fallow birchBOT
fallow birchBOT
#

Operating System

Linux

Board

Custom STM32H7 based board

Firmware

class/net/ncm_device.c

What happened ?

When using CFG_TUD_MEM_SECTION I get a section conflict. This is because ntb_parameters is constant, while transmit_ntb isn't. See https://stackoverflow.com/questions/30076949/gcc-error-variable-causes-a-section-type-conflict

This could be fixed by adding two configuration values: CFG_TUD_RODATA_MEM_SECTION and CFG_TUD_BSS_MEM_SECTION and then replace all u...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: fsdev-generalize-ch32
#

Describe the PR
This mainly add support for ch32 to stm32 fsdev driver. Also change dcd_disconnect/connect to default implemenation (instead of weak = 0)

CH32 often has multiple usb controller: fsdev, usbfs, usbhfs. By default:

  • v20x use fsdev since it is available in all variants, usbfs is optional on some
  • v307 use usbhs

these can be manually selected accordinly by defining macros in tusb_config.h or via CFLAGS

  • CFG_TUD_WCH_USBIP_FSDEV = 1
  • CFG_TUD_WCH_USBIP_USBFS = 1
    -...
fallow birchBOT
#

Operating System

Windows 11

Board

MIMXRT11XX

Firmware

My project use the tinyusb repository a068b81674e8b47d6fb78ab6a06abb7decc2e644, refer to examples/device/net_lwip_webserver.

What happened ?

NCM enable: PC(win11) can detect the driver named TinyUSB Network Interface, with event device(UsbNcm) not start, problem status 0xC00000E5. Can't ping the board and can't open the web.
ECM_RNDIS enable: Everything is ok, I can open the default web.

How to reproduce ?

In...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Thanks for your SOF frame count fix, I've also now finished adding dcd_event_sof() for each of the ports I'm targeting here.

I've been able to test all of them and have confirmed the frame counts are passed through as expected.

In case it helps, the code in using sof interrupt for plus the test printf to confirm SOF frame count is here: https://github.com/andrewleech/micropython/blob/54e0abf5d15441ad7a2a9d8058e45c6f8e193f68/shared/tinyusb/mp_usbd_cdc.c#L124

fallow birchBOT
#

Hmmm... @electretmike : which NCM are you using? The old one or the recent one? Recent one has my name in the copyright (Hardy Griech).

If you are at the current one: all this section stuff was already in the original NCM driver (without looking for excuses). Thought it would be wise to not touch that part.

How is CFG_TUD_MEM_SECTION defined for your part? Perhaps this definition is simply wrong?

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: tweak-espidf-include
fallow birchBOT
#

I have tested CFG_TUD_NCM_IN_NTB_MAX_SIZE/CFG_TUD_NCM_OUT_NTB_MAX_SIZE 3200, but not work.
Something may be important. CFG_TUD_NCM_IN_MAX_DATAGRAMS_PER_NTB/CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB default 8/6, and CFG_TUD_NCM_OUT_NTB_N/CFG_TUD_NCM_IN_NTB_N also set to 8/6, that can work. But when I pin the board, the first 6 counts pin will have lot delay ms.

fallow birchBOT
#

I have tested CFG_TUD_NCM_IN_NTB_MAX_SIZE/CFG_TUD_NCM_OUT_NTB_MAX_SIZE 3200, but not work.

Please set those values to "(2 * TCP_MSS + 100)" and try again.

Something may be important. CFG_TUD_NCM_IN_MAX_DATAGRAMS_PER_NTB/CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB default 8/6,

ok

and CFG_TUD_NCM_OUT_NTB_N/CFG_TUD_NCM_IN_NTB_N also set to 8/6, that can work.

Thats a lot of buffers. Set those to 2/2

But when I pin the board, the first 6 counts pin will have lot delay ms.
...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

@kkitayam PTAL! If you need any examples, I will provide them to you ASAP

Sorry for late response. And, thank you for your suggestion. Could you share the example for this PR? I will try the example.

Please try example with https://github.com/lijunru-hub/esp-iot-solution/tree/feat/usb_uvc_support_h265_trans/examples/usb/device/usb_dual_uvc_device.

You need to set up the ESP-IDF environment and use an ESP32S2/3 development board to flash this project. Please change the format ...

fallow birchBOT
fallow birchBOT
#

Operating System

Windows 10

Board

Custom Board

Firmware

This is a custom firmware (compiled using STM32CubeIDE, Version: 1.13.2, Build: 18220_20230914_1601 (UTC)), that I am sharing as a ZIP file.
poc_tinyusb.zip

What happened ?

After the Firmware is flashed, when you connect the device to the Windows 10 host, each time the device seems enumerated, a USB bus reset is sent by the host.

How to r...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#

increase freertos stack size", are you talking about the IDLE task?

Not the idle task, but USB task where TUSB is running.

The USB Bus reset is not due to a crash

I'm talking about

USBD init on controller 0, Highspeed = 0
sizeof(usbd_device_t) = 45
sizeof(dcd_event_t) = 12
sizeof(tu_fifo_t) = 12
sizeof(tu_edpt_stream_t) = 24
``
which came only from `tusb_init()` which should only be called once in MCU init. So you are facing a crashing issue or usage fault 
as they a...
fallow birchBOT
#

Operating System

Windows 11

Board

LPC55S28

Firmware

For the tests, we used the following examples found in the tiny-USB examples folder in the device section:

  • hid_composite_freertos
  • hid_generic_inout

What happened ?

We were interested in testing the HID+RTOS feature for the LPC55S28 board. To do this, we first used the latest version of tiny-USB (SHA: d10b65ada4be7d5754b3128e80a9b4db72bdb23f), ran the hid_composite_freertos example and had the following results...

fallow birchBOT
#

There are 2 issues:

  1. FreeRTOS not supported by BSP:

In tinyusb/hw/bsp/lpc55/family.c you can try to replace SysTick_Config(SystemCoreClock / 1000); with

#if CFG_TUSB_OS == OPT_OS_NONE
  // 1ms tick timer
  SysTick_Config(SystemCoreClock / 1000);

#elif CFG_TUSB_OS == OPT_OS_FREERTOS

  // If freeRTOS is used, IRQ priority is limit by max syscall ( smaller is higher )
  NVIC_SetPriority(USB0_IRQn, configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY );
  NVIC_SetPriority(USB1...
fallow birchBOT
#
[hathach/tinyusb] New branch created: add-c6-board
fallow birchBOT
fallow birchBOT
#

Such as

void ecm_close(void)
{
  printf("Ecm close\n");
  tusb_control_request_t notify_data =
  {
    .bmRequestType = 0xA1,
    .bRequest = 0 /* NETWORK_CONNECTION aka NetworkConnection */,
    .wValue = 0 /* Disconnected */,
    .wLength = 0,
  };
  notify_data.wIndex = _netd_itf.itf_num;
  netd_report((uint8_t *)&notify_data, sizeof(notify_data));
}

void ecm_open(void)
{
  printf("Ecm OPEN\n");
  tusb_control_request_t notify_data =
  {
    .bmRequestType = 0xA1...
fallow birchBOT
fallow birchBOT
#

Options:

  • Remove all logging from ISR.
  • Defer ISR logging, should be difficult with va_args.

I think these two options are best.

In my own embedded code, if I really need to log in an IRQ, I use two custom functions that log either a single string or a string with a number, and these fonctions (1) don't use libc and (2) work "optimistically", (i.e. only if there is room in the output buffer). I think a general solution is difficult.

Also I don't think this is a real...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

So sorry i missed this discussion somehow!

I'm using clang + llvm cross compiling for x86 type embedded system with OHCI backend.

recently I switch to use weak as the default implementation of callback to be compatible with keil https://github.com/hathach/tinyusb/pull/2239

^ Yep this does the trick for me. I was having problems with the OHCI tusb_app_virt_to_phys/tusb_app_phys_to_virt weak functions.

So I just need this patch and implement weak stub functions.

+++ b/src/...
fallow birchBOT
#

Operating System

Windows 11

Board

N/A

Firmware

N/A

What happened ?

Ref USB Spec 9.2.6.3

In the case of the SetAddress() request, the Status stage successfully completes when the device sends the zero-length Status packet or when the device sees the ACK in response to the Status stage data packet.
After successful completion of the Status stage, the device is allowed a SetAddress() recovery interval of 2 ms

I have a device (HID game controller) that will STALL...

fallow birchBOT
#
[hathach/tinyusb] New branch created: add-ch32v103
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Related area

src/portable/st/stm32_fsdev/dcd_stm32_fsdev.c

Hardware specification

stm32h7

Is your feature request related to a problem?

Used tinyUSB on the STM32H7 platform

Describe the solution you'd like

Used tinyUSB on the STM32H7 platform

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, dicussion and documentation.
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

though I think printf lock should be done in user space by implementing (nano)libc lock in _write_r(). Since not all retarget needs lock e.g. segger rtt

The problem is libc's printf() itself is not reentrant as it works on global data, not just the I/O part.

https://github.com/bminor/newlib/blob/1ed15161362b2eb5649b049b7ab0aaf8097bd43a/newlib/libc/stdio/printf.c#L52

I may miss a thing though: the newlib reentrant implementation seems to the the exact same thing as this....

#

this is interesting, I overlook the specs on this. Blindly wait for 2 seconds isn't good though, would your device still response after a few seconds after stalled response ? I am thinking we can allow the control transfer to retry up to 3 seconds right after SET_ADDRESS e.g. increase the delay to 1000 ms if the first descritptor isn't retrieved after addressed https://github.com/hathach/tinyusb/blob/master/src/host/usbh.c#L1314 ?

fallow birchBOT
#

Eh... I think reentrant is kind of implementation dependent, I just read IAR's manual:

Most parts of the DLIB runtime environment are reentrant, but the following functions
and parts are not reentrant because they need static data:
Heap functionsโ€”malloc, free, realloc, calloc, etc. and the C++ operators new and delete
...
Functions that use files or the heap in some way. This includes scanf, sscanf, getchar, getwchar,
putchar, and putwchar. In addition, if you are using the optio...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: add-host-devinfo
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

you could use the already defined tu_static struct ncm_notify_t ncm_notify_connected to implement these functions, right?

Wouldn't it also make sense to define the startup behavior? Currently it just automatically is connected. That is a good default behavior. But in a scenario where the firmware wants to change the connected state it might also want to start out in disconnected state, right?

fallow birchBOT
#

Describe the PR
Will close https://github.com/hathach/tinyusb/issues/2673

Additional context
Ref USB Spec 9.2.6.3
After successful completion of the Status stage, the device is allowed a SetAddress() recovery interval of
2 ms. At the end of this interval, the device must be able to accept Setup packets addressed to the new
address. Also, at the end of the recovery interval, the device must not respond to tokens sent to the old
address (unless, of course, the old and new addre...

fallow birchBOT
#

Related area

Usb Host raw api CFG_TUH_API_EDPT_XFER

Hardware specification

OHCI

Is your feature request related to a problem?

Im using the raw api with an RTOS and CFG_TUH_API_EDPT_XFER enabled and this is probably the simplest example

const uint8_t my_dev_addr = 0x01;

void my_transfer_cb (tuh_xfer_t *transfer)
{
    osal_semaphore_t *semaphore = (osal_semaphore_t *)transfer->user_data;
    osal_semaphore_post(*semaphore, false);
}

void readpipe(osal_semap...
fallow birchBOT
#

Describe the PR
When compiling the synopsys/dwc2 for ESP32-S2 I found it to fail using IDF v5.0.4 with:

In file included from /tinyusb/src/portable/synopsys/dwc2/dcd_dwc2.c:47:
/tinyusb/src/portable/synopsys/dwc2/dwc2_esp32.h: In function 'dwc2_remote_wakeup_delay':
/tinyusb/src/portable/synopsys/dwc2/dwc2_esp32.h:71:3: error: implicit declaration of function 'vTaskDelay' [-Werror=implicit-function-declaration]
   71 |   vTaskDelay(pdMS_TO_TICKS(1));
      |   ^~~~~~~~~~
cc1...
fallow birchBOT
#

Operating System

Others

Board

Pi Pico / RP2040

Firmware

None

What happened ?

Compiling with
#define CFG_TUH_VENDOR 1
fails with
vendor_host.h:37:3: error: unknown type name 'pipe_handle_t'
and many errors more ...

It seems the vendor class driver has been discontinued as half of the types, constants and functions being used don't exist (anymore?).

How to reproduce ?

Just enable TUH_VENDOR

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

#

Related area

Allow developers to provide custom class drivers

Hardware specification

all

Is your feature request related to a problem?

I'd like to add xbox controller support to the tuh. The xbox controllers are vendor specific and the vendor class driver seems broken: https://github.com/hathach/tinyusb/issues/2684

Describe the solution you'd like

Allowing to add custom class drivers to usbh_class_drivers[] in usbh.c would allow custom class drivers without the need t...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

#2576 changed the interrupt flow, although L475 doesn't have DMA but worth a try.

I have tested this change on an L476, this does not seem to fix the issue described

image
After Queue EP 00 with 7 bytes ..., the flow stops, it waits for the event and after around 30 seconds a new event is received and it continues without having handled those bytes. I have also checked that the 7 requested ...

fallow birchBOT
#

Operating System

Windows 11

Board

OHCI

Firmware

class/hid_host/c
portable/ohci/ohci.c

What happened ?

After random lengths of time OHCI transfers will not fire the completion interrupt. I traced this to garbage being in hcca.done_head.

The garbage was similar to the address of the TD but was partically corrupt or missing. The root cause was writing to td_head directly here

I can see exactly why we are doing this; which to prevent having to allocate dummy TDs f...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Operating System

Linux

Board

STM32H563 Nucleo

Firmware

custom

What happened ?

These lines issue a warning/error when strictly following the ISO C standard before 23
https://github.com/hathach/tinyusb/blob/756ad3553d095b69cf3276e3967381eba958232e/src/class/audio/audio.h#L492
https://github.com/hathach/tinyusb/blob/756ad3553d095b69cf3276e3967381eba958232e/src/class/audio/audio.h#L643s

How to reproduce ?

built with `gcc -Wfatal-errors -Wall -Wextra -Wpedantic -std=...

fallow birchBOT
#

Operating System

Linux

Board

Custom

Firmware

custom firmware

What happened ?

when the function tud_task() is called, it will in its turn call tud_task_ext(UINT32_MAX, false). The problem with this is that if there are no more messages in the freertos queue, the timeout value of UINT32_MAX is like stay here forever.. and system hangs. I think the value of timeout could be set to 0 to immediatly return if there is no data available in the queue.

How to reproduce ?

...

fallow birchBOT
#

works fine. Also tested with

/**
 * build with
 * gcc -Wfatal-errors -Wall -Wextra -Wpedantic -std=c11
 */

#include <stdio.h>
#include <stdint.h>

#define BYTE_TO_BINARY_PATTERN "%c%c%c%c%c%c%c%c"
#define BYTE_TO_BINARY(byte)  \
  ((byte) & 0x80 ? '1' : '0'), \
  ((byte) & 0x40 ? '1' : '0'), \
  ((byte) & 0x20 ? '1' : '0'), \
  ((byte) & 0x10 ? '1' : '0'), \
  ((byte) & 0x08 ? '1' : '0'), \
  ((byte) & 0x04 ? '1' : '0'), \
  ((byte) & 0x02 ? '1' : '0'), \
  ((byte) & 0...
fallow birchBOT
fallow birchBOT
#

Describe the PR
Issue #1018 resolved the usage of TU_ATTR_WEAK for the Keil compiler when it comes to function dcd_edpt0_status_complete().

Unfortunately, the same problem (the USB device not enumerating properly) occurs again, if the USB device makes use of a BOS descriptor. For example when using a Microsoft OS 2.0 platform capability descriptor to set a specific Device Interface GUID for WinUSB.

In this case the problem is caused by the tud_descriptor_bos_cb() and `tud_vend...

fallow birchBOT
#

Related area

New port support

Hardware specification

RZ/T2M-RSK

Is your feature request related to a problem?

I want to use the TinyUSB stack for both device and HOST functionality. I have ported the USB device driver to TinyUSB and have been having issues with the USB host driver which uses OHCI/EHCI. I tried using the existing OHCI/EHCI support in TinyUSB and modifying it for the RZT2M based on the Renesas FSP reference code and have not been able to.

Describe the ...

fallow birchBOT
#

Related area

hardcoded declaration

Hardware specification

rp2040

Is your feature request related to a problem?

I wish to reduce some noise in the rp2040's binary info, as reported by picotool. For example, I have a project where the LED on pin 25 of my Pico has a specific informational function, and I add the custom bi_decl describing that function. In this case, picotool reports LED, LED CUSTOM LABEL for pin 25, when it would be more helpful to only report `LED CUSTOM ...

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: revert-2693-enum-int
fallow birchBOT
#

Operating System

Others

Board

Raspberry Pi Pico WH

Firmware

HID device example

What happened ?

tud_umount_cb is never called after calling tud_disconnect though if you call tud_connect then tud_mount_cb is called as expected.

How to reproduce ?

TODO

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

TODO

Screenshots

No response

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, dicussio...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Related area

CDC Transfer Speed

Hardware specification

imxrt

Is your feature request related to a problem?

Hi, we currently use TinyUSB on the IMXRT for USB CDC.

One of the things I noticed with our USB sniffer with USB HS is that many packets are NACKed.

image

In the example above, each 1-2 poll is a NACK. This is wasting USB bandwidth. Ideally, we'd want to have the data read...

fallow birchBOT
#

Describe the PR
Add support for the Analog Devices MCUs MAX32650/1/2, MAX32665/6, MAX32690 and MAX78002.

Additional context
The USB IP for these devices is identical amongst the part families and uses a variation of the Mentor IP core. dcd_musb.c was used as the baseline implementation, modified for the part specific FIFO, register access and PHY control.

Supported Boards:

  • MAX32650EVKIT
  • MAX32650FTHR
  • MAX32651EVKIT
  • MAX32666EVKIT
  • MAX32666FTHR
  • MAX32690EV...
cold owl
#

Hi, I just received my Adafruit Feather RP2040 with USB HOST but unfortunately the following example does not work:
https://github.com/adafruit/Adafruit_TinyUSB_Arduino/tree/master/examples/DualRole/CDC/serial_host_bridge
SerialHost returns always false. I'm testing with Arduino IDE 2.3.2 & Adafruit TinyUSB 3.3.1. I'm sure the usb device connected is acting correctly.
Any ideas?

GitHub

Arduino library for TinyUSB. Contribute to adafruit/Adafruit_TinyUSB_Arduino development by creating an account on GitHub.

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: add-tud_cdc_configure_fifo
fallow birchBOT
#

Thanks @hathach. As part of that potential merging of the existing dcd_msub.c with my updates, should probably also look at the sunxi version as well. The scope of modifications for that were similar to mine.

Unfortunate about the back order. Once you get hardware reach out if you have any questions or issues getting up and running.

yeah, sunxi uses the same mentor usb, but it is more complicated since it is actually arm9 processor. I want to do that also but couldn't mannage the ...

fallow birchBOT
#
[hathach/tinyusb] New branch created: dwc2-test-mode-followup
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

I think the current situation on reception handling is confusing and probably wrong. tud_network_recv_renew seems to be called twice in a single packet reception, the first time by tud_network_recv_renew_r which is in turn called by netd_xfer_cb, and another time by user logic when it finished processing the current packet. This also means recv_try_to_start_new_reception is called twice in a single reception.

fallow birchBOT
#

OK, I understand that we may process multiple NCM "subpackets" in one callback, and that's why we need to repeatedly call tud_network_recv_renew.

So, I propose a solution to this issue to add re-entrance detection logic to tud_network_recv_renew function.

void tud_network_recv_renew(void) {
  TU_LOG_DRV("tud_network_recv_renew()\n");

  static bool processing = false;
  static bool should_process = false;

  should_process = true;
  if (processing) {
    TU_LOG_DRV("Re...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

ok... understood. Good point. Loop above seems to be too complicated for my eyes. Is something like this working:

void tud_network_recv_renew(void) {
  TU_LOG_DRV("tud_network_recv_renew()\n");

  static bool should_process = false;    // should go into ncm_interface_t

  if (should_process) {
    TU_LOG_DRV("Re-entrant into tud_network_recv_renew, will process later\n");
    return;
  }
  should_process = true;

  while (should_process) {
    should_process = false;
...
#

Hmmm... you are right (perhaps I need some time to rethink it ;-))

Perhaps a simple semaphore could do?:

void tud_network_recv_renew(void) {
  static bool sema = false;

  if ( !sema) {
    sema = true;

    TU_LOG_DRV("tud_network_recv_renew()\n");

    recv_transfer_datagram_to_glue_logic();
    sema = false;
  }
  recv_try_to_start_new_reception(ncm_interface.rhport);
} // tud_network_recv_renew
#

This will not work when there are 3 ntbs handled in one call to netd_xfer_cb.

I think either a loop or recursion is needed in case tud_network_recv_renew is called directly within tud_network_recv_cb. One call to recv_transfer_datagram_to_glue_logic only process on ntb. As we need to process multiple ntbs, it's obvious that multiple calls to recv_transfer_datagram_to_glue_logic is needed. We don't want recursions (because that might cause stack overflow on MCUs), so this me...

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: migrate-hil-pi5
fallow birchBOT
fallow birchBOT
#

Related area

host class driver

Hardware specification

rp2040

Is your feature request related to a problem?

Currently USBTMC class is implemented for device but not host.

Describe the solution you'd like

Be able to use USBTMC as a host

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, dicussion and documentation.
fallow birchBOT
#
[hathach/tinyusb] New branch created: more-hil-pi5
fallow birchBOT
#
[hathach/tinyusb] New branch created: hid-2253-followup
fallow birchBOT
#
[hathach/tinyusb] New branch created: add-family-da1469x
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: hild-add-metro-m7
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: fix-hil-boardtest
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: hil-add-ra4m1
fallow birchBOT
#

thank you, I made some changes, this may not fully address a race, but should make it better (need follow up PR with usb reset later)

  • rebased
  • revert changes to usbd, we will deal with usbreset in interrupt in a separated PR
  • set cfg_num in usbd before calling driver's open(), there is no reason not to do so.
  • also added tud_cdc_n_ready() but not used in this PR.
#

I don't know, this is not really stable. These things can change, and it is not a good idea to give any suggestion if we aren't sure. I guess we can leave this as is for now until there is better approach.

Note: if the order of descriptors can be used to determinne the OS, this can be done by application since these callback are executed in application space. User can keep track of the order and do the guess by themself.

fallow birchBOT
#
[hathach/tinyusb] New branch created: hil-add-lpc11u377
fallow birchBOT
fallow birchBOT
#

Updated: requested by @tannewt, I did a bit more search and found mouser having these in stocks, just ordered max32650,666,690 boards (sponsored by Adafruit). It will probaly take a week or so for it to get delivery. Meanwhile @BrentK-ADI If possible, you can try to merge the dcd_max32 to dcd_musb, probably create an header musb_max32.h and abstract/put max32 specific function there. you could check out dwc2 for ref...

fallow birchBOT
#

I agree it's not stable and could break in the future.

But facing the UAC OS compatibility issue I can't come up a better way, at least it will calm down the issue for a moment.

I can move the quirk to application space of uac2_speaker_fb example in #2328 , but since callbacks are separated functions the quirk will become clustered and harder to understand.

fallow birchBOT
#

Description

This pull request addresses an issue in the MAX3421 driver where NAK responses from the device were not handled correctly. The MAX3421 has 2x SNDFIFO of 64 bytes. If an OUT transfer receives a NAK response, the current implementation fills the FIFO again and writes to the SNDBC register, which switches to the other FIFO area and causes the earlier FIFO space to become stale. After writing to the HXFR register on the second try, the SIE will send the FIFO filled in the first a...

fallow birchBOT
fallow birchBOT
#

@earlephilhower yeah, thank you for your feedback. You are rigtht, this is my thought as well initially. However, since it copy to/from a dual port USB RAM, it may have some extra hw limit, we have seen this in other ports e.g https://github.com/hathach/tinyusb/pull/1024, though that is a bit different since MCU is M4 and able to do unaligned access (hence memcpy is implemented in such as way), however the usb ram is limited to byte/aligned access only which could cause issue.

For this PR,...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#

I dont understand is if the tud_task is blocking, it is consuming all cpu right??

No, the task will enter blocking state when eveet list is empty, to give CPU resource to other tasks.

You can read more about RTOS https://www.digikey.com/en/maker/projects/introduction-to-rtos-solution-to-part-3-task-scheduling/8fbb9e0b0eed4279a2dd698f02ce125f

#

Operating System

Windows 11

Board

stm32g0b1ret6

Firmware

/*
 * The MIT License (MIT)
 *
 * Copyright (c) 2019 Ha Thach (tinyusb.org)
 *
 * Permission is hereby granted, free of charge, to any person obtaining a copy
 * of this software and associated documentation files (the "Software"), to deal
 * in the Software without restriction, including without limitation the rights
 * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 * copies of...
fallow birchBOT
#
[hathach/tinyusb] New branch created: hil-change-esp32s3-baudrate
#

Describe the PR
lower flashing baudrate for hil s3, since it seems to have stable issue with pi5 + cp2102

[378571.099339] usb 1-2.1.2: device descriptor read/8, error -71
[378571.234364] usb 1-2.1.2: device descriptor read/8, error -71
[378571.345366] usb 1-2.1-port2: unable to enumerate USB device
[378571.942508] cp210x ttyUSB0: failed to get comm status: -71
[378571.944417] cp210x ttyUSB0: failed set request 0x7 status: -71
[378571.946412] cp210x ttyUSB0: failed set request 0x12 s...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

Operating System

Linux

Board

RPI Pico

Firmware

tinyusb/src/class/usbtmc/usbtmc_device.c
tinyusb/examples/device/usbtmc/src/usbtmc_app.c

What happened ?

PR #2494 introduced tud_usbtmc_transmit_notification_data() function. The check if EP is not busy bails out of the function if the EP is NOT busy:

https://github.com/hathach/tinyusb/blob/cfbdc44a8d099240ad5ef208bd639487c2f28153/src/class/usbtmc/usbtmc_device.c#L256

I believe it should be the opposite; bail if th...

fallow birchBOT
fallow birchBOT
#

Related area

tusb_fifo

Hardware specification

STM32H563

Is your feature request related to a problem?

I would like to use tud_audio_write() and tud_audio_read() from ISR when RTOS support is enabled (I am using FreeRTOS).
If you call it from ISR you end up with an issue in the mutex [1] since you need to use specific ISR aware functions.

[1] https://github.com/hathach/tinyusb/blob/cfbdc44a8d099240ad5ef208bd639487c2f28153/src/common/tusb_fifo.c#L474

Describe the sol...

fallow birchBOT
#

@hathach, I took a shot at combining the existing DCD MUSB with the new MAX32. Things were a little trickier than the dwc2 example, for a couple reasons:

  • The EP registers are the same packing/data types, but accessed differently between TI and MAX32. TI has a contiguous memory map where each EP register set follows the previous. MAX32 uses a shared memory space and an index to determine which EP is being accessed
  • The FIFOs on the TI parts need to be configured, where as the MAX32 h...
fallow birchBOT
#
[hathach/tinyusb] New branch created: enhance-fsdev
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: header_fix
#

Operating System

Windows 11

Board

STM32F7

Firmware

examples/device/audio-4-channel-mic

What happened ?

If I increase the sample rate to 96000 in the config.h, I don't get proper values, only something like noise. What could be the cause of this?

How to reproduce ?

/

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

/

Screenshots

No response

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, di...
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: hil-change
fallow birchBOT
#
[hathach/tinyusb] New branch created: fix-ch32v203-setup
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

After calling tud_disconnect() it is not possible to restart connection with tud_init(). The reason is that global flag _usbd_rhport remains in valid state and function tud_init() returns on lines:

// skip if already initialized
if ( tud_inited() ) return true

The solution is to modify 'tud_disconnect()', as below:

bool tud_disconnect(void)
{
  TU_VERIFY(dcd_disconnect);
  dcd_disconnect(_usbd_rhport);
  _usbd_rhport = RHPORT_INVALID;
  return true;
}
fallow birchBOT
#

Sorry for warming this up, this was an interesting read.

We currently have some issues with MacOS, where the kernel complains about "babble" error on the feedback endpoint of our UAC2.0 device.
We use the default setting, i.e. 16.16 format and 4 bytes MaxPacketSize, bcdUSB set to 0200.

Did anybody else notice a problem like this on MacOS? See the log in our issue here https://github.com/skuep/AIOC/issues/13#issuecomment-2267946297

Is it possible that (for some reason) MacOS now want...

#

Sorry for warming this up, this was an interesting read.

We currently have some issues with MacOS, where the kernel complains about "babble" error on the feedback endpoint of our UAC2.0 device. We use the default setting, i.e. 16.16 format and 4 bytes MaxPacketSize, bcdUSB set to 0200.

Did anybody else notice a problem like this on MacOS? See the log in our issue here skuep/AIOC#13 (comment)

Is it possib...

fallow birchBOT
fallow birchBOT
#

Nice work @HiFiPhile !
Regarding the OS guessing, I have done some work regarding Windows WCID in the past which could theoretically be used for accurately detecting windows (7 and up I Believe). See
https://github.com/pbatard/libwdi/wiki/WCID-Devices#user-content-Microsoft_OS_String_Descriptor

But I am not sure if the Descriptor is requested before the configuration Descriptor. Because I think it needs to change the maxPackstSize for the feedback endpoint, correct?

fallow birchBOT
#

But I am not sure if the Descriptor is requested before the configuration Descriptor. Because I think it needs to change the maxPackstSize for the feedback endpoint, correct?

Yes the detection should be done before configuration descriptor request, that's why I put Windows' descriptor as default. I think 0xEE is requested in the same order as MsOS 2.0 descriptor.

Other than that we could force renumeration by disconnecting and connecting the USB device virtually ๐Ÿคฃ EDIT: LOL of cours...

fallow birchBOT
#

superb !! Thank you very much @mabembedded for your effort ๐Ÿ‘ . Eveen though I really want to, but unfortunately, I was a bit busy at the moment to follow up with Zephyr. I will try to catch up with you guys later.

hey are you little free now? i would really like esp32s3 to have usb-otg support in zephyr

fallow birchBOT
#

Operating System

Windows 11

Board

STM32F103C8T6 Blue Pill

Firmware

examples/device/cdc_msc

What happened ?

When put the USB to the host, USB Mass Storage device appears. But it refreshes few times, then marked error.

As shown in the log output below, there are always 6 times MSC Inquery requests. And it always immediately triggers the USBD Bus Reset.

Device Manager's Bus reported device description shows the correct desciption.

How to reproduce ?

No OS...

fallow birchBOT
#

Operating System

Linux

Board

STM32H563

Firmware

custom build

What happened ?

after c60934eedcc363f320cb66695f0034312094bfd8 tud_audio_read() returns only half of the requested bytes.
reverting the merge it returns the right bytes.
I read the commits but nothing obvious to me was found.

How to reproduce ?

uint16_t audio_read_bytes = tud_audio_read(&audio_buffer[0U], AUDIO_BLOCK_SIZE * sizeof(int16_t));

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

[tinyusb...

fallow birchBOT
#

Well, I checked out to the fix-ch32v203-setup and builded it, now it seems to be fail at the earlier stage of the initialization.

Now Device Manager shows Unknown USB Device (Device descriptor request failed), and TinyUSB log output is way shorter:

<details>

<summary>log output</summary>

[22:18:25.356] tio v2.7
[22:18:25.357] Press ctrl-t q to quit
[22:18:25.402] Connected
USBD init on controller 0, Highspeed = 0
sizeof(usbd_device_t) = 52
sizeof(dcd_event_t) = 12
s...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: update-ci-toolchain
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: update-pio-usb
fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: hil-readd-v203
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

thank @ra1nb0w and @HiFiPhile, sorry I indeeded didn't tested the ISO since I am still not familliar with audio yet. I mostly tested other examples running hil_test.py locally (also added an g0 (32-bit 2048 KB), f0 (1KB), ch32 (512B) to my hil pool to make sure my rework does not break things.

which example you are testing with ? I can use analyzer to capture but can you help a bit to write a python the script to read its payload count, that would make thing easier/faster. Will try to fix...

#

@hathach
For H5 the fix is simple, just a buf_id thing.
https://github.com/HiFiPhile/tinyusb/tree/fsdev_iso_fix

which example you are testing with ? I can use analyzer to capture but can you help a bit to write a python the script to read its payload count, that would make thing easier/faster

It's the audio_4_channel_mic example, since the data is a stream it is a little tricky to validate the output with a script, but if you run plot_audio_samples.py and a get a clean output (...

fallow birchBOT
fallow birchBOT
#
[hathach/tinyusb] New branch created: fsdev_iso_fix
fallow birchBOT
fallow birchBOT
#

Yeah, it is like 7 or 8 boards. Though some like metro m7 1011 does not play when with others when doing parallel testing (maybe power issue or something). I also got of usb bus funny problems but get them more stable now. I will try to add a few more, currently occupied all 3x7 usb hub.

I starts to do local testing with these locally while developing since it is rather convenient:)

fallow birchBOT
fallow birchBOT
#

Operating System

Windows 11

Board

CH32V203K8T6 without evaluation kit

Firmware

Sorry, it's a Platform.io project.
https://github.com/SEED264/ch32v203_tinyusb_hid_test

What happened ?

When creating an HID with CH32V203 and sending a report of random numbers as a test, a HardFault will occur after as little as a few seconds, or as long as a few tens of minutes.
The call stack is often displayed as shown below, but sometimes only up to tud_task is displayed, or the call ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#

@BrentK-ADI Everything went smoothly, I push more refactor to generalize register interfacee. I also tried to include max32650 to my hardware-in-the-loop pool https://github.com/hathach/tinyusb/issues/2194. Though it is self-hosted running on a Raspberry Pi (aarch64), so I tried to compile openocd (analog fork) https://github.com/analogdevicesinc/openocd so that PI can flash the board (using max32625pico) and run test each PR push. But got following compiled error on my Linux x86.

/u...
fallow birchBOT
#

@hathach As far as I know that is the right repo. I believe it should be the release branch vs adi-main or master. I was able to build that branch with the normal OpenOCD instructions:

To build OpenOCD, use the following sequence of commands:

  ./bootstrap (when building from the git repository)
  ./configure [options]
  make
  sudo make install

If that's still causing you problems, I'll ping the group that maintains the tools for these MCUs on Monday and get more gui...

fallow birchBOT
fallow birchBOT