Not a problem, thank you for fixing it up and merging!
#tinyusb
1 messages ยท Page 6 of 1
I'm thinking about set configuration request, should FIFO flushed in dcd_edpt_close_all before switching ?
Yes, we should flush all fifo with close all
Describe the PR
Tested with net_lwip_webserver on STM32F407DISCO, with command:
echo 1 | sudo tee /sys/bus/usb/devices/3-5/bConfigurationValue
echo 2 | sudo tee /sys/bus/usb/devices/3-5/bConfigurationValue
[hathach/tinyusb] New branch created: labeler-perm
Describe the PR
Use custom secret for labeling new PR
[hathach/tinyusb] New branch created: labeler-pull_request_target
Describe the PR
use pull_request_target for labeler
thank you, I separate tx/rx flush to reuse part of the code. always inline would help to reduce overhead for calling 2 functions.
For labeler somebody said use pull_request_target
https://github.com/orgs/community/discussions/57878
ah thanks, trying to use that in #2591 to see if that works.
Any comments regarding my changes?
As far as I can tell the failing checks are limited to hil-test runs which all fail because of them not finding a serial port / bootloader to connect to. This sounds to me like a problem in the test setup not with my changes.
the call with remaining should be removed
do we still have issue with this spurious interrupt ? I wondered if it is caused by incorrect double buffer configuration previously.
Good spot !
In fact I'm not sure if it's even necessary, pcd_set_ep_rx_cnt() only reduce buffer size.
It's still necessary since Tx interrupt can't be masked, if I disable the EP the host will not happy seeing NAK.
Another way to fix is in classes driver's xfer_cb, always call usbd_edpt_xfer for iso even if there is nothing to send.
No need to change the class driver, this is specifci to this dcd only. I see host send IN token while have nothing to send and ISO does not have NAK --> triggered interrupt with zero byte data. I think this is all good now. Though I think we should make it more ISO explicit thing (making changes atm)
@HiFiPhile I have rename and invert logic for this flag. It now means if we have an active data for ISO IN, and limit its affect on ISO endpoint only. Let me know it makes sense to you.
@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_handlerin your application. I'm not against adding a function like e.g. `tud_de...
perfect, thank you. Great works as usual and I am glad it is more robust now
Hello! I am chiming in here since I worked on this effort for a project and got a link to this issue from a colleague. I'll start the process to push my implementation of the port of TinyUSB to upstream Zephyr.
Is this available anywhere?
Describe the PR
Implement dcd_edpt_close_all()
Tested with net_lwip_webserver on NUCLEO-G0B1RE , with command:
echo 1 | sudo tee /sys/bus/usb/devices/3-5/bConfigurationValue echo 2 | sudo tee /sys/bus/usb/devices/3-5/bConfigurationValue
Can't test with L053 as RAM too small.
Confirmed from oldest F1 datasheet and actual behavior.
Since EP0 size is always aligned to buffer size, I didn't put more check.
Describe the PR
Supercede #2395 with a better style.
I believe this is fixed by https://github.com/hathach/tinyusb/pull/1802. Give it a go, and do report back.
A new ISO endpoints allocation API was introduced to resolve this issue, it's implemented in audio and video class and dcd driver of stm32, esp32 etc. But nobody works on rp2040 driver yet.
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?
Close since this is obsolete. Feel free to open another one should the issue still exists
I initially set it up as a bit field for future reservations, but youโre right that it currently doesnโt serve any purpose.
This change is great! I think itโs very good.
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...
I'm seeing the same behaviour here too. I'm trying to figure out why sending MIDI notes to the host randomly stops working until I unplug and re-plug the USB, but as in the issue report, once connected tud_connected() and tud_mounted() continue to report that they are connected even when the USB cable is unplugged.
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...
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 ...
@hathach ping, is this what you were looking for?
delay using nop where msp430 can run up to 25Mhz
thank you very much, sorry for late response. I have update the PR to use blocking delay (cycle burning, taking consideration for msp430 can run at max 25Mhz). Since there is no generic delay API for tinyusb at the moment. We can change this later should we decide to have an generic time function later on.
thank you very much for detailed explanation. This makes sense, I didn't notice this, it is indeed very good piece of code for run time. I have reverted the changes, although forloop is simpler to understand, this is worth keeping since it is in isr.
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.
thank you for the Pr, I am so sorry for late response. I have rebase and update PR to skip the local endpoint stalled status, and just carry the request from host i.e clear stall even if it is not stalled previously. This will pass to the dcd which should reset data toggle. In case dt is not reset, it is bug from dcd and should be fixed there.
thank you for the Pr, and sorry for late response. I have rebased and add check for queuing new usb event
thank you for your PR and sorry for late response. synopsys is renamed to dwc2 in recent release. I have applied the changes to dwc2 to support SOF. However as generic driver for all dwc2 usbip, it may lack some specific support for stm32, feel free to open issue/pr so that we could update/enhance that.
it has been a while, I have update PR to
- remove changes to nvic
- change the mdk conflict case to use nrfx v2. User with v1 in these conflict can force nrfx version with
CFG_TUD_NRF_NRFX_VERSION=1
thank you, sorry for late response. I have fixed the pre-commit check, will merge after ci passed.
โฆojects.
Describe the PR
Add rtthread script support to better integrate into rtthread projects.
Tinyusb will be added to the rtthread project in the form of a software package.
Additional context
If applicable, add any other context about the PR and/or screenshots here.
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...
Describe the PR
Add renesas cortex-m85 ra8 support.
Additional context
If applicable, add any other context about the PR and/or screenshots here.
I found that using the armclang compiler(ac6) without adding this code will cause it to not run properly.
It's an old issue from ST who hasn't update their license for years.
I don't it's a good idea to make a Debian package as build system artifacts are in the source folder and in general it's not a writable directory in debian.
Otherwise you can use source only repo without examples:
https://github.com/hathach/tinyusb_src
Thanks for your PR but it's more like an example configuration which should be added to rt-thread instead of tinyusb.
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...
Copyright (c) 2034, HiFiPhile
Haha good spot
You mean they are getting placed there when building
Yes, also when you use batch build script tools/build_***.py
CMake can just do an out-of-tree build and then nothing has to be written to /usr/src/tinyusb/
Yes if you use CMake only.
If pack is wrong it should be fixed in src/common/tusb_compiler.h
You need to put this statement inside conditional check as other MCUs don't support HS. For example #if defined(BSP_MCU_GROUP_RA8M1)
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...
They are generated by MCUXpresso which is not FOSS. But the SDK itself is BSD-3 licensed https://github.com/nxp-mcuxpresso/mcux-sdk/tree/main.
But the boards from my list above seem to be missing from the list at https://github.com/nxp-mcuxpresso/mcux-sdk/tree/main/boards or am I looking at the wrong place?
They are part of older sdk, if you don't need just exclude them.
src/ is for tinyusb stack code, lots of pr's files are framework glue codes and does not belong to src/ folder. If rtthread needs these glue code to run, you can put it into lib/ instead.
which board you are testing with, please also add the board to hw/bsp/ra to make sure it got built by ci.
[hathach/tinyusb] New branch created: build-clang
thanks for raising the issue, I will revise and update those file with a better license, find a better alternative etc ... These are very old linker that is in 2000 era, where vendor has very strict license.
if I call function stdio_init_all() many times, it will fill up shared irq slots in rp2040 mcu.
If it is possible to offer a stdio_deinit_all funtion?
assertion "irq_hander_chain_free_slot_head >= 0" failed: file "H:\shared_files\pico\pico-sdk\src\rp2_common\hardware_irq\irq.c", line 215, function: irq_add_shared_handler
If it is possible to offer a stdio_deinit_all funtion?
Why you ask here instead of pico-sdk ?
ๆ่ฐขๆจ็ 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
src/is for tinyusb stack code, lots of pr's files are framework glue codes and does not belong to src/ folder. If rtthread needs these glue code to run, you can put it into instead.lib/
OK,I'll modify it.
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 ...
ๆจๅฅฝ๏ผ้่ฟ่ฟๆ ทๅ๏ผๆจๅฏไปฅๅฐ 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.
I think it would be sufficient to have just hcd_stm32.c as it will also work on h series processors.
This callback should always invoke the hcd_event_xfer_complete function with success or a failure. Calling Submit without some kind of response causes the usb stack to hang.
tinyUSB already has retry mech built in. seems like you should just report failure and let the stack do the retries.
open_control_in_pipe. is basically duplicate code, could be made generic to eliminate the duplicate code.
clear the pipes in here, and I have also found that the used hhcd.hc[] pipes need to be re-inited as well, don't know why stm doesn't have an api to close an endpoint.
Thanks for your effort to make HCD works on SMT32.
- Both F4 and F7 use synopsys dwc2 IP, so they should be generalized
- Implementation shouldn't base on ST's HAL driver, as you can see there is no HAL dependency in
dcd_dwc2.c
Anyway it's a good starting point.
Operating System
Windows 11
Board
ra8d1_evk
Firmware
device cdc_msc
What happened ?
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();...
This problem can also be reproduced on RA6M5/other RA series MCU platforms.
no debug tool
Isn't the board has on-board jlink debugger ?
no debug tool
Isn't the board has on-board jlink debugger ?
sorry I don't have jlink tool
The original capture log file cannot be uploaded either.
The picture is a screenshot of the usb packet capturer
๏ผhttps://www.totalphase.com/products/control-center-serial/๏ผ
ra8d1_ek is not supported yet in the bsp.
่ฟไธช้ฎ้ขไนๅฏไปฅๅจRA6M5/ๅ ถไปRA็ณปๅMCUๅนณๅฐไธ้็ฐใ
This problem can also be reproduced on other RA series MCU platforms.
[hathach/tinyusb] New branch created: nrf-code-format
Describe the PR
reforamt dcd nrf
่ฟไธช้ฎ้ขไนๅฏไปฅๅจ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.
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.handtusb_descriptor.c/.h. That's why every example has its own configurations.For example if you compare
tusb_descriptor.cfromvideo_captureandusb_mscexamp...
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
#...
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...
Describe the PR
- Clang support for cmake tested with most of stm32, nrf, imxrt, lpc
- rp2040 not ported yet
- samd21/51 built but usb does not enumerated yet.
Describe the PR
Some fixes I did when implementing dwc2 DMA support, better to do a separate PR.
dxepctl is not cleared on bus reset, besides no need to do maksed write.
If there are pending IN transfer on bus reset, eg. in cdc echo test do only write without read:
Since EPENA is not cleared on reset, once the EP is opened it will enter DIEPINT_TXFE interrupt and try to write packet and cause cause access violation.
Write dxepctl to 0 won't clear EPENA.
gcc print format for uint32_t is %lu while clang is %u, should use PRIu32 to prevent format warning
don't depend on gcc/clang start file (crt0). Need to define __STARTUP_CLEAR_BSS for start up to clear .bss . This also applies to other nxp mcu as well as nrf
old lpc didn't define __heap_start/__heap_end for use with clang libc
removed since this cause lld issue (either operant must be absolute address or somethin)
these group libgcc must be removed since not available in clang
bug in nrfx v2 linker that does not define these symbole for defining __STARTUP_CLEAR_BSS
libgcc is not available in clang, since ld in nrfx/mdk contains this, we must keep an copy of lds just to remove this line
bug in nrfx v2 linker that does not define these symbole for defining __STARTUP_CLEAR_BSS. This is fixed and not required with nrfx v3
clang linkder does not seem to support self-check defined for symbol, if not change, result is STACK_SIZE = 0
clang: symbol (_estack) must be defined memory section properties after defining MEMORY section first. For this reason, we must keep local copy stm32 ld files, since many of them from stm cmsis repo use this style
remove malloc/free usage since we use static allocation anyway. This prevent linker to try to find libc, heap start/end symbols.
clang is picky, only alow using atomic_flag_ function with atomic_flag and not atomic_bool
change unit test compiler to gcc, since clang (x86 target) conflict with my clang arm target
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
...
It would uses two polling phases for transfering single packet:
Here is my enpoint descriptor for ep2:
[hathach/tinyusb] Pull request opened: #2609 Remove redundant header file includes for the hid class
Describe the PR
#if CFG_TUD_HID
#include "class/hid/hid_device.h"
#endif
hid_device.h include hid.h
Remove redundant header file includes for the hid class
Additional context
If applicable, add any other context about the PR and/or screenshots here.
I think you need to add it to bare_api example.
I pushed a fix for pre-commmit. Look good, note that since I don't ( know how to) use rtthread yet, I won't be able to maintain the code, please submit PR to help keep it up to date.
ๆๆจ้ไบ pre-commit ็ไฟฎๅค็จๅบใ็่ตทๆฅไธ้๏ผ่ฏทๆณจๆ๏ผ็ฑไบๆ่ฟไธ็ฅ้ๅฆไฝไฝฟ็จ rtthread๏ผๆๅฐๆ ๆณ็ปดๆคไปฃ็ ๏ผ่ฏทๆไบค PR ไปฅๅธฎๅฉไฝฟๅ ถไฟๆๆๆฐ็ถๆใ
No problem, I am an official member of rtthread and can help you maintain it.
Describe the PR
- add OPT_MCU_ESP32/C3/C6 for use with max3421e host controler
- add TUP_MCU_ESPRESSIF for quick check mcu from expressif
- add board adafruit_feather_esp32_v2 espressif_c3_devkitc
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
Don't want to depend on class driver but maybe it's the simplest way.
Kernel use dwc2->ghwcfg3_bm.total_fifo_size it should be reliable. We can even remove _dwc2_controller[rhport].ep_fifo_size and use this field instead except GD32VF103 looks strange.
Thanks for your PR, sorry for the delay. I've a change to let ep0 IN transfers use separate buffer.
Describe the PR
Add header files to source tree for easier navigation.
Sorry for the delay, is this callback actually needed for your application ?
_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...
Great, free feel to merge when ci passed
I agree seeing INVALID is confusing, better rename into UNUSED.
With a dedicated EP we don't know the Report type so better to use UNUSED instead of OUTPUT.
I prefer to keep it simple for the moment, we can add the callback when there is real need. (anyway transfer failed is not implement by dcd so it won't be called)
The data a dedicated OUT endpoint receives is from the type HID_REPORT_TYPE_OUTPUT per definition. It's not invalid nor unused!
The new callback should also allows tracking issues for IN endpoints. Without that is not possible.
The data a dedicated OUT endpoint receives is from the type HID_REPORT_TYPE_OUTPUT per definition. It's not invalid nor unused!
Ture.
I've simplified xfer_result_t result as failure reasons are only used by hcd.
Sorry for huge delay, since then both examples received many updates, if you still work on it would be appreciated to port them.
I just realized the lacking of buffer copying in bulk IN transfer is problematic, as some MCU require buffer to be placed into a special RAM region and has alignment requirement. To ensure compatibility I had to add it.
For this reason I've added a buffer for INT transfer with size configured by CFG_TUD_USBTMC_INT_EP_SIZE.
No trivial switch statements
This switch statement should either handle more cases, or be rewritten as an if statement.
FIXME comment
FIXME comment: IAR Assembler cannot include mcu header directly to get __NVIC_PRIO_BITS.
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.
Hi, sorry for the delay. It's hard to say, I believe you got reduced size as constant address functions are not used in your case, however on stm32 it increases code size of ~250 bytes.
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.
:
/src/tinyusb/lib/networking/dnserver.c:195:17: fatal error: a function declaration without a prototype is deprecated in all versions of C [-Wstrict-prototypes]
195 | void dnserv_free()
| ^
| void
1 error generated.
This is likely due to the tinyusb ACM device cap not advertising support for line break. Linux used to ignore it and always send a line break but a recent patch has made it check.
tinyusb ACM device cap not advertising support for line break.
Good finding ! You can make a PR if you want.
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.
Hmmm... don't know what to do here. Unfortunately I don't have any Hi-Speed device in my drawer, so incapable of checking the above.
At least I have a project using NCM which also works in conjunction with Win10. Speed is comparable. My major concern was compatibility.
I was able to massively boost the performance simply by increasing TCP_WND !
| MSS vs Mbps | default | x2 | x4 |
|---|---|---|---|
| 100 | 10.2 | 10.3 | 10.4 |
| 200 | 12.5 | 18.9 | 19.2 |
| 400 | 6.71 | 24.9 | 32 |
| 800 | 8.02 | 12.5 | 46.6 |
| 1450 | 8.00 | 14.8 | 70.4 |
MSS=1450 comparaison
- TCP_WND = TCP_MSS
Instead of one complete datagram 2 segments are sent, both are acked, then high delay (~1ms) until next transfer.
.
Buffer size: I have taken the 3200 from the original TinyUSB NCM driver. So no thoughts from my side concerning buffer size.
Hmmm... currently checking Zephyr sources. They do not transmit frames from device -> host which are > NET_ETH_MAX_FRAME_SIZE, which is 1500+header_size
I can't do that, but I can recreate the PR within a personal repository. Is that OK?
I can't do that, but I can recreate the PR within a personal repository. Is that OK?
I'll do a PR then since the approach is different. You can test it first:
Not sure if lwip's iperf server is buggy or something else, reverse throughput doesn't work well, most cases it just doesn't transfer.
Also looks like a it always use TCP_MSS as MSS.
| MSS vs Mbps | RNDIS | NCM |
|---|---|---|
| 100 | 0 | 0 |
| 200 | 0 | 0 |
| 400 | 0 | 0 |
| 800 | 23 | 16 |
| 1200 | 23 | 16 |
| 1450 | 0 | 0 |
NTB is not used efficiently, always cut in half.
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.
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
Ah... yes... one more thing: in function_ncm.c there is a definition of up/downlink speed. Never really tried values for tuning but perhaps the Linux NCM driver is smart and checks those values?
PS: Just found kernel use 2048 as minimal size:...
Meaning CONFIG_CDC_NCM_XMT/RCV_NTB_MAX_SIZE > 2048 ?
Never really tried values for tuning but perhaps the Linux NCM driver is smart and checks those values?
Already tried, I set it to 480Mbps and nothing changes.
Describe the PR
Due to a missed optimization in the compiler, code for constant address handling is being included in all builds. This change splits the code in different functions to avoid that.
Additional context
Supercede #2132
Meaning CONFIG_CDC_NCM_XMT/RCV_NTB_MAX_SIZE > 2048 ?
I think so, performance is 2-3% lower than 1600 as most parts of last packet is wasted.
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...
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...
@HiFiPhile Thanks for the prompt response. Can you be more specific: what exactly is "out of USB specification"?
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()anddcd_edpt_iso_activate()should work
@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...
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 ?...
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.
Without VBUS there is no way to do disconnection detection.
You should use tud_ready()
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...
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.
...
I understand the situation & I'm actually one of those :-/
My last (side) project was based on RP2040 and its SDK which uses TinyUSB et al.
My current (professional) project is based on Zephyr, so chances are that I will drift away from TinyUSB.
Concerning the settings: of course I will test those. Give me some minutes.
Additional context
I'm trying to make a CMSIS-DAP dongle.
@kkitayam Didn't see that you've already done it :)
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 |
| ---- | ---- | ---- | ---- ...
Perhaps a parameter for wNtbOutMaxDatagrams should be added to allow the regular user as well to enter parameter hell!?
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_...
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:
 and N=1 with a comment mentioning increasing N may increase performance in trade of RAM usage...
Just a quick test, what if you put tusb memory in DTCM in linker script ?
I'll try that when I get back home later today. Do you want everything tinyusb related in dtcmram?
Do you want everything tinyusb related in dtcmram?
Yes please
Just tried. I moved the krpc (the thing using the CDC) and tinyusb at the beginning of DTCMRAM. Still same behaviour
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...
Oh. Yes. I allocated only 2KB to tinyusb. I've pushed a commit that increases the size to 4KB
I have added your suggestions. Currently the NCM driver is not built in the CI. Any idea how to add that?
I'll do comment and format things :) Also I have to move #include "lwipopts.h" to example's tusb_config.h, the stack itself should have minimal external dependencies.
I'll do comment and format things :) Also I have to move
#include "lwipopts.h"to example'stusb_config.h, the stack itself should have minimal external dependencies.
Thank you very much for testing and reviewing.
Thank you, changed according your suggestion.
Just tested the fix in 02ec486 and it solved the issue on my end as well ๐
Does it resolve first all zero setup packet ?
Can't get SWO to work so I've added RTT to your project, and suddenly RTT stop to output...
Maybe there is still some glitch somewhere, enumerate is not smooth as stock example, it start with one incomplete transfer.
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.
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;
}
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 ...
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.
Thanks, but no need anymore. My testing setup was bad. With your set_test.py script and some modifications to also rx at the same time, I can now loopback at ~560KB/s, which is more than enough
Describe the PR
Add cmake support for most of the rest of family for unifiying bsp/ci support.
also fix #2337
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.
No trivial switch statements
This switch statement should either handle more cases, or be rewritten as an if statement.
No trivial switch statements
This switch statement should either handle more cases, or be rewritten as an if statement.
Thank you for your great effort for this new driver ! Now it's setup.
I made this a constant, it's used to be configurable but there was also an error check to ensure TUD_NCM_ALIGNMENT=4, which is quite awkward.
For example build I reduced both NTBs to 1 for less RAM usage, users can read ncm.h for tuning details.
Thank you for your great effort for this new driver ! Now it's setup.
Wonderful to hear that my contribution will be part of tinyusb.
And many thanks for your review. It was very constructive and helpful for rechecking some parts.
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...
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...
Thanks for your PR, please add define and description in cdc_device.h like how #ifndef CFG_TUD_CDC_EP_BUFSIZE does.
Thanks, I did think the setting should be detailed somewhere, in hindsight cdc_device.h should have been the obvious location!
Describe the PR
- In cdc_device if read* functions called before tud_ready() transfer will be queued to EP0 cause strange issues.
- Clear _usbd_dev first to ensure tud_ready() return false before driver clean up.
Testing this feature with ESP32-S3 has been very successful. The device plays sound without any noise, and the FIFO consistently maintains a stable intermediate level.
Thanks for your PR, looks good.
Sorry for the delay, since #2227 is merged, could you make a rebase ?
[hathach/tinyusb] New comment on pull request #2252: Add HID Lighting and Illumination functionality
Sorry for the delay, looks good.
@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?
@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...
@rgrr so TinyUSB was build without any rtos (FreeRTOS/mynewt/other)?
@rgrr so TinyUSB was build without any rtos (FreeRTOS/mynewt/other)?
yes
I'll have a go at building into my current project, may take a while as I few bits I think I need to get my head around to get it in there working. Thanks for looking into it!
[hathach/tinyusb] New branch created: rework-ci
Describe the PR
- rework ci to build multiple toolchains, with multiple build system. Lots of build scripts and ci workflow update
- also add name as permenant member of usbd_classdriver_t
@rgrr when you use TinyUSB functions, do your code calls them from other interrupts (not just USB one)?
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.
forgot: compiler is clang 13.0.0
Thanks for your PR, sorry for the delay. It's no longer needed since #2283 is merged.
This will also ignore DCD_EVENT_SOF
Close deperated PRs.
Despite that this can't be merged easily anymore it's also outdated and should contain a bug.
Maybe next week I can provide the newer version which should work on the current branch.
I can rebase and merge 3 commits:
- Use the SOF as a failsafe to restore from sleep if the host don't trigger the remote wakeup.
- Drop pending interrupts which were skipped if a reset took place.
- Only suspend device if there is no pending remote wakeup.
For Skip interrupt handler if there is nothing to do. as I said if no irq is active dcd_int_handler() won't enter.
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...
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.
`...
@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...
Sorry for the extra long delay, I've merged latest ZLP handling from CDC class.
[hathach/tinyusb] Issue opened: #2632 WebUSB example crash when a max size packet and a ZLP received
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 => {
...
How it goes with #2606 ?
Reason
Currently, the key codes for keypad are marked incorrectly as reserved and they are not defined.
Reference
HID Usage Tables v1.12 from page 57 to page 59
I've move sof status into usbd_device_t to ensure it's cleared on bus reset or configuration change.
Currently audio driver could call sof enable/disable different times, will fix later.
Thanks for your PR, I think it's a more an issue of old macro, should be named HID_KEY_KEYPAD_DOT.
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...
[hathach/tinyusb] New branch created: fix-cifuzz
Describe the PR
A clear and concise description of what this PR solve.
sof must be explicitly enable/disable with additional API
Thanks for everyone's effort.
Generic user land SOF support has been merged in #2213.
One can use bool tud_sof_cb_enable(bool en) and void tud_sof_cb(uint32_t frame_count) to use SOF callback.
Thanks for your PR but it's not something we want.
Normally tud_control_xfer() is an internal API won't be accessed outside, in the case of custom class one can case the const pointer in user land.
Sorry for the delay, is this something still wanted ?
Close obsolete PR, also NCM class has been added into https://github.com/espressif/esp-usb so it's no longer needed.
Expect dma capability in dwc2
@rrrrrrobot @diggit @donbommelon check #2576
Describe the PR
- change concurrency group to ${{ github.workflow }}-${{ github.ref }}
- use argparse for build.py hil_test.py, remove the need to install click
- move ci win/mac to build_cmake.yml
- add get_deps action
- move all hil build into its own ci
Describe the PR
adding circi
There is an issue here, I think.
The call dcd_sof_enable(rhport, true); on line 736 sets previousSofState = true. But we expect to call dcd_sof_enable(rhport, false) here if SOF is used as a failsafe to wake the device?
Describe the PR
Add the adaptation and configuration script of RT-Thread to USB HOST.
@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:
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...
@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:  callers. If you want to, I will try to find out, but that will take some time because I'm currently very busy.
Describe the PR
- try to cache docker for esp idf
- rename build_cmake.yml to build.yml
- cmake(clang) and make(*) only run with pull_request or push to master
- hil test and iar build only run with pr or push to master
Without convincing explanation I can't really give my blessing. I'm pretty sure that DE/EI will not break anything but I'm not sure it really fixes problem that may pop up in different place later.
[hathach/tinyusb] New branch created: ci-tweak3
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
I understand your position. I will revert the second case and commit the mini change.
Further info: This behavior is caused by a very slow old USB stick. I had to increase the MSD read timeout for this stick to work with the uTasker USB stack. Unfortunately there are lots of sticks like this around... How do I increase the MSD read time-out value for tinyUSB?
Thanks!
Hi @perigoso , how's it going the project ? Did you made it work ?
No trivial switch statements
This switch statement should either handle more cases, or be rewritten as an if statement.
Long switch case
Switch has at least one case that is too long: TUSB_REQ_FEATURE_REMOTE_WAKEUP (34 lines).
Thanks for your PR, I've adjusted the logic, test mode is default disabled, one can enable by set CFG_TUD_TEST_MODE=1
As mentioned above the Test Mode is mandatory for Hi-Speed per specification.
As mentioned above the Test Mode is mandatory for Hi-Speed per specification.
It's mandatory for compliance test not for end use, same like WiFi RED test which is mandatory but test firmware is not publicly available.
Yeah, but these are there for a reason. Only because no one cares and don't send in a device doesn't mean it should be disabled per default. It's not that this feature is only enabled just when doing the test.
You are right. At 736 either the value should not overwritten or it should be restored.
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.
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...
@HiFiPhile In the case you want to know how to archive specific events, I personally use the official XHCI Electrical Test Tool (XHSETT). With that you should be able to just send or trigger specific events. Keep in mind that the sleep condition is likely met after triggering a reset. So the app should not react to that.
Why not have a weak declaration in the header file? After all it's used only once at L629 anyway. So a check there for a definition similar how it's done for other things should be more inline.
A return value makes no sense here.
While also true for my original PR that wasn't as obvious. I wasn't sure if every driver has implemented dcd_sof_enable() and so used TU_VERIFY() to check for that.
This is not dead code! This is a check if the used test selector is actually supported and to fall back to do nothing in that case.
The app can still call dcd_enter_test_mode() directly and not all chips which are compatible with DWC2 actually support test modes.
Describe the PR
make use of circle-ci opensource free plan to build arm-clang on pull request. current setup could support up to 700 build on PR
Not a typo, it could be other consumer later, should be only called when whole value change to true or false.
We are converting to weak default implementation for keil and clang compatibility.
dcd layer are private functions can't be called by user code. If there is a need of force enable should implement a usbd_ function
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...
Which device your are testing ?
I've tested G0B1 and L053, both of them resume correctly when reset happens while suspended with XHSETT.
USBD Suspend : Remote Wakeup = 0
USBD Resume
USBD Bus Reset : Full Speed
- 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 ...
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.
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.
[hathach/tinyusb] Issue opened: #2645 EHCI driver attempts transfers exceeding the max transfer size
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...
GD32 chips are already ported.
The only GD32 supported is GD32VF103: https://github.com/hathach/tinyusb/blob/3c24ba3ff2eb5fdb4e214f668a25ed2038a847ad/src/tusb_option.h#L156
[hathach/tinyusb] New branch created: max3421-abort-xfer
Describe the PR
- implement max3421e hcd_edpt_abort_xfer()
- should help to resovle https://github.com/adafruit/circuitpython/issues/9226
- some minor changes to action yml
so far I only tested arm-clang with cdc_msc example, it doesn't seem to need weak_import yet, but I admit we need more testinng. the conlfict with unit-test is resolved (unit test switch back to gcc)
I didn't wrote that I'm using a port which is provided by this repro. :wink:
I also don't get why this matters. This hasn't anything to do anymore this this PR.
Again, I need to revaluate this one (which will likely take a while) and I will create another one to address the different state callbacks (which I hope I can push this week).
I didn't wrote that I'm using a port which is provided by this repro. ๐
I also don't get why this matters. This hasn't anything to do anymore with this PR.
I don't understand why didn't you put the fix in your port since it's a GD32 specific issue, and this driver is for STM32.
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.
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...
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 ...
Oh wow this got merged :D Thanks!
Hooray!
I can switch back to mainline for my audio projects, instead of using my fork :D
This PR should hopefully bring in 2-way sync between device and host for control values.
Sometime I'll try to add support to the Linux UAC2 driver for multi-band equaliser controls too, which it currently seems to totally lack.
This has been closed by #2227
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...
@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...
SAMD support has been tested (both enable and disable) on a Seeed Studio XIAO SAMD21
This implementation has been tested (both enable and disable) on NXP MIMXRT-1010-EVK where the interrupt fires at 125ms as expected for a high speed connection.
thank you for your PR. I am testing this out, rebased (with latest) and also fix ci build and other minor change to cmake build https://github.com/hathach/tinyusb/tree/pr2362_rebased , but I couldn push to this PR since you haven't allow maintainner to update this. Would you mind changing the PR to give me the write permission.
try it now, you should be able to push to my fork
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.
Interesting, it's still working well on my end with my mouse_jiggler example. I do build things differently, but I wouldn't imagine it makes a big difference. I've run into issues before where if bcdUSB is set to 0x0200 instead of 0x0110, a descriptor is requested that gets stalled and device doesn't enumerate.
I can take a look too, which example are you running?
Thanks for your PR, since your are working on it , could you please also add dcd_event_sof() to pass event to upper layer ?
Like:
https://github.com/hathach/tinyusb/blob/ccc7a36043e055ded1f478a979a303e694123187/src/portable/synopsys/dwc2/dcd_dwc2.c#L1161
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.
Is this different? I noticed they already had something like this?
They are similar, except dcd_event_sof() pass the frame number which is useful mostly for audio application.
I need to fix tud_sof_cb() always receive frame_count 0
Thank you both for the information. I will attempt to capture more details about what happens.
My setup is a STM32F042F6P6TR that acts as a USB<->UART bridge using HID and WinUSB. USB only powers the microprocessor and a LED, the rest of the system is optically isolated. The device is connected with a USB-C cable to a no-name 10-port USB-hub with exte...
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...
Try it now, I didn't realize dcd_edpt_xfer should clear the stall, added a call to dcd_edpt_clear_stall. Looks like it's enumerating now on my end with bcdUSB set to 0x0200.
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...
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...
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 ...
(cc @gregdavill since he is the author of the driver/backend/port?)
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...
Hi, your issue involved Arduino which isn't covered by this repo. Please try to reproduce with stock examples:
https://github.com/hathach/tinyusb/tree/master/examples/device
Thank you for your great work, although I don't have CH32 device to test with...
I just merged upstream SOF support to make test easier for other people, please take a look if it's good for you.
There is a PR regarding ch32 issues, you can give a try: https://github.com/hathach/tinyusb/pull/2392/
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:
- Thrustmaster T.16000M joystick
- JustSoaring GliderSim Pro Joystick and pedals
- JustSoaring GliderSim ...
#2392 indeed seems to fix the issues, thanks! (Should this issue be closed as a duplicate then?)
Glad it works, it can be closed once PR merged.
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...
Confirmed that LOG=2 with examples/device/hid_boot_interface appears to function correctly, producing debug logs without deadlocking. I'll open an issue with the Arduino library.
I would still like some clarification about whether tu_printf is expected to be ISR-safe.
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
I just fixed the CI issue and frame count in tud_sof_cb().
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 ...
I haven't had trouble with deadlocks with RTT on nRF52, compared to the Arduino core's Serial1.
On the other hand, anything with Bluetooth (Bluefruit lib; haven't tried anything lower level yet) seems to cause trouble with segfaults during debugging, including RTT.
I haven't had trouble with deadlocks with RTT on nRF52
I think it depends on timing (luck), implementation side they don't have interrupt lock.
https://github.com/NordicSemiconductor/nrfx/blob/4620e7ccfebc08dbd4c039bc7d530b62c4c68ca8/drivers/src/nrfx_uarte.c#L871
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...
mimx and samd frame_count are tested working, eg.
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...
I would have assumed esp32s2/3 uses this driver which doesn't have these sof functions configured?
dcd_esp32sx is old driver still maintained by espressif, a new driver has been created for all devices with dwc2:
src/portable/synopsys/dwc2/dcd_dwc2.c
Describe the PR
Add a simple re-entrancy lock for TU_LOG, should resolve #2652 in most cases. An interlocked version is needed for multicore MCU.
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...
@dragonlock2 no, it is not correct behavior. We should only clear EP0 stalled status (both in and out) when receiving SETUP token. For non-control endpoint, the stalled status remain until it is explicitly cleared by host.
I see, I just moved the dcd_edpt_clear_stall calls to the interrupt when the setup token is received
I see, I just moved the
dcd_edpt_clear_stallcalls to the interrupt when the setup token is received
perfect, I am about to pus the update, but you are faster than me. It is enumerated now, it is now safe to do some "minor" moving and/or generalizing the driver. Will try to merge this soon enough.
Comparison result is always the same
Comparison is always false because resplen <= -1 and 0 <= bufsize.
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...
Even on a single core, volatile is not sufficient to prevent inconsistencies due to ISR execution interrupting another instance executing from user space. This needs an actual critical section, or similar.
Could you make a real example with disassembly ?
[hathach/tinyusb] New branch created: update-circleci
Describe the PR
circle ci remove deps caching to reduce storage credit
superb ! thank you very much for the fix as well as ISO support. I have rebased, merge interrupt handler for ISO and Transfer (since they are similar), also reformat for the code, and add some minor clean up. All is good, tested with v307. Will merge when ci passed.
Just it seems dcd_event_sof is lost on merge.
Just it seems dcd_event_sof is lost on merge.
oops, sorry, let me double check that
dcd_sof_enable() looks good, only dcd_event_sof() is missing.
HOST SOF bit in the interrupt imply that this is only for host most, not sure if it is also used for SOF detection in device mode
@HiFiPhile does this look similar to your previous changes (sorry to loose it while rebasing)
Sof was added in #2181, dcd_event_sof(rhport, USBHSD->FRAME_NO, true); is better as it has frame number.
thank you, I figure that out, but we should mask 11 bit only, since upper 3 bit is micro-frame index which actually increased faster than frame count
I think documentation is a bit lacking for frame count on HS. For example uac2 have msof is easier to do calculation. Dwc2 doesn't mention msof at all.
I think better to standardize msof is used or not.
yeah, we probably need to normalize the micro-frame/frame counter, maybe using the top 3 msb bit in uint32_t for application, or just change the tud_sof_cb() to have an typedef struct. I will do that with follow-up PR later on.
Are you still working on this PR? If so please follow above review to add bsp for the new board.
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...
Hi, i never got back to this project, so there are no updates that I recall
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...
Describe the PR
Add support for UVC frame-based
Transmitting H264 video streams using frame-based transfer on the ESP32-S3 has been very successful.
@kkitayam PTAL! If you need any examples, I will provide them to you ASAP
Describe the PR
A clear and concise description of what this PR solve.
Additional context
If applicable, add any other context about the PR and/or screenshots here.
Easier solution would be to remove CFG_TUD_MEM_SECTION from the const variables. Thay are not placed in RAM anyway
Hi, thank you for the issue, The correct fix would be add an interrupt EP buffer in CFG_TUD_MEM_SECTION, until now the only message sent is ntb_parameters but it could have other messages later.
CFG_TUD_MEM_SECTION is necessary as explained in tusb_config.h that some MCUs can only transfer to/from specific RAM region.
[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
-...
You can remove this #if defined(PKG_TINYUSB_DEVICE_ENABLE) as PKG_TINYUSB_DEVICE_ENABLE already tested.
Same thing for PKG_TINYUSB_HOST_ENABLE
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...
Please use stock example for testing, otherwise it's impossible to diagnostic.
[hathach/tinyusb] New branch created: release-0.17.0
Describe the PR
- increase version as pre-releases, still need more clean up before actual relesae
- Fix readme doc on supported table
- changelog note (WIP)
Is there any progress on host/device switching?
Unfortunately I can't use this routine directly on my board. But I found that if I change the CFG_TUD_NCM_IN_MAX_DATAGRAMS_PER_NTB and CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB to 1, I can use NCM rightly and open the default web.
@rgrr do you have any thoughts?
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
Renesas updates tested on a EK-RA4W1 which had a usb cable added to the appropriate breakout header pins (the USB peripheral actually isn't connected to a USB port on these eval boards).
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?
So this example uses the most recent NCM driver? (you can identify it with my name in the copyright (Hardy Griech))
What is on the host side?
One more thing: @HiFiPhile introduced one significant change during reformat. CFG_TUD_NCM_IN_NTB_MAX_SIZE/CFG_TUD_NCM_OUT_NTB_MAX_SIZE was changed from "(2 * TCP_MSS + 100)" to "3200". Could you please test with the old values?
Thanks for your support and reviews @HiFiPhile !
[hathach/tinyusb] New branch created: tweak-espidf-include
Describe the PR
Fix missing xtensa_api.h
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.
This example use the released version 0.17.0 and has the Copyright (c) 2024 Hardy Griech.
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.
...
In your customization, how about to use taskYIELD() instead of vTaskDelay() to avoid blocking?
@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.
In tud_network_xmit_cb, just process one datagram and will call tud_network_recv_cb to alloc data of this one datagram. I didn't notice that in my previous tests. So in my test, CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB must be 1.
I think the recv data flow is not very suitable for rtos. Do you have any good ideas?
In tud_network_xmit_cb, just process one datagram and will call tud_network_recv_cb to alloc data of this one datagram. I didn't notice that in my previous tests. So in my test, CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB must be 1.
Which means, that your problem is solved?
I think the recv data flow is not very suitable for rtos. Do you have any good ideas?
Perhaps this glue code helps?: https://github.com/rgrr/yapicoprobe/blob/master/src/net/net_glue.c
There are servial ways.
- not use rtos mode of tinyusb.
-
- not use service_traffic(), input data into lwip directly in tud_network_recv_cb()
- modify tud_network_recv_renew(), do a while(1) process of datagrams, and end by recv_glue_ntb==null, end process call recv_try_to_start_new_reception()
There are servial ways.
...
Sorry, I cannot follow... to whom are you responding? The glue code above also uses FreeRTOS. Why not use it? Tested and works (at least in my project ;-)).
There are servial ways.
...Sorry, I cannot follow... to whom are you responding? The glue code above also uses FreeRTOS. Why not use it? Tested and works (at least in my project ;-)).
Thanks.
There are servial ways.
...Sorry, I cannot follow... to whom are you responding? The glue code above also uses FreeRTOS. Why not use it? Tested and works (at least in my project ;-)).
Thanks.
The glue code is useful to me. I want more details but I don't know how to get lwip and tinyusb code in your project.
@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 ...
The glue code is useful to me. I want more details but I don't know how to get lwip and tinyusb code in your project.
Check other parts of the code, esp CMakeLists.txt in the project root
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...
Please use stock (stm32u575-nucleo) example for testing, your setup has many external factors.
Hi @HiFiPhile , thank you for your answer. I don't have such a board. Are there some logs I can add in the stack that may help you?
Stock BSP only use few peripherals so most custom board should be compatible.
https://github.com/hathach/tinyusb/blob/master/hw/bsp/stm32u5/boards/stm32u575nucleo/board.h
Try increase freertos stack size, at the end tusb reinitialized itself probably after crash reset.
Are you talking about using the hooks implemented in freertos_hook.c? If this is the case, when you say "increase freertos stack size", are you talking about the IDLE task?
The USB Bus reset is not due to a crash, but because the GINTSTS_USBRST bit is set in the DWC2 gintsts register.
For some reason the Host decides systematically to reset the USB bus.
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...
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...
There are 2 issues:
- 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...
Describe the PR
Add c6 board to test with max3421e, working well
also move build-renesas into build.yml
bump up uf2 dependency, add family_add_uf2() and family_flash_uf2() to cmake
most of example are now builtable with cmake
Related area
net class
Hardware specification
esp32-S2, esp32-S3
Is your feature request related to a problem?
None
Describe the solution you'd like
None
I have checked existing issues, dicussion and documentation
- [X] I confirm I have checked existing issues, dicussion and documentation.
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 *)¬ify_data, sizeof(notify_data));
}
void ecm_open(void)
{
printf("Ecm OPEN\n");
tusb_control_request_t notify_data =
{
.bmRequestType = 0xA1...
The problem is with this sequence:
if (lock) {
return -1;
}
// <--- ISR COMES HERE
lock = true;
To make that work on uniprocessor with interrupt, then interrupt must be disabled between the test and the setting to true:
something like:
disable_interrupts();
if (lock) {
return -1;
}
lock = true;
enable_interrupts()
And this is of course wrong, more like:
bool is_locked;
disable_interrupts();
is_locked = lock;
if (!is_locked)
lock = true;
enable_interrupts()
if (is_locked)
return (-1);
Hi,
The problem is with this sequence:
if (lock) {
return -1;
}
// <--- ISR COMES HERE
lock = true;
When ISR happened here, vprintf hasn't been executed, so ISR will execute vprintf in it's context then return to normal context. There is no case where the execution of vprintf is interrupted.
Actually you're right, sorry. need more coffee.
But: what protect your IRQ from interrupting another vprintf() call, outside tinyusb?
BTW: I'm using a stm32h747 with tinyusb, and I would love to see your DWC2 DMA patch going in, which is why I was lurking....
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...
But: what protect your IRQ from interrupting another vprintf() call, outside tinyusb?
Good question, currently TU_LOG_* are available for user space logging.
BTW: I'm using a stm32h747 with tinyusb, and I would love to see your DWC2 DMA patch going in
We are few maintaining the repo, if you don't want to wait you can try the testing branch.
The low-end devices STM32U535xx and STM32U545xx use the USB IP found in older STM32 devices (like an STM32F04x for instance). So use the stm32_fsdev driver instead of the synopsys/dwc2 for these two devices.
Thank you for the quick response, and I am sorry for the delay. There was no RAM alignment issue, simply with the first suggestion the example worked as expected. Depending on the selected USB port, I added some extra code to set the specific NVIC_SetPriority.
Again, thank you for your help! I'll close this issue.
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/...
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...
[hathach/tinyusb] New branch created: add-ch32v103
Describe the PR
add ch32v103 bsp support, compile but does not run, probably due to compile/linker/startup issue
Reduced the toggle bit logic to a single XOR. Improves performance, reduces size and simplifies source code. The original code is more than a decade old nonsense from ST, which is still present in their current code.
In addition made the delays in the initialization safer and more portable.
Perfect, thank you. I havenโt tested since didnโt have the hw yet, but it looks great
Thanks @HiFiPhile, 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
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.
Looking more into supported.rst ...
| G4 | โ | โ | โ | stm32_fsdev |
| WBx5 | โ | | | stm32_fsdev |
The hardware of both are of a full-speed USB device type. It seems that there is a confusion of what exactly the โ and empty box means. Currently both are used for two options:
- Not supported by hardware.
- Hardware ca...
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.
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.
I may miss a thing though: the newlib reentrant implementation seems to the the exact same thing as this....
actually, I don't manage the docs well enough. The idea is
- โ: tested and worked
- โ: hw is not supported
- (empty): no information, maintainer just forgot or have no idea.
If you are user WBx5 is FS device only, please make a pr to update it.
I think we should add tud_cdc_mounted() API, and use that in place of tud_ready().
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 ?
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...
It is 2 milliseconds, not seconds so not too bad to wait on I don't think.
ah sorry, indeed, I overlook it again, indeed 2 ms is OK :) . I think We can safely add that delay since it is part of the specs.
Describe the PR
Probably just a simple typo. The recipient for tuh_interface_set() should be TUSB_REQ_RCPT_INTERFACE instead of TUSB_REQ_RCPT_DEVICE.
Additional context
Also slightly updated the table legend. As there are no functional changes, despite the failing hardware test, this PR is ready to go.
missing '+' in the intersection between U5 and L5
all look good, though there is a missing table format in the comment, which cause github not rendering table correcting.
correct, thank you for the fix
I am running into what appears to be this problem. I cam reliably reproduce it on the L476disco board by reducing the system clock to 16MHz (or anything under 48MHz actually).
Applying the suggested change makes the problem go away. Is this then the correct fix?
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?
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...
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...
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...
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...
You've been able to hook in your own USB host drivers since https://github.com/hathach/tinyusb/pull/2222
I made this a while ago but I try keep it up to date you https://github.com/Ryzee119/tusb_xinput
With #2222 this driver can probably just removed at all ...
Excellent. Your driver works as advertised ... thanks a lot ...
Table looks good, somehow legend is not shown .
Applying the suggested change makes the problem go away. Is this then the correct fix?
I am not sure either, I will try to lower clock and pull out my L476 to test with whenever I got time.
Describe the PR
- Add examples host/device_info and dual/host_info_to_device_cdc
- Add ch32v203g6 board, update v20x linker
- add optional COMPILE_DEFINE from cmake cli
Thanks for looking.
In the meantime, we found that the change does not fully fix the issue. Opening and closing the CDC port from windows now fails once every 20 or so tries. So it's better, but not fully fixed.
#2576 changed the interrupt flow, although L475 doesn't have DMA but worth a try.
Thanks. I will test that change. But can only do that next week. I will post an update.
#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
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 ...
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...
@alano-ee with #2576 I'm not sure if the fix above case GRXSTS_PKTSTS_OUTDONE: is still necessary, it doesn't exist in ST's driver. What happens without it ?
@HiFiPhile Without that case statement, I end up at the default, which triggers a breakpoint.
And with that statement, I end up in an infinite loop, because the DOEPINT_STPKTRX flag is not cleared. The comment claims that it is cleared later, but handle_rxflvl_irq is called from a loop until all flags are cleared. But they are never.
(Should this comment move to #2576?)
Hum... in ST's code handle_rxflvl_irq is pretty simple : https://github.com/STMicroelectronics/stm32l4xx_hal_driver/blob/42d324ac323088701270f2c19f328bcad0457c52/Src/stm32l4xx_hal_pcd.c#L1109-L1139
DOEPINT_STPKTRX will be cleared in handle_epout_irq, normally it takes care the special case of GenID 3.10A https://github.com/hathach/tinyusb/blob/02ec4866105eca3f95e7392e538caf97ebb902b4/src/portable/synopsys/dwc2/dcd_dwc2.c#L1084-L1086.
But I don't have L47x board to see what really...
I have tried to change the interrupt handling to match what STM32 HAL does: https://github.com/HiFiPhile/tinyusb/pull/2
I could only test with STM32L486, but it seems to work there. But this is all based on looking at the STM32HAL driver, and not based on any documentation.
Describe the PR
Make LPC55 work with FreeRTOS.
Also add MPU setting to fix potentially USB RAM alignment issue (ref. https://community.nxp.com/t5/LPC-Microcontrollers/USB-and-newlib/m-p/1312833#M45952)
Describe the PR
ISO C does not allow extra ';' outside of a function [-Werror=pedantic]
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=...
I am also investigating another issue
~/libs/tinyusb/src/class/audio/audio_device.c:1493:23: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]
1493 | while (p_desc < p_desc_end)
| ~~~~~~~^~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
Describe the PR
Fix the following error
~/libs/tinyusb/src/class/audio/audio_device.c:1493:23: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]
1493 | while (p_desc < p_desc_end)
| ~~~~~~~^~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
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 ?
...
Thanks, there was some leftover not changed.
No, please take a look at FreeRTOS enabled examples, tud_task() is executed in it's own task, when there is no message it's blocked to free CPU.
https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_msc_freertos
I read the post ,does it work with (int)(1U << 31U) ?
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...
Please make a PR so I can approve it sooner.
Describe the PR
fix error
~/dsp/libs/tinyusb/src/class/audio/audio.h:643:53: error: ISO C restricts enumerator values to range of 'int' before C23 [-Werror=pedantic]
643 | AUDIO_CHANNEL_CONFIG_RAW_DATA = 0x80000000, // TODO
| ^~~~~~~~~~
compilation terminated due to -Wfatal-errors.
thank you. Have a nice weekend!
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...
@kkitayam hi kkitayan, you can try this with a esp32s3 devkit.
https://espressif.github.io/esp-launchpad/?flashConfigURL=https://dl.espressif.com/AE/esp-iot-solution/config_test.toml
Just flash this bin, and you will see two camera.
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 ...
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 ...
Would like to have the same, I hope to get USB CDC ACM (virtual com port) devices running on a ESP32 as USB Host.
Preferably with Micropython, since Micropython uses tinyusb, I thought would be a good idea to look here if Host actually is supported :face_with_peeking_eye:
will need to revert this since this cause, note that int is not guaranteed to be 32bit for all platform. Not sure why build workflow does not trigger for this PR.
warning error: left shift count >= width of type [-Werror=shift-count-overflow]
[hathach/tinyusb] New branch created: revert-2693-enum-int
Good spot, don't know how I overlooked this even I work alot on STM8 who has 16 bit int...
Maybe use #define to replace enum later.
using
int32_t?
it is still overflowed since first bit is considered signed bit.
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...
Updated the first post with logs and example.
maybe we should re-open this until we find a solution
Hi guys, in case you are still interested in USB Host applications, we have it supported on ESP32-S2 and ESP32-S3 in esp-idf
Here's some documentation https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/usb_host.html
And some CDC examples https://docs.espressif.com/projects/esp-idf/en/stable/esp32s3/api-reference/peripherals/usb_host.html
@tore-espressif Thanks, yes I use that when I am on esp-idf. I have some projects that are on Arduino (ex. https://www.sparkfun.com/products/21307), and it would be very valuable to have USB Host available in both frameworks. Is there a brief way to explain on why this is especially challenging for the developers? The question comes up fairly frequently and I never know what to say.
Operating System
Windows 11
Board
STM32G0B1CBT6
Firmware
I make a simple project here https://github.com/hathach/tinyusb/commit/b3ee927e58cf7cd44f05db9dec41bc241ef94902
What happened ?
I make a CDC Usb device but not work, I need help.
It will get
53 | extern uint32_t SystemCoreClock;
So, I comment this line https://github.com/hathach/tinyusb/commit/b3ee927e58cf7cd44f05db9d...
Please don't use issue for asking for help.
[hathach/tinyusb] New branch created: v203-use-224kb
Describe the PR
enable full 224KB flash for ch32v203 with flash enhanced read mode in SystemInit (best with startup.s but good enough for now).
add flash with wlink-rs
add board_reset_to_bootloader() as weak board_api.h
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.
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...
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...
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?
thank you for your PR, I think we should update the dcd_musb.c to support max32 instead of duplicating an new driver. Since that make maintanence easier in the future. I can help with that, give me a bit of time, I will try to find an dev board to test this out.
[hathach/tinyusb] New branch created: add-tud_cdc_configure_fifo
Describe the PR
- add tud_cdc_configure_fifo() to replace CFG_TUD_CDC_PERSISTENT_TX_BUFF as follow up to #2629
- new line, and code format
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.
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 ...
[hathach/tinyusb] New branch created: dwc2-test-mode-followup
Describe the PR
- all dwc2 ip seems to support test mode in both fs/hs -> remove TUP_USBIP_DWC2_TEST_MODE
- remove dcd_check_test_mode_support(), all should be supported
- move enum tusb_feature_test_mode_t to tusb_types.h
For dev board, this one look reasonable https://www.digikey.com/en/products/detail/analog-devices-inc-maxim-integrated/MAX32666FTHR/12727215 (lead time is 09/02), will let you know once I got the hardware.
Yes, that board will work out well for testing. The MAX32650FTHR is also a good choice for a small form factor board, but same 9/20 lead time at Digikey.
Feather 666 is a bigger chip with dual core but cost less than 650 and also available earlier so it is better choice I guess.
This did not work so well for me as already mentioned there: https://github.com/hathach/tinyusb/discussions/1764#discussioncomment-10034888
Operating System
Linux
Board
Custom ESP32 S3
Firmware
My own, but this is not relevant - will explain below
What happened ?
The new USB NCM driver - introduced in #2227 - is causing a stack overflow.
It causes the problem like this:
tud_network_recv_renew will call into [recv_transfer_datagram_to_glue_logic](https://github.com/hathach/tinyusb/blob/bd...
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.
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...
Hmmm... not getting the point. Do you think the problem is in the NCM driver or in the glue code?
Perhaps my own glue code could be of help?: https://github.com/rgrr/yapicoprobe/blob/master/src/net/net_glue.c
I think it's in the NCM driver, which cause compatibility issues with older codes that calls tud_network_recv_renew directly within tud_network_recv_cb. And this can be fixed by my function above.
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;
...
No, this will not work, because when you call recv_transfer_datagram_to_glue_logic(), should_process is false, so the if (should_process) block won't be executed. Keep in mind that the second call to tud_network_recv_renew is inside recv_transfer_datagram_to_glue_logic.
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...
you are right (again)... perhaps it could be solved by letting recv_transfer_datagram_to_glue_logic() return an indication that some work has been done (or that there is some work still waiting)?
Yes, but I think should_process in my code is this indication.
got that, but to be honest I'm not happy with two variables for this logic.
[hathach/tinyusb] New branch created: migrate-hil-pi5
Describe the PR
update hil to run on new pi5
Describe the PR
Due to some expectations in the glue code, a recursive call of tud_network_recv_renew() might happen.
This is the corresponding fix for it.
Additional context
See discussions in #2711
Closes #2711
Could you please check PR #2713
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.
[hathach/tinyusb] New branch created: more-hil-pi5
Describe the PR
hil flash itsybitsy m4 with picoprobe which is faster and more stable then using bossaac bootloader
[hathach/tinyusb] New branch created: hid-2253-followup
Describe the PR
- rename tud_hid_report_fail_cb() to tud_hid_report_failed_cb() and change its signature
- use default implementation for hid callbacks to be compatible with keil compiler
- code format
Describe the PR
fixed _find_desc_format "fmt == VIDEO_CS_ITF_VS_FRAME_FRAME_BASED" to "fmt == VIDEO_CS_ITF_VS_FORMAT_FRAME_BASED"
Additional context
Describe the PR
Add metro m7 1011 to hil rpi test
[hathach/tinyusb] New branch created: fix-hil-boardtest
Describe the PR
fix hil board_test duplication, add cdc_msc_freertos test
RP2040 tweaks:
- Compiler warning fixes
- allow pico-sdk LWIP to be used if TinyUSB one does not exist
- Use custom memcpy in RP2040 code
- Don't clear registers when not needed as hardware reset already does it
Describe the PR
Some variables not reset to 0 on driver reset, fix #2724.
[hathach/tinyusb] New branch created: hil-add-ra4m1
Describe the PR
add ra4m1 ek for hil test
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.
thank you look good. I made neccessary tests for the weak implementation: skip exists check, but we need to check its returned value. Also apply for the qualifier and other_speed
[hathach/tinyusb] New branch created: hil-add-lpc11u377
Describe the PR
add lpc11u37 for hil test
I know this has been merged, but replacing memcpy with a local implementation makes no sense to me.
memcpy, by definition, does not have any alignment restrictions (but of course you need memmove if there's potential overlap). I would suggests that any memcpy that crashes on a non-4-byte-aligned input or output is busted or should not be called memcpy because lots of other things are going to bre...
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...
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.
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...
@HiFiPhile that is OK, I still prefer not puttin this in the stack.. the commennt will help to illustrate the point of guess work. just use bool flag for each descriptor callback.
@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,...
[hathach/tinyusb] New branch created: fix-fsdev-issue
Describe the PR
fix issue introdued by #1942 due to typo https://github.com/hathach/tinyusb/commit/818bda18c23e17c08c689b543d77ecc944681dea#diff-3e8c23d7e232b49de75eeff4f44eacd3a8179e0409395d1110ed742523b81847L1289
@hathach , I'll start digging into that merge. Hopefully can get something together by the end of the week.
I still have to add a vTaskDelay after tud_task() function otherwise my application freezes. And what I ding understand is if the tud_taak is blocking, iT is consuming al cpu right?? Hoe is iT supposed to work?
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...
[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...
Gotcha. Thanks to all for looking into it.
Ok thats clear to me , but why is my application only working properly with the vTaskDelay added? It should work without it right? But it doesnt. Are there other FreeRTOS config settings which can cause this behaviour?
Gotcha. Thanks to all for looking into it.
no problems, thank you for providing feedback on the PR.
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:
I believe it should be the opposite; bail if th...
Related area
HID device
Hardware specification
all hardware
Is your feature request related to a problem?
If there is more than one HID subordinate descriptor, use sizeof(tusb_hid_descriptor_hid_t) to enumerate exceptions
Describe the solution you'd like
Supports...
maybe someone is interested in a rebased version to the latest master
https://github.com/ra1nb0w/tinyusb/tree/rx_fb
maybe someone is interested in a rebased version to the latest master https://github.com/ra1nb0w/tinyusb/tree/rx_fb
Thank you, will rebase when free, also move #2628 into example.
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.
Describe the sol...
@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...
[hathach/tinyusb] New branch created: enhance-fsdev
@BrentK-ADI perfect thank you, my order from Mouser already shipped, it will probably delivery in a few days. Let hope we could get this merged as soon as we could.
Describe the PR
Trying to fix race condition with ch32v203 with windows, still haven't fixed it yet. But fixed a few issue while testing. Also try to improve fsdev driver.
For some reason my codespell didn't catch that error when I ran pre-commit. I'll hold off fixing it if there are other updates needed for this merge to avoid a frivolous entry in the commit log.
@electretmike could you confirm if issue is resolved with latest #2576 ?
I was busy on other projects for the last weeks, and will be away the next few. I hope to be able to test in about 4 weeks.
Operating System
Others
Board
PIC0 RP2040
Firmware
examples/host_bare_api
ex_host_bare_api.zip
What happened ?
On pico rp2040 host, control endpoint get blocked after a random period of time. The status stage is missing and no more control_xfer is possible.
On a specific roline mouse, enumeration fails with wrong data toggle from the device. The USB_INTS_ERROR_DATA_SEQ_BITS is not handled ...
@kilograham this might be an issue with the rp2040 usb host controller. TinyUSB host does not handle the wrong data toggle error but when I connect the same device to other host controllers including Windows, I don't get such an error.
@hathach This PR has been tested my multiple users and works well, since @PanRe is not here could you take a look and merge?
[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...
Impressive work! Thank you all for your effort in improving the UAC2 driver!!
Expression has no effect
This expression has no effect (because ep_add_dtog has no external side effects).
Expression has no effect
This expression has no effect (because ep_add_dtog has no external side effects).
Thank you for your PR.
This issue was also reported in #2656
Sorry, I'm busy now. Iโll confirm this PR and #2656 together later.
this comment for catching ch32v203 issue with windows with -O0/-Og
[hathach/tinyusb] New branch created: hil-change
Describe the PR
- add g0b1 (fsdev 2k buffer)
- remove esp32s3 due to cp210x cause usb bus issue in the long run
cp210x ttyUSB0: usb_serial_generic_write_bulk_callback - nonzero urb status: -71
[hathach/tinyusb] New branch created: fix-ch32v203-setup
Describe the PR
More effor to fix ch32v203 setup race with windows
I am currently experiencing the same issue.
By any chance, did you find what was wrong with it?
For some reason my codespell didn't catch that error when I ran pre-commit. I'll hold off fixing it if there are other updates needed for this merge to avoid a frivolous entry in the commit log.
no problems, my order is in custom clearance, it should be delivered in a couple of days.
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;
}
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...
@HiFiPhile: Good to see you're still active on the tinyusb audio part :-)
Thanks a ton for the pull request reference. Another rabbit hole to traverse into... :-(
Woo love to see this finally get in! Thanks for keeping it going :D
great! hello proper uac:)
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?
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...
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
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...
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...
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...
The most recent master that have merged fix-ch32v203-setup still presents the issue
Unfortunately no, had to pause my project until a solution is found. Still hoping that happens one day.
The newer tusb_option.h assumes that there is a number of device endpoints to check against.
You'll want to update with this version of PIO-USB at least: https://github.com/sekigon-gonnoc/Pico-PIO-USB/pull/126
Describe the PR
move ci toolchain url into setup-toolchain action yml instead of ci_set_matrix.py
I got the feather dev boards, will start to test/review and make changes if needed to merge this PR asap. If you have an pending update, please push it if possible to prevent conflict/merge thanks.
Marked the keycode parameter of the keyboard_report functions as const since the functions don't modifies the value
These functions does not change the value of uint8_t keycode[6] therefore it should be marked const
tud_hid_n_keyboard_report
tud_hid_keyboard_report
Describe the PR
Temp fix build for rp2040
Describe the PR
Try to fix hw and Re-add nano ch32v203
with latest commits the value is correct. But it is non constant like before the rework.
Instead, the mic is completely unusable now. It is constantly in underrun (tested on linux) but the value returned by tud_audio_write is stable and correct.
I hope these feedback are useful.
@hathach I'd a git bisect, it looks like d680424f62b0d677158af7219b319a24f5497d1c breaks ISO IN transfer.
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 (...
@HiFiPhile got it, running that script is good enough. No worries, I also have G0 and H5 which has 32-bit bus (2K USB SRAM). I will do some testing, bi-set and backtrack. It is probably the buffer toggle issue.
False alarm for L0, I just forgot disable DEBUG so the timing was all wrong...
@hathach since you are working on it you can integrate the changes if you want.
thank you @HiFiPhile , it seems to fix the issue, it is easy to miss epreg bit manipulation :). Though on Linux, the plot does not look as good as your screenshot, but that is no problem, I will find a way to verify these value with a script later so that we could include them in the hil test.
I have added quite a few board recently and upgrade the self-host to pi5. Cable is a mess but it is good enough, so I guess we could close this issue now.
[hathach/tinyusb] New branch created: fsdev_iso_fix
Describe the PR
should fix #2755, thanks @HiFiPhile
[hathach/tinyusb] New branch created: circi-dynamic-config
Describe the PR
circleci dyanmic config
fixed. Thank you very much guys!
the plot is probably the same, the issue is the (horizontal) time scale.
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:)
I have bring this PR updated to master, add max32 to ci build and fixes some warning when compiling with cmsis header v3 (in the mcu/max32). Will do more extensive test with actual hw tomorrow.
[hathach/tinyusb] Issue opened: #2764 HardFault occurs randomly while sending HID report on CH32V203
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 ...
Tested with feather maax32866, it works as a charm, passed my local hil test with both TI tm4c and max32666, I am doing a bit of more refactor, but probably wont change the driver behavior. We probably merge this real soon (hopefully). Note: since I have both max32650 and 666, I will add one to the hil pool as well to get it tested with the ci.
This PR removes unused code in usbtmc example and uses existing defines instead of hardcoded values in several places.
There are no functional changes otherwise.
Glad things worked smoothly. Thanks for putting the time into this!
why this commit is the default tinyusb? I just see the submodoule default url
Minor style improvements found by cppcheck.
@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...
@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...
@BrentK-ADI thank you, I change the branch to release and it compiles perfectly. I was on the default adi-main previousls. Shouldd have tried that first, not too familliar with Analog tool (have been using jlink so far for developing) :)
I am able to add feather max32666 to the hil pool. Somehow, someway, I fried my feather max32650 while trying to flash with openocd, no 3v3 measured,power with lipo battery does not work as well (it has been doing just fine with jlink). Luckily I still have an extra max32690 ekit (though it is a bit trunky).