#tinyusb

1 messages · Page 4 of 1

jolly scroll
#

and after a funky irq, it was in this state!?

jolly scroll
# 
] heap info
Heap dump (using miniheap):
        base 0xc411c284, len 0x9d7c
        free list:
                base 0xc411c588, end 0xc411c59c, len 0x14
                base 0xc411c74c, end 0xc411e418, len 0x1ccc
                base 0xc4125688, end 0xc4126000, len 0x978
        delayed free list:
                node 0xc411c5a8
                node 0xc4123588
] novm
not enough arguments
usage:
        novm info
        novm alloc <numberofpages> [arena bitmap]
        novm free <address> [numberofpages]
] novm info
name 'main', 1037027 pages, each 4k (4148108k in all)
  range: 0xc411d000-0xc1400000
# 
loading GD#24, disk offset 5632
tuh_msc_read_block(0xc411c518, 0xc4120220, 526347, 1)
406.446168 [DWC2:hcd_edpt_xfer:418]:    HOST0  ->   2.02 0xc401d87c/31 opep:0xc411c4d0 type:2 pid:0
407.592887 [DWC2:hcd_edpt_xfer:411]:    HOST0  <-   2.81 0xc4120220/512 opep:0xc411c488 type:2 pid:2
dumping channel 0: IN init
  HCCHAR0: 0x988a00
    mps:512 ep:1 dir1 type:2 mc:1 addr:2
  HCSPLT0: 0x0
  HCINT0: 0x0
  HCINTMSK0: 0x7ff
  HCTSIZ0: 0x40080200
    size:512 packets:1 pid:2 ping:0
  HCDMA0: 0xc4120220
enabling...
unhandled VPU Exception: Bad L2 alias
dumping channel 0: xfer comp
  HCCHAR0: 0x988a00
    mps:512 ep:1 dir1 type:2 mc:1 addr:2
  HCSPLT0: 0x0
  HCINT0: 0x0
  HCINTMSK0: 0x7ff
  HCTSIZ0: 0x80000000
    size:0 packets:0 pid:0 ping:1
  HCDMA0: 0x00000200
407.939082 [DWC2:dwc_check_interrupt:657]: bytes 0, buflen 512, packets: 1, old next_pid: 2
407.947150 [DWC2:dwc_check_interrupt:658]: hcd_event_xfer_complete(2, 0x81, 512, success, true)
407.955571 [DWC2:dwc_irq:746]: irq time: 267783
Fatal VPU Exception: Undefined instruction
     pc: 0x0000000c  lr: 0x00000000
#

stack 0xc411e4c8, stack_size 8448, stack_used 1660

#

stack end: c41205c8

fallow birchBOT
jolly scroll
#

the buffer was ~936 bytes from the top of the shell's stack, which fits with expectations

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: build-pico-examples
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New review comment on pull request #2052: Renesas_RA: add support for board with HS USB port

I think the natural size of the CPU architecture, the variable type, is better for performance. The natural size means 'int' and 'unsigned'. Unless there is a reason the type may keep 'unsigned'.

When variable type is narrow than CPU architecture, compiler generates sign extension instructions to keep variable type size.
In this function, it is clear that 'total_len' is always less than or equal to 65535, so there is no need for it to be 'uint16_t'. Because 'total_len' is clipped by max p...

fallow birchBOT
jolly scroll
#

@robust walrus so ive now run into a rather confusing problem

reading MSD works fine
if i link my ext2/4 driver in, it begins loading group descriptors
0-23 load fine
24 causes all **** to break loose
when the IN packet for that block is executed, an unknown cpu exception fires
if i attempt to return from that, the normal transfer-complete irq fires

but a cpu exception in the middle of an irq hander prologue, corrupts the state, and it returns to the wrong addr

#

adding sleeps to every in/out does nothing

#

reducing the vpu clock does nothing

robust walrus
#

I haven't seen anything like that before

jolly scroll
# robust walrus I haven't seen anything like that before

i can currently think of ~3 plans of attack

1: figure out exactly what is causing the Bad L2 alias exception
2: examine the stack and figure out why i cant return from that
3: just checksum all of .text and .rodata and see if dma is somehow corrupting my code

you got any ideas from that?

robust walrus
#

not really, you are in deeper weeds than I am

jolly scroll
#

one issue, is that i dont have an MMU, and i havent configured the MPU

#

so anything can just trash my code

# 
unhandled VPU Exception: Bad L2 alias
VPU registers:
     r0: 0x00000039  r1: 0x00000065  r2: 0x7e201018  r3: 0xc401bed0
     r4: 0xc4012394  r5: 0x00000000  r6: 0x00000065  r7: 0xc4018c4f
     r8: 0x00000007  r9: 0x40000000 r10: 0x80988a00 r11: 0x00080000
    r12: 0x00000200 r13: 0x00000800 r14: 0xc4120420 r15: 0x0000ffff
     pc: 0xc40012a0  lr: 0xc4000a9a  sr: 0x20000000
# 
0xc401ccd0 9c 12 00 c4 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0xc401cce0 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0xc401ccf0 00 00 00 00 ff ff 00 00  20 04 12 c4 00 08 00 00  |........ .......|
0xc401cd00 00 02 00 00 00 00 08 00  00 8a 98 80 00 00 00 40  |...............@|
0xc401cd10 07 00 00 00 4f 8c 01 c4  65 00 00 00 00 00 00 00  |....O...e.......|
0xc401cd20 94 23 01 c4 d0 be 01 c4  18 10 20 7e 65 00 00 00  |.#........ ~e...|
0xc401cd30 39 00 00 00 9a 0a 00 c4  00 00 00 20 a0 12 00 c4  |9.......... ....|
#

from 0xc401ccd8 to 0xc401cd33, you can see r23 to r0, in reverse order

#

after r0, is the state of lr at the instant it entered the exception handler

#

9a 0a 00 c4, as the printf showed, that is a return statement at the end of platform_dputc()

#

00 00 00 20 a0 12 00 c4
from memory, i believe the hardware will push the PC and status reg to the stack, upon any interrupt

#

so, it was 1 opcode into fleh_irq (the raw irq entry-point) when this exception fired

#

0xc401cd40 00 00 00 00 86 1d 00 c4 00 00 00 00 00 00 00 00 |................|

#

but there is an extra 32bit word there.., then an addr into .text, timer0_irq(), a c function

# 
0xc401cd50 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0xc401cd60 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0xc401cd70 00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0xc401cd80 00 00 00 00 00 00 00 00  00 00 00 00 44 9e 00 c4  |............D...|
#

and a lot more nulls

#

followed by the c entry-point for the usb irq

#

this stack doesnt look right, and i can see why it later returned to an invalid addr

fallow birchBOT
fallow birchBOT
#
cleverca22
[hathach/tinyusb] New comment on issue #2188: External Custom USBH Class Driver Definitions

i also remembered another benefit of this trick
ipxe always compiles every driver, to prevent code-rot

and then at link time, it can select what the user actually wanted, so you can still get small binaries, but lesser used code still gets syntax/type-checked by the compiler

but yeah, you would need to at least inject the linker script into the linker args, i believe it can take multiple linker scripts

jolly scroll
# 
] bio dump usb2_0 269489664 512
tuh_msc_read_block(0xc411c718, 0xc41204e0, 526347, 1)
  Queue EP 02 with 31 bytes ... 
240.417172 [DWC2:hcd_edpt_xfer:418]:    HOST0  ->   2.02 0xc401da7c/31 opep:0xc411c6d0 type:2 pid:2
241.545910 [DWC2:hcd_edpt_xfer:411]:    HOST0  <-   2.81 0xc41204e0/512 opep:0xc411c688 type:2 pid:0
241.837717 [DWC2:dwc_check_interrupt:658]: hcd_event_xfer_complete(2, 0x81, 512, success, true)
242.869957 [DWC2:hcd_edpt_xfer:411]:    HOST0  <-   2.81 0xc401da9c/13 opep:0xc411c688 type:2 pid:2
tuh_msc_read_block(0xc411c718, 0xc41204e0, 526347, 1)
244.090481 [DWC2:hcd_edpt_xfer:418]:    HOST0  ->   2.02 0xc401da7c/31 opep:0xc411c6d0 type:2 pid:0
245.246201 [DWC2:hcd_edpt_xfer:411]:    HOST0  <-   2.81 0xc41204e0/512 opep:0xc411c688 type:2 pid:0
246.570247 [DWC2:hcd_edpt_xfer:411]:    HOST0  <-   2.81 0xc401da9c/13 opep:0xc411c688 type:2 pid:2
#

digging some more, i can see that my bio dump only supports 256 byte blocks

#

so, to dump a 512 byte sector, it has to do 2 reads

#

and its not the block# that is lethal, that is the same block that fails

# 
0x10101600: 08 00 08 00 14 00 08 00 08 10 08 00 00 80 e0 1f |................
0x10101610: 00 00 03 00 00 00 00 00 00 00 00 00 e0 1f 7f 84 |................
0x10101620: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x10101630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x10101640: 09 00 08 00 15 00 08 00 06 12 08 00 41 7e e0 1f |............A~..
0x10101650: 00 00 03 00 00 00 00 00 00 00 00 00 e0 1f e3 46 |...............F
0x10101660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x10101670: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x10101680: 0a 00 08 00 16 00 08 00 04 14 08 00 00 80 e0 1f |................
0x10101690: 00 00 03 00 00 00 00 00 00 00 00 00 e0 1f de 60 |...............`
0x101016a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x101016b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x101016c0: 0b 00 08 00 17 00 08 00 02 16 08 00 41 6d e0 1f |............Am..
0x101016d0: 00 00 01 00 00 00 00 00 e3 f3 00 00 e0 1f 88 80 |................
0x101016e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................
0x101016f0: 00 00 00 00 00 00 00 00 3a d5 00 00 00 00 00 00 |........:.......
# 
[root@amd-nixos:~]# hexdump -C /dev/sdc --skip 269489664 --length 512
10101600  08 00 08 00 14 00 08 00  08 10 08 00 00 80 e0 1f  |................|
10101610  00 00 03 00 00 00 00 00  00 00 00 00 e0 1f 7f 84  |................|
10101620  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
10101640  09 00 08 00 15 00 08 00  06 12 08 00 41 7e e0 1f  |............A~..|
10101650  00 00 03 00 00 00 00 00  00 00 00 00 e0 1f e3 46  |...............F|
10101660  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
10101680  0a 00 08 00 16 00 08 00  04 14 08 00 00 80 e0 1f  |................|
10101690  00 00 03 00 00 00 00 00  00 00 00 00 e0 1f de 60  |...............`|
101016a0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
101016c0  0b 00 08 00 17 00 08 00  02 16 08 00 41 6d e0 1f  |............Am..|
101016d0  00 00 01 00 00 00 00 00  e3 f3 00 00 e0 1f 88 80  |................|
101016e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
101016f0  00 00 00 00 00 00 00 00  3a d5 00 00 00 00 00 00  |........:.......|
#

and the data its returning, does look valid

#

@robust walrus aha, if i just hexdump the same block ~25 times, it crashes!

#

that roughly lines up with an ext4 superblock, and 24 group descriptors!

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #2052: Renesas_RA: add support for board with HS USB port

@kkitayam great anatomy, indeed using native size has smaller code size, though I am worried that unsinged on smaller such as 8-bit mcu can cause issue (not sure if rusb2 has any 8-bit mcu maybe H8). However, as @HiFiPhile suggested uint_least16_t seems to be the best of both worlds. If you agree we could do that.

PS: would it be ok if we do that in follow-up PR since I plan to refactor common code from dcd/hcd (pipe write/read etc..) anyway and that would be good chance to update overall...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: pr2091
jolly scroll
#

@visual breach ive hit a rather crazy bug in the dwc hw

if i read ~27 packets from a usb device
the hw takes the 32bit int, 12 bytes into the last usb packet
and overwrites the dma write-pointer

then writes that packet to an essentially random location in ram, lol

#

how crazy does that sound?

visual breach
jolly scroll
#

it also fired a VPU exception, that i havent been able to return from correctly

#

so its also a DoS

#

i'm not sure what it could be, because it fires with such regularity

visual breach
#

(btw, I think this is offtopic for #tinyusb ?)

jolly scroll
#

i'm writing an HCD for tinyusb, on the rpi

#

and the usb controller is malfunctioning, when using the mass-storage driver in tinyusb

# 
 59.183018 [DWC2:dwc_check_interrupt:706]: bytes 0, buflen -1006507332, packets: -1006507332, old next_pid: 1
 59.192647 [DWC2:dwc_check_interrupt:707]: hcd_event_xfer_complete(2, 0x81, 0, success, true)
ASSERT FAILED at (lk/kernel/timer.c:151): timer->magic == TIMER_MAGIC
#

what what have i done??, time to debug it more!

# 
unhandled packet status on rx fifo
  channel: 4
  byte count: 1558
  PID: 0
  packet status: 10
#

wait, what

fallow birchBOT
jolly scroll
# 
0x0f0e0d00 8a aa ab 8b aa aa 22 aa  aa aa aa aa 00 01 02 03  |......".........| 
0x0f0e0d10 04 05 06 07 08 09 0a 0b  0c 0d 0e 0f 10 11 12 13  |................|
#

a sample, where the entire sector (0 to 255, repeated twice), got written to address 0f0e0b0c, which is just 0c 0d 0e 0f but interpreted as LE

#

i should get to bed

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2105 Add CDC+UAC2 composite device example for Pico

superb! Thank you very much for your PR and patient. I was super busy with other works. I have pulled and tested, added makefile so that we could build with other mcus without the huge list of skip.txt. Also update descriptor to build with nrf52 and a couple of file renaming to reduce confusion as tud_cdc.c look like it comes from the stack. Overally it is great, I haven't tested it on other mcus though, but should work (else we could fix later).

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: enhance-bsp
fallow birchBOT
#
bitgamma
[hathach/tinyusb] Issue opened: #2203 STM32H5 support

Related area

Port

Hardware specification

STM32H5

Is your feature request related to a problem?

Is support for STM32H5 planned in future? Couldn't find any discussion in regards and would like to use TinyUSB in a project using that MCU

Describe the solution you'd like

Support for STM32H5, at least in device mode

I have checked existing issues, dicussion and documentation

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

@robust walrus just noticed a possible hint
the tx fifo, can hold ~32 packets of 512 bytes
its failing at ~27 plus enumeration....

fallow birchBOT
jolly scroll
#

@robust walrus i dumped the raw rx and tx fifo's
after the failure, i can see a 512 byte sector, crossing the border from rx fifo to tx fifo!

robust walrus
#

please don't ping unless you have a question about tinyusb. I'm not following the details of your debugging. You are in areas I'm unfamiliar with

#

(I'll still follow along with your updates. just don't want to get interrupted)

jolly scroll
#

kk

#

my current theory, is that the fifo's are as broken as the interrupt mask...

jolly scroll
#

setting them to the current value doesnt work

#

but if i shrink the rx fifo, it seems to stop crashing...

#

that seems to be working

#

unsure if data is being lost when it overflows into "free space" and wraps wrongly

#

but its no longer crashing

#

was able to read 1024 sectors without issue!

jolly scroll
#

left it reading 102400 sectors
its up to 10.2k

jolly scroll
# 
] fs mount /root ext2 usb2_0p1
] ls /root   
F 1431655893       .
error -2 opening file '/root'
D 16384            lost+found
D 4096             lk
] ls /root/lk
D 4096             .
F 1431655893       ..
D 4096             .git
D 4096             .github
F 120              .gitignore
F 1132             LICENSE
F 1344             README.md
D 4096             app
D 4096             arch
D 4096             dev
D 4096             docs
F 12442            engine.mk
D 4096             external
D 4096             kernel
D 4096             lib
F 590              lk_inc.mk.example
D 4096             make
F 1113             makefile
D 4096             platform
D 4096             project
D 4096             scripts
D 4096             target
D 4096             tools
D 4096             top
]
#

woooo!!!

#

the problem, was that despite the rx fifo being right up against the tx fifo (0 byte gap, the default), it seems that is invalid, and it causes the fifo to overflow into its neighbor

i just shrank the rx fifo some, and no more problems

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #2204 Enhance bsp

Describe the PR

  • Mostly BSP related, non-stack code
  • rename hw/bsp/board.h to hw/bsp/board_api.h
  • add board_get_unique_id() to get unique ID for usb serial number. Partly implement #1970 , related #2194
    • This function is implemented on rp2040 and various stm32
    • if not implemented default to 0123456789abcdef
  • Update all examples'descriptors to use unique ID
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2151: Fix build issues when building for RP2040 from pico-examples/pico-sdk.

update: and PR building pico-examples will be added soon (after this one). CI will only build 2 usb example in the pico-examples repo dev_hid_composite and host_cdc_msc_hid (currently disabled due to usb host api changes). let me know if this is sufficient enough.

https://github.com/hathach/tinyusb/blob/2e7192c5c277be039d67950c302b7efb2b80b9a3/.github/workflows/cmake_arm.yml#L92-L109

    - name: Build pico-examples
      if: matrix.family == 'rp2040'
      env:
        PICO_SDK...
fallow birchBOT
jolly scroll
#

filled in the missing code for queues to block
removed various sleeps, it can now enumerate a usb disk in ~3.2 seconds from init
wired up the msd disconnect event, and fixed interrupt endpoints

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #2194: Enhance HITL (hardware in the loop) test

I've connected the boards.

3 debuggers are flashed to Jlink:

SN Board Device
770935966 STM32F746DISCO STM32F746NG
774470029 NUCLEO-L412KB STM32L412KB
727600775 OM13092 LPC54608J512

Both STM32L4 & STM32F7 works, while only HS port works on OM13092. (added missing -DBOARD_TUD_RHPORT=$(PORT))

Tried changing 54628 to 54608 in board.mk and I don't spot any USB related difference...

fallow birchBOT
fallow birchBOT
#
abakosh
[hathach/tinyusb] Pull request opened: #2205 fix(usbh): robustness against unplugging usb device when it is busy

Describe the PR
Host Library:
The unplugging process of the USB device might lead to an infinite loop. It is easy to run into this situation if unplugging occurs during the enumeration process. Also, it happens when unplugging while the host and the USB device are doing something.

The issue is really big. As the stack enters an infinite loop when this is happening.

Additional context
I am testing with the RA4M2 family, with no OS. I know this fix is not meant if you are hosting a hub...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hw-test-jlink-sn
fallow birchBOT
jolly scroll
# 
] init
hcd_event_handler()
HCD_EVENT_DEVICE_ATTACH
#

] reset

# 
] open
 17.585567 [DWC2:hcd_edpt_open:390]: dev 0 EP00 opened root port: 0 hub_addr: 0 hub_port: 0 speed: 2(HS) opep: 0xc4116db4
] setup
hcd_event_handler()
HCD_EVENT_XFER_COMPLETE
  ep_addr: 00
  result: 0
  len: 8
#

(result 0 is success)

# 
] data_in
hcd_event_handler()
HCD_EVENT_XFER_COMPLETE
  ep_addr: 80
  result: 0
  len: 8
0xc4018600 12 01 00 02 09 00 02 40  00 00 00 00 00 00 00 00  |.......@........|
# 
] setup
] data_in
hcd_event_handler()
HCD_EVENT_XFER_COMPLETE
  ep_addr: 80
  result: 0
  len: 8
0xc4018600 12 01 00 02 09 00 02 40  00 00 00 00 00 00 00 00  |.......@........|
# 
] setup
] setup
] data_in
0xc4018600 12 01 00 02 09 00 02 40  00 00 00 00 00 00 00 00  |.......@........|
jolly scroll
#

ive confirmed that the hub in the lan9514, is perfectly happy to respond to SETUP requests, even if a previous control-in was not completed fully

#

my next step, was to test that with a tinyusb device, but my zero is giving me trouble...

jolly scroll
# 
] init
HCD_EVENT_DEVICE_ATTACH
] reset
 20.297209 [DWC2:dwc_check_interrupt:671]: port enabled at HS
] open
 25.373273 [DWC2:hcd_edpt_open:390]: dev 0 EP00 opened root port: 0 hub_addr: 0 hub_port: 0 speed: 2(HS) opep: 0xc01014cc
] setup
] data_in
0x8001d7c0 12 01 00 02 00 00 00 40  00 00 00 00 00 00 00 00  |.......@........|
#

(diff usb device, no hub involved, pi0)

#

and i can confirm the same thing, setup setup in, and setup in setup in all give the expected result, even with the ack missing, or controls not reading the in

#

but i can break the rp2040 boot rom, by just doing setup setup in

#

i think its tinyusb based

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #2209 Enhance HITL test

Describe the PR
Add HITL testing script for newly added boards #2194

I'm not familiar with Github, @hathach could you take a look for CI integration ?

Additional context

Actually it catched something !
My lpcxpresso54608 (even modified 54628 to 54608 in board.mk) failed with cdc_msc test, msc block doesn't show up :

[242341.797154] usb 4-1.7: new high-speed USB device number 89 using xhci_hcd
[242341.901761] usb 4-1.7: New USB device found, idVendor=cafe, idProduct=...
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support
  • There should be only necessary things placed in an interrupt. Everything else should be done in the main loop.
  • Data response should be done in an asynchronous manner.
  • The USB driver only guarantee bandwidth (for isochronous transfers) and uniform timings (for interrupt transfers).

Meaning a HID device can be polled at any time as long as the rate is constant while it's unclear when that actually happens between two SOFs packages. So the SOF interrupt should be only used to save the...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2151: Fix build issues when building for RP2040 from pico-examples/pico-sdk.

LGTM - not sure if it is better to just have the job fail if there are any issues (e.g. the host API changing is a valid reason for failure), though we could add a second job for that - perhaps i'll add that on our end

maybe you could update the pico-examples on dev branch, and we can use dev branch here. otheriwse a failed ci will prevent any merge on this repo. We could fix and enable it in follow up PR. Thank you.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host-usb-reset
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #2211 Host usb reset

Describe the PR

  • Add tuh_rhport_reset_bus() for reset downstream port.
  • Add tuh_rhport_is_active() to check if rhport is running as host
  • EHCI improve bus reset, fix send_setup() not carried out if halted previously
  • seperate bus reset delay and contact debouncing delay in enumeration
  • fix host msc get maxlun not using aligned section memory

@tannewt

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: pico-sdk-1468
fallow birchBOT
fallow birchBOT
fallow birchBOT
jolly scroll
robust walrus
jolly scroll
#

ahh

#

which half did he fix?

robust walrus
#

maybe not. thinking #2211 above

jolly scroll
#

yeah, thats more host stuff

#

and also a fix i mentioned elsewhere:

fix host msc get maxlun not using aligned section memory

#

ive also gotten MSD and ext4 stable enough that i can stream raw uncompressed video from usb to the screen

#

have a look at this

jovial mist
#

Does anyone have any resources on using the rp2040 as a host using its own built in USB port that's already attached? I want to use a USB keyboard to type in a program, but I want to just be able to plug a usb in without cutting up the wire. Also preferably in Arduino lol

#

like maybe modifying the Feather Host library to just use the usb thats built in

jolly scroll
jolly scroll
jovial mist
#

yeahhh I have seen that, but I was looking for an arduino version

jolly scroll
#

10.935417 [DWC2:hcd_edpt_open:415]: dev 0 EP00 opened root port: 0 hub_addr: 5 hub_port: 2 speed: 0(FS) opep: 0xc411a2e8

#

ok, so something in tinyusb is aware that its a full-speed device behind the hub

#

that came from asking tinyusb via hcd_devtree_get_info()

#

yep, as expected, thats a reply from the hub

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2209: Enhance HITL test

Now it read README.TXT from mounted device.

thank you perfect, I will check this out soon enough. Though one thing pop up in my mind. I think at the end of the CI. We should flash board_test example. This will disable the usb on the tested board. Making testing the next board easier, at least it will more forgiving in our test script.

fallow birchBOT
#
cleverca22
[hathach/tinyusb] Issue opened: #2212 host mode enumeration halts if second hub present

Operating System

Others

Board

rpi2

Firmware

custom https://github.com/librerpi/lk-overlay/tree/master/platform/bcm28xx/dwc2 + https://github.com/librerpi/lk-overlay/tree/master/lib/tinyusb

#define CFG_TUH_HUB                 1
#define CFG_TUH_DEVICE_MAX          (3*CFG_TUH_HUB + 1)

What happened ?

a second hub connected to port 2 prevents enumeration from discovering devices on ports 3-5

if the MSD is on port 2, and hub on port 3, the MSD is enumerated,...

fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

As far as I know it's not guaranteed that interrupt transfers are always scheduled directly after the SOF, even if that is typically done this way. I'm not aware that the USB specification specifies when withing a frame interrupts transfers should take places as long as the timing is ok.

Imagine a lot of devices with a lot of interrupt interfaces. The more there are the longer it takes to handle all and the last one can be scheduled very late compared to the first one.

Even your linked ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2209: Enhance HITL test

lpc54 has an issue with receiving 31 bytes for msc command and sending 13 for msc status. Somehow when the transfer is complete, it is only 30 bytes (1 residue) and 12 bytes. Seem like the interrupt triggered a bit early or something. I have spent something troubleshoot, but not quite sure what is wrong. We probably need to skip the lpc54 for now, lpc55 has no issue with this though, strange.

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support
  • I think a general SOF callback can be helpful for any application. It's likely needed for any realtime implementation. As the other callbacks these drivers callbacks are handled also by the tud_task() in the main loop. So that can't be used as a time reference for any time critical stuff because you don't know the time between the SOF interrupt triggered by the MCU and when this callback is actually executed. Of course for non-critical stuff it should be fine and better as nothing.
  • I d...
#
perigoso
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

@Rocky04 I don't understand where you are trying to get, please be concise, and avoid massive information dumps and rambling like you are doing, it's hard to parse to parse without the context of what you're thinking, also try to reach a conclusion, ideally something actionable, right now you're just wasting everyone's time.

I think you're suggesting that the SOF interrupts not reliable, and you're right, that's a given some architectures don't even implement it... but I fail to realize wh...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

@perigoso Here, as simple as I can write it for you...

  • Add a general SOF callback. It makes absolutely no sense to implement that in a HID specific way.
  • It would help making the delay more consistent but likely add latency. Please check out how Motion Sync works on a modern mouse.
  • Your statement is contrary. This PR is all about adding a HID specific callback and not about a general one.
  • I aware of the USB specification, how a typically implementation for a USB device works an...
fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

@Xelus22
The function hidd_sof_isr() as configured in the class driver is called in dcd_event_handler() and so executed when the SOF interrupt is handled. That's why the name is "isr". Due to this there would not pass much time between the interrupt and the execution. But that approach isn't good because only very important stuff should be done in an ISR and as less as possible execution time should be spend there in general.

The added code from you in the tud_task_ext() function on...

#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2209: Enhance HITL test

I was looking around for lpc54 issue and found there are 17 USB issues in errata sheet, that's a lot...

Maybe it's related:

* USB.1: In USB high-speed device mode, the NBytes field does not decrement after BULK OUT transfer
Introduction:
The LPC546xx. device family includes a USB high-speed interface (USB1) that can
operate in device mode at high-speed. The NBytes value represents the number of bytes
that can be received in the buffer.
* Problem:
If the buffer length is less th...
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

Here, as simple as I can summaries it, just for you...

This is better, you should make extra effort from the start.

A general SOF callback should be added. It makes absolutely no sense to implement that in a HID specific way.

I agree, I made the same suggestion.

It would help making the delay more consistent but likely add latency. Please check out how Motion Sync works on a modern mouse.

This is precisely what I noted as being an implementation detail.

Your statemen...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

@perigoso

Upf, details matter... An implementation is always about the details. This is a PR, so side effects and specifics need to be taken into account. The underlying goal for the desired feature of this PR was all about input delays on USB. So with the provided info I was basically questioning the purpose of the PR as is, even I referred to a use case which would be implementation specific.

I can understand that there is likely a language barrier and that maybe not all things are e...

#
Rocky04
[hathach/tinyusb] New review comment on pull request #2180: HID SOF interrupt support

There are naming conventions for a reason. So people who read a function name have an expectation what the function does. Messing around with that only causes issues.

Just have a look at the other TinyUSB callbacks, like tud_mount_cb(). The event for it is invoked (but the function isn't executed) in the ISR. It's later called in the main loop from tud_task(). But audiod_sof_isr() on the other hand is executed in the ISR. So the "_cb" functions are executed in the main loop and the "...

fallow birchBOT
fallow birchBOT
#
kammce
[hathach/tinyusb] Issue opened: #2214 Consideration to support remotely allocated USB interface storage

Related area

extending class driver

Hardware specification

N/A

Is your feature request related to a problem?

Currently, a project needs to select the number of class descriptors at compile time. In most use cases, this is great as it is well known the exact number of each type of USB device an MCU wants to be. But what about cases where this isn't known? In my case, I'd like to make prebuilt binaries of this library for multiple architectures. These binaries can be linked in...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #2209: Enhance HITL test

yeah, I figure that out as well. I have already made the changes, just want double check if you first. The id is also shorten in blk device, if it only impact serial, then we are probably safe to remove the cut ?

def get_serial_dev(id, product, ifnum):
    # get usb serial by id
    return f'/dev/serial/by-id/usb-TinyUSB_{product}_{id}-if{ifnum:02d}'


def get_disk_dev(id, lun):
    # get usb disk by id
    return f'/dev/disk/by-id/usb-TinyUSB_Mass_Storage_{id}-0:{lun}'
...
fallow birchBOT
fallow birchBOT
#
kammce
[hathach/tinyusb] New comment on issue #2214: Consideration to support remotely allocated USB interface storage

Sure. Please correct me if there is already a way to support remotely allocated storage for this project or if this isn't necessary to support multiple USB ports at runtime. To clarify my goal, I would like to build a prebuilt binary version of this library for the set of processors I plan to deploy to. A small example of those would be Cortex-M0+, Cortex-M3 and Cortex-M4 processors. Having these singular prebuilt binaries means that I can link them to any application that wants to support US...

#
hathach
[hathach/tinyusb] New comment on pull request #2209: Enhance HITL test

I pushed my changes which include:

  • add lpc54608 board, similar to 54628
  • work-around for lpc54 mcu, msc disk appears but the mcu is too troublesome, it still reset randomly, and failed with hid_boot_interfaces, probably due to USB.15 (TX corruption) and/or other usb errata. So I decide it is better to not include lpc54 into the test farm since it will be a headache in the future.
  • update hitl_test script and json to simplify the json configuration. by default, all tests will be run. js...
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2209 Enhance HITL test

everything seems to work well now, except for the lpc54 which has horrible usb hs implementation. The MSC still use the 8 byte ID ( didn't manage time to update that). But it is all good for the merge. We can update thing later with follow-up PRs. @HiFiPhile let me know if you are ok with my changes, and/or want to make more changes.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2209: Enhance HITL test

Perfect it's good for me, maybe also let it run for GCC build.

yeah, that is possible as well, though I think we are good enough for now. Since we do generally test with gcc when developement. IAR is much rarer, so I am glad it is covered by HIL. Thank you very much for work and VM/board farm for doing actual test.

fallow birchBOT
fallow birchBOT
#
kammce
[hathach/tinyusb] New comment on issue #2214: Consideration to support remotely allocated USB interface storage

I was looking through the code today and I think the cdc_dual_ports is a great example. In the tusb_config.h, CFG_TUD_CDC is set to 2, which sets the size of https://github.com/hathach/tinyusb/blob/92457ec99f1690b772ef9fa6b348256701c7fcf7/src/class/cdc/cdc_device.c#L86. Now if I wanted to make prebuilt binaries for Cortex M3 processors to support multiple applications, I would need to make a prebuilt bina...

jolly scroll
#

it hurts, when youve been reading usb specs for weeks

and then linus claims usb includes the full route in the address of usb packets

#

facepalm

#

and now he is confused as to why 250 ENDPOINTS are working, when the address limit is 127

#

though he is now starting to explain some more about endpoints

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #2194: Enhance HITL (hardware in the loop) test

I've added a LPCXpresso4367 to replace 54608, it passes all tests with EA4357 BSP. I think it's good to have chipidea_hs tested.

PS1:
Can we modify Make to build both FS & HS option for stm32f746 ? Since HS use external phy I think it worth to test both.

PS2:
Potential null pointer dereference building host example for ea4357.

/home/tusb/tinyusb/src/portable/ehci/ehci.c: In function 'hcd_edpt_xfer.constprop':
/home/tusb/tinyusb/src/portable/ehci/ehci.c:459:5: error: potential n...
fallow birchBOT
jolly scroll
#

@robust walrus after a few more days work, i now have tinyusb dwc2 working on both VPU and aarch64
its able to load a Image file from ext4 on usb, and execute linux
and linux is then able to mount the rootfs, and begin booting (but the systemd starts being a pita)

ive also talked to somebody else about xhci, and found a potential issue with tinyusb/xhci support
the xhci controller will automatically assign an address and issue the SetAddress control transfer for you, skipping a few steps in tinyusb's state machine
so that state machine would need special states for xhci

fallow birchBOT
robust walrus
#

Nice work!

jolly scroll
#

yep, dwc host support

#

no PR yet, and i'm heavily relying on LK primitives (events, timers) in the HCD

#

so it wouldnt work outside of my kernel

robust walrus
#

👍

#

can you abstract that into the OSAL?

jolly scroll
#

part of the problem, is that interrupt endpoints are 100% manual

#

so when an interrupt endpoint NAK's, i have to schedule a timer to try again later

#

and the existing OSAL lacks timer support

#

though, i could modify it, to just have a big queue of things, and retry on the next SOF IRQ

#

i'm also using malloc in many places in the HCD

#

and from what ive seen, tinyusb seems to be anti-malloc

#

and i'm still missing split transaction support, so no LS/FS devices

robust walrus
#

yup, anti malloc

#

that's best for circuitpython and micropython because their main heap gets torn down and recreated every VM

jolly scroll
#

so i would need to kind of re-design the entire HCD, to suit tinyusb's expectations

#

but i at least have a working example now, and a far better understanding of the hw

robust walrus
#

👍

jolly scroll
#

i also discovered a nasty bug, in the MSD support

robust walrus
#

xhci would be so cool to support 🙂

#

host support is all very new so I'm not surprised

jolly scroll
#

tinyusb does not support 2 concurrent reads, and has zero protections to stop you from trying that

#

due to the lack of malloc, it uses a static buffer for state

#

and a second read, just overwrites the buffer, and then when 2 replies come in, it goes nuts 😛

#

i discovered that, when implementing bad-apple

#

i opened 2 files, in 2 different threads, bad-apple.bin (the video), and bad-apple.wav

robust walrus
#

haha, uh oh!

jolly scroll
#

had to wrap the MSD functions in a mutex to make it functional

#

but i did also notice another thing

#

every scsi command, has a 32bit tag

#

i think the intent, is that the usb drive can send replies out of order

#

and you use the tag to send the reply to the right client

#

so, if tinyusb just staticly allocates say 4 buffers per drive

#

then it can support 4 concurrent reads at once

#

and still route the replies back to the right thread

#

but currently, tinyusb hard-codes that 32bit tag, to TUSB

robust walrus
#

🙂

jolly scroll
#

and when i went to actually use the usb heavily, my old friend corrupt packets returned!

#

there is a config bug, where tcp packets get silently corrupted

#

as best as i can tell, the usb NIC (smsc95xx) validates the tcp checksums for you

#

then sends packets over usb (which has its own checksums)

#

and linux trusts that the smsc95xx and usb are doing their job, and doesnt check checksums

#

*REG32(USB_GVBUSDRV) = (*REG32(USB_GVBUSDRV) & 0xFFF0FFFF) | 0xD0000;
if this line of code is missing from the firmware, then something in that whole chain messes up

#

and tcp packets get corrupted without any warning signs

#

you wont notice until ssh/https get upset

#

i had disabled that, because it was breaking my HCD, back before i had proper reset logic

fallow birchBOT
#
rppicomidi
[hathach/tinyusb] New comment on issue #2188: External Custom USBH Class Driver Definitions

@hathach If you require a C only solution, then macros like these should do the trick.
In file usbh_classdriver.h

/*
   To define your own USB Host driver(s), invoke this macro one or more times in the definition of the
   CFG_TUH_EXTERNAL_DRIVERS macro in your local tuh_config.h file
*/
#define TUH_MAKE_EXTERNAL_DRIVER(ex_name, ex_init, ex_open, ex_set_config, ex_xfer_cb, close) \
    { \
      DRIVER_NAME(ex_name) \
      .init       = ex_init, \
      .open       = ex_open...
jolly scroll
# 
[   12.847507] FIQ FSM acceleration enabled for :
[   12.847507] Non-periodic Split Transactions
[   12.847507] Periodic Split Transactions
[   12.847507] High-Speed Isochronous Endpoints
[   12.847507] Interrupt/Control Split Transaction hack enabled
#

noticed this in the dmesg while booting linux

#

and now that i know usb more, i can make sense of this

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #2188: External Custom USBH Class Driver Definitions

thanks @rppicomidi , we will probably go with the same approach used by custom device class driver with callback for consitency. Also back then we once considered a smilar approach like your suggestion, but espressif team insist on dynamic drivers to only load them once enabled, which I think kind of making sense. I forgot the detail, but you could go through the long discussion in following issues

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #2194: Enhance HITL (hardware in the loop) test

ah thanks, I also have LPCXpresso43s67, I can help adding bsp and testing this out.

Can we modify Make to build both FS & HS option for stm32f746 ? Since HS use external phy I think it worth to test both.

Yeah, sure, I would love to, we will need

  • add addtional json field for compile argument e.g PORT=0 (may need to duplicate f476 in json)
  • update test scrip to build to build with extra compile argument and run test on f746

You don't have to do this, give me a bit of time, I...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

late response as usual, seems like there is a bit of heated dicussion in this issue, I hope we are still cool and don't take that personal.

Hi hathach, ive added in the SOF callback to the HID driver specifically for fast mouse response and minimum latency.
I've put it here since I would like to use tinyUSB to follow the current fastest open-source mouse firmware on the market in terms of click latency (after razer)
https://github.com/zaunkoenig-firmware/m2k-firmware/blob/main/mo...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on commit `8451d05`

@hathach
Why was is renamed, what was the issue with the existing code?
Because that function pointer is executed within the ISR and not like a callback in the main loop I would think it helps to understand the code better if that suffix is used.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-lpc43s67
#
hathach
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

@hathach What's missing and should be re-added? The linked PR is merged. Do you mean the function to dynamically set the SOF ISR function?

If that is supposed to be controlled by the individual implementation why is there one already present just for audio?

I just removed that in one of follow-up PR along with other managing code, forgot which one. Yeah, we can re-add that generic code to enable SOF

void tud_sof_isr_set(tud_sof_isr_t sof_isr);

Though, maybe we sho...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
tswan-quasi
[hathach/tinyusb] Pull request opened: #2219 min on cdc r/w

Describe the PR
Adds a MIN() check for the bufsize on cdc reads and writes. This is to avoid a loop where the 'bufsize' passed to 'tud_cdc_write()' or 'tud_cdc_read()' is '65536' (or a multiple) causing nothing to be written/read.

Additional context
Casting values to uint16_t greater than UINT16_MAX just truncates the upper bits, which means if bufsize ends up being 65536 (or a multiple) it results in the uint16_t cast giving a value of 0, causing no read/write to o...

fallow birchBOT
#
kammce
[hathach/tinyusb] New comment on issue #2214: Consideration to support remotely allocated USB interface storage

CFG_TUD_HID is maximum HID interfaces tinyusb can support, it does not dictact number of HID in use. That is dictacted by configuration descriptors. What is your max HID for all cases, just define CFG_TUD_HID to that number. If it isn't terribly high number, it won't cost much of sram.

I'm building a library that others will consume that uses this project, therefore I cannot know what circumstances a user of the library will find themselves in and thus I cannot define a hardcoded value...

#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

The issue right now with setting the function pointer for a driver specific SOF callback (here used in a common sense), which is executed within the ISR, is that this would need to know to which driver it should be applied in the case multiple configurations are used. The driver name is only present on a debug level so that can't be used.

Because of this I think it would be better to let it as is so that the SOF ISR is purely driver related. Meaning if that behavior should be changed or co...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

I would prefer to have both, a more general SOF callback which is weak and executed by tud_task() and so within the main loop and one separated from this in the ISR for driver specific things. For the first there is already a PR https://github.com/hathach/tinyusb/pull/2213.

I used to think of deferred SOF, but from last work with audio feedback. I am not quite sure if we still need that. what is point of SOF where is not invoked in the start of frame, other transferred is probably comple...

#
Rocky04
[hathach/tinyusb] New comment on pull request #2180: HID SOF interrupt support

I'm not really sure what you mean...

For me there are two places, executed a bit later in the main loop via a general callback and or directly when the MCU handles the SOF interrupt via a specific driver callback. I also don't get why you mentioning tud_sof_enable() because controlling if the MCU should react to a SOF package or not is independent what the application should do when this occur and can be handled.

I also think a vendor defined driver should have full control and I don'...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #2214: Consideration to support remotely allocated USB interface storage

oh, I can see your point now. This will require all the changes across all drivers, but there is a few gotchas

  • internal buffer also has other resitriction on endpoint alignment and address range depending on mcus.
  • The internal interface typedef struct won't be made public, therefore the set interface is probably just supply buffer + size and get the number of inteface it got in return. Maybe we can have an get size function. But that would be needed for every class driver.
  • The set...
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2220: Adding support for custom SOF ISR for CFG_TUD_VENDOR

Again, yes the control of that is missing. The code I use so far is much older and rely on a symbol (USE_SOF) where it's always on or off. Indeed a dynamic control of that is the preferred way and for this reason I'm currently adding it to the PR #2213.

It also doesn't matter if it hurts performance when it's needed. Of course it should be off when it's not currently needed. What's the preferred way if an implementation wants to have it's own audio driver with endpoint control? I would i...

fallow birchBOT
fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on pull request #2220: Adding support for custom SOF ISR for CFG_TUD_VENDOR

English is not my first langue either...

At first I thought I know how a vendor defined device should look like. Due to your feedback I'm not sure anymore. :worried:

I was expecting that each device should have at least one standard class from TinyUSB defined in the tusb_config.h config file. So if no predefined class matches the use case the vendor class should be used instead. But if this isn't the case I don't get why there is a vendor class to begin with if that should not be us...

#
hathach
[hathach/tinyusb] Pull request review submitted: #2180 HID SOF interrupt support

we should only add sof_isr that can be auto managed (on/off when neede) to class driver e.g audio with feedback enpoint is enabled, sof is enabled, and disable along with the interface. Since HID does not need it function, we can add an generic sof cb in isr for this purpose for app to turn it on and off when it wants. You don't need to make any changes for this PR. I remembered added that sometime ago (then reverted), I could try to re-add it when possible. Thank you for brining up this PR a...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: ehci-halted-error
fallow birchBOT
robust walrus
#

I found docs that say you can get pcap data from an ip socket but can't figure out how

#

tio can do serial -> ip

jolly scroll
#

will circuitpython acitvate the pio-usb host stuff automatically, or do i need to enable something at build time?

#

is it as simple as just connecting the usb cable to the right pins?

robust walrus
#

I think its on in the build but you'll need to init it from python

#

port = usb_host.Port(dp, dm) iirc

jolly scroll
#

ah, manually specify pins, perfect

robust walrus
jolly scroll
#

so i can wire it up the same as the sniffer-lite, and just punch the pin#'s into the repl

robust walrus
#

probably. I think they need to be consecutive pins but that's probably true for the sniffer too

jolly scroll
#

yeah, so the only issue is if its D+, D-
or D-,D+

robust walrus
#

I think pio-usb handles both..

#

dp then dm

jolly scroll
#

ive also commited all of my little-kernel/dwc2 stuff to github

#

and i can now boot linux on my pi3, even when building from a completely clean clone

#

in the current configuration, i only bring dwc2 online once, in aarch64, to load the linux kernel from usb

#

and then linux takes over, and finds the rootfs

#

up next, is confirming that stage1 can still do things, and make it fully self-contained on usb

fallow birchBOT
fallow birchBOT
#
arntsonl
[hathach/tinyusb] Pull request opened: #2223 Add tuh_hid_get_report(...) to hid_host.h

Describe the PR
This allows USB host functionality to call HID_REQ_CONTROL_GET_REPORT on the TUSB_DIR_IN direction, and read the report buffer in the callback function.

This extends the functionality of the hid_host.h/.c files and gives the host a way to call the HID get report features.

Additional context
I'm one of the main developers of https://gp2040-ce.info/ and we extensively use the TinyUSB library to handle USB calls. I wanted to try to keep our TUSB host code as hid_h...

jolly scroll
#

soldering job is a bit messy, but that should work

jolly scroll
# 
[Tue Aug 15 02:15:30 2023] usb 1-11.1.2: New USB device found, idVendor=0930, idProduct=6544, bcdDevice= 1.00
[Tue Aug 15 02:15:30 2023] usb 1-11.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Tue Aug 15 02:15:30 2023] usb 1-11.1.2: Product: USB Flash Memory
[Tue Aug 15 02:15:30 2023] usb 1-11.1.2: Manufacturer:         
[Tue Aug 15 02:15:30 2023] usb 1-11.1.2: SerialNumber: 001D92DC4AF9C8C153B703E7
#

vs

>>> dev.idVendor
2352
>>> dev.idProduct
25924
>>> dev.serial_number
'001D92DC4AF9C8C153B703E7'
#

i think that just worked?

#

vid/pid do match

# 
>>> dev = usb.core.find()
>>> dev.idVendor
1267
>>> dev.idProduct
420
>>> dev.serial_number
#

i typed those commands, from my usb keyboard, plugged into pins 10/11

#

everything ive tried works, when tannewt gets back tomorrow, you can tell me what you did to break it, and how to access MSD, and i can poke at it more

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #2188: External Custom USBH Class Driver Definitions

closed by #2222, thank you @rppicomidi for your work. If posible, please keep the midihost pr open, I really want to merge that one, but haven't got time just yet due to crzay work previously. Will try to wrap it up soon enough. You can actual use external for developement since external has more priority than built-in, and we could sync once after a while or so. That would allow to more peoeple to work on the driver.

fallow birchBOT
robust walrus
#

The crash I was seeing was done by connecting a second CP device to the first

jolly scroll
#

ah, we are in luck then, i also have a sparkfun pro micro rp2040

#

so i can just build for the other board, and connect them together

jolly scroll
#

if its anything like what i saw during the livestream, the pio-usb is sending a double setup due to a missed ack

#

and the TUD stack gets upset by that, while a real usb device doesnt

#

but i need some sleep first

fallow birchBOT
#
harbaum
[hathach/tinyusb] Issue opened: #2224 Support for Bouffalo BL616 EHCI host

Related area

Run complex (hub/multidevice) setups connected to the BL616 host

Hardware specification

BouffaloLabs BL616

Is your feature request related to a problem?

I recently stumbled upon the BouffaloLabs BL616 which is a cheap Risc-V microcontroller coming with WiFi and Bluetooth and some other interesting peripherals incl. a EHCI controller. The BL616 seems to target the same audience as the ESP32 and is roughly comparable.

This BouffaloLab SDK comes with cherryUSB ...

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

At this point, this pull request is obsolete. Merged pull request #1434 implemented RP2040 bulk endpoints more cleanly. Some of the other changes I made are either already in TinyUSB from other pull requests or have been implemented in TinyUSB in an equally functional way. Pull request #1627 fixed several bugs in this pull request. Finally, I have used the code from #1627 to create this application host driver; the driver also implements BULK IN ...

fallow birchBOT
#
lfs911
[hathach/tinyusb] Issue opened: #2226 When the config descriptor length for F1C100s is set to 64, it is unable to respond to the BOS.

Operating System

Windows 11

Board

f1c100s

Firmware

hid generic inout and vendor

What happened ?

I am using F1C100s as the chip for my project. When I use the "hid inout" interface alone or use the vendor interface, which means the USB device has only one interface, everything works perfectly. However, once I set up "hid inout" as interface 1 and vendor as interface 2, tinyusb doesn't respond to the TUSB_DESC_BOS request. I noticed that at this point, CONFIG_TOTAL_LEN ha...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-max3421e-hcd
fallow birchBOT
fallow birchBOT
#
RobertDaleSmith
[hathach/tinyusb] New comment on issue #2163: HID host issues with RetroFlag Classic USB Gamepad

I can confirm this issue on the RetroFlag SNES controller and various 8Bitdo controllers that all seem to exhibit the same boot behavior of cycling through different modes.

I first noticed this issue in the 8BitDo Wireless Adapter 2's latest firmware updates. Then more recently the 8BitDo Ultimate C wired controller and the 8BitDo NEOGEO controller both crash TinyUSB.

When I turn on full logs I can see it hits a *** PANIC *** error stating Invalid speed right before it l...

fallow birchBOT
#
rgrr
[hathach/tinyusb] Pull request opened: #2227 Rewrite of NCM device driver

Describe the PR
This is a rewrite of the original NCM device driver. You can check tests concerning functionality and performance here.

Additional context
Buggyness of the current driver can be easily verified with for MSS in 100 200 400 800 1200 1450 1500; do iperf -c 192.168.14.1 -e -i 1 -M $MSS -l 8192 -P 1; sleep 2; done.

I'm using the driver in my own [project](h...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] New comment on commit `5ca748a`

@hathach
Can you please explain why the buffer was renamed? Now the naming is wrong. The buffer represents the transfer buffer and so is independent of the transaction size (the size of the endpoint and so wMaxPacketSize). If the transaction buffer is smaller than the transfer buffer the transfer is split by the host driver into multiple transactions for the HID class.
Meaning the proper name should be transfer_in_buf and transfer_out_buf while the define can be `CFG_TUD_HID_TRANSFE...

fallow birchBOT
fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Hmmm, does anybody read this?

I want to make a proposal: the ncm_device driver seems to be very buggy, e.g. it operates on incoming frames while the previous one is still processed, also it does no ZLP insertion where it should insert one. These bugs are the cause for the above described hickups.

I have implemented a simple version of the driver, which allows only one ethernet frame on reception/transmission.

This would put the focus on reliability, not so much on perfo...

#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Hmmm, does anybody read this?

I want to make a proposal: the ncm_device driver seems to be very buggy, e.g. it operates on incoming frames while the previous one is still processed, also it does no ZLP insertion where it should insert one. These bugs are the cause for the above described hickups.

I have implemented a simple version of the driver, which allows only one ethernet frame on reception/transmission.

This would put the focus on reliability, not so much on perfo...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Yup I am using standard lwip webserver example from TinyUSB and iperf application from lwip-contrib/examples/lwiperf

I am executing following command.
for MSS in 100 200 400 800 1200 1450 1500; do iperf -c 192.168.7.1 -e -i 1 -M $MSS -l 8192 -P 1; sleep 2; done

Here are the logs that I am getting.

Iperf logs

WARNING: attempt to set TCP maximum segment size to 100, but got 536
------------------------------------------------------------
Client connecting to 192....
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

ooopssss... and the example is running with ECM/RNDIS?

"request blocked" is not bad, but the "VALIDATION FAILED" messages are fatal. Possible reasons that come to my mind:

  • bad glue code (but if ECM/RNDIS are working this should not be the case)
  • memory alignment problem of the buffer (when I'm counting correctly, the ncm_interface buffers could land at an 16bit boundary if the struct is packed)
  • buffer is not valid (but why?)

What I also do not understand is "WARNING: attempt ...

fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

It is possible, that I have created a dependency of the driver with my glue code to TinyUSB. The suspicious part looks like:

static void context_tinyusb_linkoutput(void *param)
/**
 * Put \a xmt_buff into TinyUSB.
 *
 * Context: TinyUSB
 */
{
    if ( !tud_network_can_xmit(xmt_buff_len)) {
        //printf("context_tinyusb_linkoutput: sleep\n");
        vTaskDelay(pdMS_TO_TICKS(5));

        taskDISABLE_INTERRUPTS();
        usbd_defer_func(context_tinyusb_linkoutput, NU...
fallow birchBOT
fallow birchBOT
#
hildenborg
[hathach/tinyusb] Issue opened: #2232 USB Host device enumeration gets wrong address.

Operating System

RaspberryPi OS

Board

Rasberry pi pico

Firmware

any

What happened ?

Function "get_new_address" in "usbh.c" is bugged and delivers wrong address.
It tests for a usb host device that is not connected, and then returns that device address + 1.
It looks like the idea is to not return a 0 which later is tested as illegal address.
However, the next time a call is made to "get_new_address", the same unconnected device is found and the same device address + 1...

fallow birchBOT
fallow birchBOT
#
hinxx
[hathach/tinyusb] Issue opened: #2233 TMC device does not perform clear

Operating System

Linux

Board

RPi Pico

Firmware

examples/device/usbtmc

What happened ?

When issuing read() to provoke timeout the device becomes unusable. It does not respond to new commands anymore; needs to be power cycled.

How to reproduce ?

Issue read() without prior write(). The command will timeout. Trying to do a clear() with result in endless messages from host to device without positive result ; i.e. any new command results in timeout. See log files for st...

fallow birchBOT
fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

rgrr,

I confirmed that , lwip-webserver is also running fine on my platform.

"WARNING: attempt to set TCP maximum segment size to 100, but got 536". That also indicates that something is really wrong.

I suspect that this definitely indicates some problem. Also it works for smaller segment sizes but as I increase the segment size the bandwidth decreases and later point driver just crashes.

:(
I need to thoroughly understand the code changes that you made and what problems i...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2168 Added support for the NXP K64 series

thank you very much for your PR. I have rename the option from OPT_MCU_KINETIS_K64 to simply OPT_MCU_KINETIS_K since it seems to be the name of family of those m4f.

I have tried to add kinetis_k to bsp with teensy_35 board to test with this PR. Unfortunately teensy 3.5 is not able to blink led with board_test example. It is probably due to clock config. I push the changes anyway, will try to find an k64f board later to test with. Menanwhile please be patient.

fallow birchBOT
#
klaus-liebler
[hathach/tinyusb] Issue opened: #2236 TU_ASSERT(epnum < EP_MAX) in dcd_synopsys.c fails

Operating System

Windows 11

Board

DevEBox STM32F407

Firmware

Created very basic test project with STM32CubeIDE and followed https://github.com/hathach/tinyusb/discussions/633 with current master branch. Used https://github.com/hathach/tinyusb/tree/master/examples/device/cdc_dual_ports as template.

Relevant/modified lines in tusb_config.h are:

#define CFG_TUSB_MCU OPT_MCU_STM32F4
#define CFG_TUSB_RHPORT0_MODE       (OPT_MODE_DEVICE | OPT_MODE_FULL_SPEED)
#define CFG...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

:( I need to thoroughly understand the code changes that you made and the specific problems it is fixing in the original ncm driver. After this only I will be able to better deduce what is causing this problem. Is it the TinyUSB ? or class driver ? Or my device specific dcd.c implementation.

Please consider ncm_device as a rewrite. I have dropped more or less the original and started fresh but used the original as a template for some things.

Problem with the original ncm_device was, ...

fallow birchBOT
fallow birchBOT
#
Jajcus
[hathach/tinyusb] Issue opened: #2237 rp2040 host won't work with 'tracer CH4' hub

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

examples/host/cdc_msc_hid

What happened ?

When hub is connected device seems stuck in a loop instead of detecting the hub connected. When disconnecting the hub it panics with 'Invalid speed'. The same hub works correctly with Linux PC, a different hub works with the same Pico.

How to reproduce ?

  1. compile the example with: make BOARD=raspberry_pi_pico all LOG=2
  2. flash it to the Rasbperry Pi Pico
    3....
fallow birchBOT
#
XelaRellum
[hathach/tinyusb] New comment on issue #1018: stm32_fsdev builded by keil with --gnu option - enumeration fails

I think the problem here is the different semantics of weak functions in Keil and in the GCC.

I solved the problem by removing TA_ATTR_WEAK from:
void dcd_edpt0_status_complete(uint8_t rhport, tusb_control_request_t const * request);

In usbd_control.c I added an empty, yet weak declaration:
TU_ATTR_WEAK void dcd_edpt0_status_complete(uint8_t rhport, tusb_control_request_t const * request)
{
(void)rhport;
(void)request;
}

In "usbd_control_xfer_cb" I removed the check for the...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
XelaRellum
[hathach/tinyusb] New comment on pull request #2239: Fixes #1018 the weak dcd_edpt0_status_complete for Keil Compiler

Yes and I have tried this in the code, with Keil and with STM32CubeIDE GCC (since I needed this in my project right now)...

Am 30. August 2023 05:06:15 MESZ schrieb Ha Thach @.***>:

@hathach commented on this pull request.

Thank you for the Pr. Do you check with official doc from keil for this behavior for declared weak function ?

--
Reply to this email directly or view it on GitHub:
https://github.com/hathach/tinyusb/pull/2239#pullrequestreview-1601789495
You are receiv...

fallow birchBOT
fallow birchBOT
#
XelaRellum
[hathach/tinyusb] New comment on pull request #2239: Fixes #1018 the weak dcd_edpt0_status_complete for Keil Compiler

can you please provide link to keil's official doc for the behavior ?

As usual, the documentation is a bit cryptic:

https://developer.arm.com/documentation/101754/0620/armclang-Reference/Compiler-specific-Function--Variable--and-Type-Attributes/--attribute----weak---function-attribute

Also on the same topic:

https://stackoverflow.com/questions/51656838/attribute-weak-and-static-libraries

In my understanding the problem is the difference of the weak declaration vs. the weak de...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] Issue opened: #2240 nRF5x: race condition in dcd_nrf5x.c

Operating System

Windows 10

Board

PCA10056 (nRF52840 Nordic DK)

Firmware

Firmware provides a USB-CDC and puts the received data onto BLE.

The host software opens the COM port, does some communication and closed the COM port. This in a loop.

What happened ?

The communication on device side hangs after a while (depending on luck after 5x the above loop or 200x). It seems that especially the disconnect causes the hangup condition.

Used compiler is clang. Several v...

fallow birchBOT
#
XelaRellum
[hathach/tinyusb] New comment on pull request #2239: Fixes #1018 the weak dcd_edpt0_status_complete for Keil Compiler

Right now I am progressing further with the project and I now realize the scope of the problem is bigger. My first thought was, the function above is the only one that is really needed for an implementation. But now I have come to realize TU_ATTR_WEAK functions are all over the place (well, at least several of them).

So, the right thing to do would be to change the semantics of all the callbacks and provide a default implementation for any callbacks that are optional. The return value of t...

fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

I have taken a reference of glue logic from
https://github.com/rgrr/yapicoprobe/blob/feature/minor-cleanup/src/net/net_glue.c

Implemented the same.

As I increased the TinyUSB buffer size, the test case work for all segment size. :smiley:

iperf command used:

for LEN in 40000 16000 1400 1024 800 200 80 22 8 2 1; do for MSS in 90 93 100 150 200 255 256 300 400 500 511 512 600 700 800 900 1000 1100 1200 1300 1400 1450 1459 1460 1500; do iperf -c 192.168.14.1 -e -i 1 -l $LE...
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Actually I have no idea what the bottleneck could be. Have you checked the wireshark log if you see the expected? Perhaps your iperf behaves not as you want.

Your iperf output:

Client connecting to 192.168.7.1, TCP port 5001 with pid 1792756
Write buffer size:  100 Byte
TCP window size: 40.0 KByte (default)

Mine (2.1.9):

Client connecting to 192.168.14.1, TCP port 5001 with pid 18915 (1 flows)
Write buffer size: 40000 Byte
MSS req size 600 bytes (per TCP_MAXSEG)
...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2239: Fixes #1018 the weak dcd_edpt0_status_complete for Keil Compiler

Your link is pointed to armclang (which is different from keil armcc). From keil doc, look like it should work well with current code https://developer.arm.com/documentation/dui0375/g/Compiler-specific-Features/--weak

__weak
This keyword instructs the compiler to export symbols weakly.

The __weak keyword can be applied to function and variable declarations, and to function definitions.

Usage
Functions and variable declarations
For declarations, this storage class specifies an...
fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Actually I have no idea what the bottleneck could be. Have you checked the wireshark log if you see the expected? Perhaps your iperf behaves not as you want.

Tried with iperf 2.1.9 same result

  • According to analysis, this version of ncm driver is definitely much better than previous version.
    Can you explain what is the expectation with glue code logic ? So that if possible we can think in that direction.

Also with little clean up https://github.com/hathach/tinyusb/pull/2227 ...

fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Expectations with glue logic: there should be an official call to put an event into the TinyUSB event queue so that one get into the context of TinyUSB. lwIP API offers tcpip_try_callback() or tcpip_callback(). Currently one has to use usbd_defer_func() which is actually TinyUSB private and also does just block USB interrupts.

Clean up: will follow soon.

Currently I cannot see any further improvement. Perhaps wider use of the net_device will open some new wishes/issues.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
RobertDaleSmith
[hathach/tinyusb] New comment on issue #1808: N-Key-Rollover

What about in the case of using TinyUSB as a host device reading a HID keyboard? Appears the built-in support is for hid keyboard boot mode which reports only 6 keys. From what I understand there is a command that must be sent to a keyboard from a host device to enable full NKRO mode. Is this correct and are there any known examples?

fallow birchBOT
#
Keval-Joshi-TI
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

This would improve compatibility over the several OSes, because NCM is supported by Linux, MacOS (AFAIK), Win11 (AFAIK) and Win10 (with minor driver installation).

As far as I know RNDIS is windows standard offering and Linux also supports RNDIS by default. Where as in NCM extra driver installation is required. Thus it is okay to keep RNDIS as default.

: how about adding iperf to the webserver example to get a reference example for performance measurements?

lwip Iperf will be ...

fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

yes, that is a valid point: RNDIS is correctly detected by Win10. But there are some drawbacks: RNDIS changes somehow routing of my Linux desktop (Debian) and also RNDIS works only under Win10 if it is the only class of the USB device. So actually not a generic solution.

Nevertheless as an example RNDIS should do it.

But: those examples aren't just examples. To my understanding they are also some kind of compilation test. So if all examples go for RNDIS, the NCM device will not be c...

fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

@Keval-Joshi-TI : "funny" thing, if you limit in lwiperf_tcp_client_send_more() (in lwiperf.c) the txlen_max to 700 (instead of TCP_MSS) then iperf -c 192.168.14.1 -e -i 1 -M 100 -l 8192 -r succeeds.

Don't know yet, if this indicates a bug in lwiperf, lwIP, TinyUSB or the device driver (but ECM shows the same behavior).

Comparing ECM / NCM shows that NCM is factor 4 better in direction device -> host.

PS: actual problem is, that tcp_output() does not create a lwiperf_tcp_client_sen...

fallow birchBOT
#
joshikeval3131
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Hardy: I am stuck at more basic problem.

Even with your suggested change int the lwip example DEV-> HOST transfer is not happening in my case :(

------------------------------------------------------------
Client connecting to 192.168.7.1, TCP port 5001 with pid 3025046 (1 flows)
Write buffer size: 8192 Byte
MSS req size 100 bytes (per TCP_MAXSEG)
TOS set to 0x0 (Nagle on)
TCP window size: 16.0 KByte (default)
------------------------------------------------------------...
#
Keval-Joshi-TI
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

Hardy : I am stuck at more basic problem.

Even with your suggested change int the lwip example DEV-> HOST transfer is not happening in my case :(

------------------------------------------------------------
Client connecting to 192.168.7.1, TCP port 5001 with pid 3025046 (1 flows)
Write buffer size: 8192 Byte
MSS req size 100 bytes (per TCP_MAXSEG)
TOS set to 0x0 (Nagle on)
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
maidnl
[hathach/tinyusb] Pull request opened: #2245 Fix msd extraneus bytes on reading

Fix the fact that MSD status msg sometimes goes in the payload of data read from disk

This fixes: https://github.com/arduino/ArduinoCore-renesas/issues/84
The problem: when issuing a reading command on MSD class, sometimes data read form disk (QSPI flash device) are corrupted with status message (the one that should "end" the transmission of data read from disk, i.e. "USBS..."). According to our analysis this is due to the fact given that MSC_STAGE_STATUS case is executed always "after" t...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #2245: Fix msd extraneus bytes on reading

I guess that the following place is good to wait for the HW pipe FIFO to be empty. At the last packet of an IN transaction, it will wait for the HW pipe to be empty.

https://github.com/hathach/tinyusb/blob/7bf5923052e5861f54c9cb0581e328f8be26a0a9/src/portable/renesas/rusb2/dcd_rusb2.c#L343

if data are still present in the hw pipe fifo while the status message is sent by the function, the status message overwrites part of the data present in the hw pipe fifo.

For efficient handling ...

fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

gosh... sometimes it is more complicated... I have to correct myself: the above loop does not work, the one with the usbd_defer_func() is the correct one. And this is also true for ECM/RNDIS: they do fine with the defer loop but not with the simple loop from above. I will investigate this further if there is time, but I guess the simple loop blocks TinyUSB while it actually wants something to do. The problems appears for ECM immediately, for NCM (because of better buffering) for very smal...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-cmake-samd
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Keval-Joshi-TI
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

@rgrr :

Concerning lwiperf: the problem with the sender operations lies within the condition of the do-while-loop in lwiperf_tcp_client_send_more(). The condition txlen >= (TCP_MSS / 2) is too limiting, because for -M 100 the call to tcp_write() does not succeed and thus there is no data in the buffer which stops transmission.
Replacing the above condition with txlen != 0 solves this and lwiperf sends data correctly.

Even with above mentioned change rx is not working in my case.
...

fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

My device is a Raspi Pico (RP2040), i.e. dual-core Cortex-M0. TinyUSB has higher priority than lwIP. I will test, if it matters which process has higher priority (both processes are limited to one core).

lwiperf: I inserted several printf() for debugging. They pointed very fast to the loop in lwiperf_tcp_client_send_more().

What is your current glue code? Especially if you are using TinyUSB I would use mine ;-)

fallow birchBOT
fallow birchBOT
#
OrhanYigitDurmaz
[hathach/tinyusb] Issue opened: #2247 16 Bit Resolution Support?

Related area

Please add 16 or 12 bit Analog Trigger Resolution

Hardware specification

rp2040

Is your feature request related to a problem?

I was using the arduino leonardo with Joystick library for my project, which had 16 bit res. support. Now i shifted to the RP2040 platform, i miss that 16 bit resolution support. The arduino-pico core and Pico SDK all use 8 bit internally, which are all derived from you.

Describe the solution you'd like

instead of uint8_t use uint16...

fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

@kripton : does it mean that you are using the new NCM device?

It did not do any tests with your project although I like your work. I stopped when "make" asked for npm :-/

Nevertheless your glue code points me into the direction why the simple loop from above did not work: the call to tud_task() was missing.

Corrected version looks like this:

static void context_tinyusb_linkoutput(void *param)
/**
 * Put \a xmt_buff into TinyUSB.
 *
 * Context: TinyUSB
 */
{
    whil...
#
kripton
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

@kripton : does it mean that you are using the new NCM device?

No, i'm using the original, first version and I did notnface any problems with it.

It did not do any tests with your project although I like your work. I stopped when "make" asked for npm :-/

True, dmxsun is compiling a React web app, Sorry, I know it causes additional effort.

Nevertheless your glue code points me into the direction why the simple loop from above did not work: the call to tud_task() was missing....

fallow birchBOT
#
rgrr
[hathach/tinyusb] New comment on issue #2068: CDC-NCM poor performance for known reasons

@kripton : does it mean that you are using the new NCM device?

No, i'm using the original, first version and I did notnface any problems with it.

You will stumble into problems if the transmitted packets are coming fast and in different sizes. My initial application was SystemView.

Nevertheless your glue code points me into the direction why the simple loop from above did not work: the call to tud_task() was missing.

So does it solve your problems with the origina...

fallow birchBOT
fallow birchBOT
#
Protoxy22
[hathach/tinyusb] New comment on pull request #1463: changes proposal to audio feedback computation

@HiFiPhile do you have an example code on how to calculate feedback on fifo count work ? I will try to find a way to fit it as well or give some option to do so.

Full code is in https://github.com/HiFiPhile/i2s_bridge, UAC related code is in audio_callbacks.c

1. I defined a feedback min/max of 0.1%, in USB HS spec clock deviation is 0.05% so 0.1% should be good if same type of oscillator is used for MCLK.
   https://github.com/HiFiPhile/i2s_bridge/blob/1d6a24fdd...
fallow birchBOT
fallow birchBOT
#
maidnl
[hathach/tinyusb] New comment on pull request #2245: Fix msd extraneus bytes on reading

I made the changes you suggested and tested them on our device. Now the wait function is static in the RA file dcd_rusb2.c and used in the point you mentioned in the comment. The MSD result untouched in this way and all the changes are only for renesas.

In case you prefer some changes to this to better fit the overall architecture please let me know and I will test them on our device. Thanks.

fallow birchBOT
fallow birchBOT
#
maidnl
[hathach/tinyusb] Pull request opened: #2248 renesas: support micros with different number of HW pipes

renesas: add support for renesas micro with different number of USB hw pipes

not all renesas micro have the same number of pipes as expected by the find_pipe function.
For example see RA4M1 micro which only have 2 bulk pipes and 2 interrupt pipes.
For this reason some defines were introduced so that the actual number and positions of USB HW pipes can be defined at build time for different kind of processor.

If you prefer a different approach please let me know. I will try to impleme...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
onurdof
[hathach/tinyusb] Issue opened: #2250 HID Haptics Implementation

Related area

Report descriptor for gamepad

Hardware specification

esp32s3

Is your feature request related to a problem?

Hello I want to provide haptics to my gamepad and I did not find how to do that. How can I configure that ?
It is good to implement some macro for that like below.
#define TUD_HID_REPORT_DESC_GAMEPAD(...)
HID_USAGE_PAGE ( HID_USAGE_PAGE_DESKTOP ) ,
HID_USAGE ( HID_USAGE_DESKTOP_GAMEPAD ) ,
HID_COLLECT...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2251: Add max3421e host driver

For now, you need to enable the host driver with CFG_TUH_MAX3421=1, this will also include driver internal data https://github.com/hathach/tinyusb/blob/master/src/portable/analog/max3421/hcd_max3421.c#L205. If you want to supply the internal data when needed we probably need some kind of malloc-like callback (malloc when init host stack, free when de-init). It will probably need its own PR since there is a few request for more dyanmic memory for class drivers (since not all enabled driveres...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rsolorzanomsft
[hathach/tinyusb] Pull request opened: #2252 Add HID Lighting and Illumination functionality

Describe the PR
This PR adds Lighting and Illumination usage page and descriptor template for HID class.

Additional context
The descriptor in hid_device.h was taken from the lighting and illumination page, and all definitions in hid.h are taken from there as well. Adding this functionality allows TinyUSB devices that have lighting capabilities to be controlled by the host machine. In Windows, ...

fallow birchBOT
#
Rocky04
[hathach/tinyusb] Pull request opened: #2253 HID class driver fixes

Addressing some drawbacks of the HID class driver implementation.

  • Fixing that the tud_hid_set_report_cb callback would always inform about an invalid result state if a dedicated OUT endpoint is used. In the case the optional OUT endpoint is used outgoing transfers are then handled by hidd_xfer_cb and not by hidd_control_xfer_cb anymore. Then the HID examples wouldn't work anymore because the result state wouldn't be right.
  • Only invoke tud_hid_report_complete_cb and `tud_hid_se...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
laf0rge
[hathach/tinyusb] Issue opened: #2255 resetting DATA PID toggling to DATA0 after SET_INTERFACE

Operating System

Linux

Board

raspberry pico (rp2040)

Firmware

any tinyusb firmware as long as it uses the usbd.c default handling of TUSB_REQ_SET_INTERFACE and doesn't override that in a driver specific control endpoint handler call-back.

What happened ?

It is my understanding that after any configuration event (to which SET INTERFACE belongs), the endpoints belonging to that interface re-start from DATA0.

See USB Spec 9.1.1.5: _configuing a device or changing an alt...

#
laf0rge
[hathach/tinyusb] New comment on issue #2255: resetting DATA PID toggling to DATA0 after SET_INTERFACE

FYI: I tried to add related code, but I couldn't even find any dcd_* API from the low-level drivers to the generic usbd.c which would be used to reset the DATA toggle state.

The below diff illustrates how one can get notifications from the rp2040 usb device peripheral about those data toggle errors (the commented-out panic was from the hcd which interestingly does enable those error interrupts, while the dcd doesn't):

diff --git a/src/portable/raspberrypi/rp2040/dcd_rp2040.c b/src/p...
#
laf0rge
[hathach/tinyusb] New comment on issue #2255: resetting DATA PID toggling to DATA0 after SET_INTERFACE

One way of looking at the problem is the fact that the default usbd code blindly acknowledges all SET_INTERFACE requests. The USB spec chapter 9 explicitly states that for interfaces with only one altsetting the device may simply stall rather than acknowledging the request. This way the data toggling state on the host/bus presumably shouldn't change.

However, this wouldn't be a true fix for any application that actually uses multiple different altsettings (like vendor specific drivers).
...

fallow birchBOT
#
laf0rge
[hathach/tinyusb] New comment on issue #2255: resetting DATA PID toggling to DATA0 after SET_INTERFACE

see below for a control_xfer_cb of a custom driver which overrides the usbd.c default handling (returning true in the SETUP stage) and then later returns false in the ACK/Status stage. This way the host sees the SET_INTERFACE failing, and will not change the data toggling.

static bool cardemd_control_xfer_cb(uint8_t __unused rhport, uint8_t __unused stage, tusb_control_request_t const *request)
{
        switch (request->bmRequestType_bit.type) {
        case TUSB_REQ_TYPE...
fallow birchBOT
#
XZCE
[hathach/tinyusb] New comment on issue #1883: [RP2040] First byte of X52 Pro HID report is zero, unless CFG_TUSB_DEBUG >= 2.

dump.txt

This is a ShanWan (PS3) wireless controller, it configures EP 0x81 & 0x02 as 32 bytes longs, but by my calculations the HID report is 35 bytes long and I suspect those extra 3 bytes make the Pico's USB device hold the EP inactive...

Normally, it crashes the Pico on these assert &| panic lines (which I've disabled for this dump, because I don't want my Pico to crash if a user plugs in such a device, and in the logging...

fallow birchBOT
fallow birchBOT
#
klaus-liebler
[hathach/tinyusb] Issue opened: #2256 audio_4_channel_mic on STM32F411 with modified tud_audio_tx_done_post_load_cb

Operating System

Windows 11

Board

BlackPill F411

Firmware

audio_4_channel_mic example (unmodified and modified, see below)

What happened ?

I successfully integrated the audio_4_channel_mic example in a new STM32CubeIDE project and used "plot_audio_samples.py" to test it. When I looked at the plot, I saw that the value 1 remains constant for two samples (see marking in the screenshot below). According to the source code, the value 1 should only be displayed for one sampl...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-max3421-esp32
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: cmake-u5
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #2255: resetting DATA PID toggling to DATA0 after SET_INTERFACE

yeah, you are right, we should reset DATA toggle when received SET_INTERFACE request, it should be done by either usbd or class driver and an additional dcd_edpt_reset_toggle() should be addded. Could you explain a bit on your configuration descriptor/driver, and how you setup/test, it would be helpful if you have an ready to build/test example/repo so that I could work on and verify the fix.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
eivindbohler
[hathach/tinyusb] New comment on issue #1673: Support two physcial host ports on the RP2040 (native and pio)

I've started to look at how I can get both the native USB host and the Pico PIO USB host up and running at the same time on the RP2040. My use case is as a HID controller for keyboard + mouse on a retro ITX motherboard I'm making (https://www.vogons.org/viewtopic.php?t=93480). I find it quite challenging however, because of how mutually exclusive the two solutions are set up to be for the RP2040 specifically, and generally how TinyUSB doesn't yet support two host controllers. In also not that...

fallow birchBOT
fallow birchBOT
#
eivindbohler
[hathach/tinyusb] New comment on issue #1673: Support two physcial host ports on the RP2040 (native and pio)

@tannewt Because not having to rely on a hub is arguably the better solution. I mean, if this can be done in software then why not?
As for hubs, I assume most external ones would probably work just fine - but the fewer external dependencies the better. I could also use an internal hub chip I guess. The problem with that is that it would break being able to reprogram the rp2040 over the native USB port (using the BOOTSEL button/signal).

At a high level - both the rp2040 and the TinyUSB l...

fallow birchBOT
#
Firmware-beginner
[hathach/tinyusb] Issue opened: #2261 How to compile tinyusb-master -> examples with esp32

Operating System

Windows 10

Board

No board used till now

Firmware

tinyusb-master\examples\host\cdc_msc_hid\src

What happened ?

Aim is to build the above project.
I'm using esp-idf 5.1 CMD. Tried to do idf.py set-target esp32s3 but getting a Cmake error. How to fix this error.

Error :
You must set a FAMILY variable for the build (e.g. rp2040, eps32s2,
esp32s3). You can do this via -DFAMILY=xxx on the cmake command line

How to reproduce ?

  1. Open esp-i...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1673: Support two physcial host ports on the RP2040 (native and pio)

@hathach, what's your take on this? Do you feel it makes the most sense to try to get the Pico PIO host working "alongside" and as decoupled from the native host as possible, or put in place a more general support for multiple host controllers? I'd imagine the latter being more elegant and potentially useful for other boards as well, but I'm sure harder to achieve.

native usb controller + pio-usb host can coexist, treated as mixed host controllers. There are more MCUs with mixed controll...

fallow birchBOT
#
bencowperthwaite
[hathach/tinyusb] Pull request opened: #2265 STM32U5 HS Support

Added support for USB2 HS peripheral (with integrated HS PHY) on STM32U59x & STM32U5Ax chips.

Describe the PR
The latest additions to the STM32U5 family have an OTG_HS peripheral (replacing the OTG_FS peripheral).
This requires modifications to the dwc2_stm32.h to reflect the lack of OTG_FS defines and set up the HS defines correctly.
I tried to keep this looking/feeling similar to the OPT_MCU_STM32H7 case above it.

Additional context
In my tusb_config.h (for device only) I ...

fallow birchBOT
#
samspencer5991
[hathach/tinyusb] Issue opened: #2266 CDC data lost/truncated with consecutive full packet writes

Operating System

Linux

Board

Custom STM32G491 board

Firmware

size_t CustomWriter::flush()
{
	size_t num = tud_cdc_n_write(0, txBuf, numBytes);
	tud_cdc_n_write_flush(0);
	numBytes = 0;
	return num;
}

size_t CustomWriter::writeBuffer(const uint8_t *buffer, size_t length)
{
               ... 
               // Copy as many bytes as will fit into the buffer and transmit
		uint16_t remainingBytes = 64 - numBytes;
		memcpy(&txBuf[numBytes], modBuffer, remaining...
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-in_isr-to-hcd_int_hanlder
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
glass mist
#

Hey folks. I'm using both the Adafruit TinyUSB library, and vanilla version for projects. Getting stuck into an ESP32-S3 board and having some issues with the Adafruit TinyUSB library inside PlatformIO. I've scoured the forums and GH but no dice.
I'd like to use the Adafruit version as it incorperates a little more nicely with the MIDI library and various transports. I've played with the USB mode, different include options as well as the include file trick mentioned on the PIO forums, but still won't compile. The particular error is: "TUP_DCD_ENDPOINT_MAX is not defined for this MCU, default to 8". I also can't see 'OPT_MCU_ESP32S3' defined anywhere. It seems to indeed be an issue with the library linking order or clashign with the IDF TinyUSB.

From a few forum threads it indicates that a fix has been merged, but even on the latest version, the behaviour is the same.

fallow birchBOT
#
shuffle2
[hathach/tinyusb] Issue opened: #2273 rp2040: HID output report race condition

Operating System

Others

Board

raspberry pi pico W

Firmware

using pico-sdk 1.5.1

What happened ?

I'm writing firmware for the pico which talks to pre-existing software on a usb host (read: I cannot change or easily inspect the host software/stack).

The host regularly sends HID output reports to the pico. At the same time, it also sends SET_ and GET_ FEATURE_REPORT reports. What I observe is that occasionally while I am processing a SET_FEATURE, the underlying buffer g...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more-esp32-max3421
fallow birchBOT
fallow birchBOT
#
u77345
[hathach/tinyusb] Issue opened: #2274 Async trigger for USB488 SRQ transmission

Related area

USB488 / USBTMC

Hardware specification

all

Is your feature request related to a problem?

n/a

Describe the solution you'd like

Adding support to asynchronously trigger sending a status byte on the interrupt endpoint, to indicate a USB488 SRQ condition, that occurs in the usbtmc application level.

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked existing issues, dicussion and documentation.
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Lotharyx
[hathach/tinyusb] Issue opened: #2277 examples/device/cdc_msc_freertos does not compile for stm32f439nucleo as-is

Operating System

Linux

Board

ST STM32F439-Nucleo

Firmware

examples/device/cdc_msc_freertos

What happened ?

Following output from make BOARD=stm323f439nucleo all

buildlog.txt

WORKAROUND: Disable maybe-uninitialized as an error by adding to Makefile:
CFLAGS_GCC += -Wno-error=maybe-uninitialized

How to reproduce ?

  1. git clone https://github.com/hathach/tinyusb
  2. `cd tinyusb/examp...
fallow birchBOT
fallow birchBOT
#
Krasutski
[hathach/tinyusb] Pull request opened: #2278 Feature/ch32f20x

CH32F20x MCU family support
Added support of CH32F2 MCUs

Current code already support WCH CH32V3 chip, this MCU have the same USB HS core as CH32F20x therefore I just moved portable/wch/ch32v307/dcd_usbhs.c file to common folder(portable/wch/dcd_ch32_usbhs.c) and add libs for CH32F2xx

image

This my first Pull Request to tinyusb, please let me know If I missed something

fallow birchBOT
jolly scroll
#

pi5 also complicates matters, by having 2 xhci controllers, each driving half the usb-a ports

#

so you would need a more complex xhci driver, that can manage multiple controllers at once

robust walrus
#

only if you want pi5 support from the get go

#

pi400 would be very cool

#

you should let them know that tinyusb does run bare metal on the pi

#

just not with pcie or xhci support

jolly scroll
#

@robust walrus i also had an idea before, not sure i mentioned it, on how to deal with multiple controllers and different hcd's

what if the normal set of hcd functions, re-route the call to the right hcd, based on the root port number
so root port 0 goes to the dwc hcd
root port 1 goes to the 1st xhci
and root port 2 goes to 2nd xhci

#

then a single tinyusb host stack could drive multiple controllers

#

by adding a state pointer, and mapping the root ports over, i think it could easily expand to handle multiple controllers

robust walrus
#

@jolly scroll it is worth proposing to thach

#

probably worth filing an issue

jolly scroll
#

i'll try to pop one open tonight

fallow birchBOT
#
pauleffect90
[hathach/tinyusb] New comment on issue #458: zephyr port

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.

Thank you kindly for your work. You're awesome. Can't wait to finally be rid of that god-awful zephyr usb stack.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2259: Fix UAC encoding, update example.

@PanRe Thanks for your quick return :)

I'll try to optimize IN transfer data flow in a following PR.

For TYPE-I format the allowed sample in each packet is n<sub>avg</sub>+-1, for example 48kHz with a FS device gives 47~49 samples per packet.
<img width="664" alt="image" src="https://github.com/hathach/tinyusb/assets/4375114/e6fa43b8-7c04-44fe-9a5c-494aea124e0d">

Currently it always try to send all the data in FIFO. If we take example of a 48 sample length I2S buffer, who wri...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #2259: Fix UAC encoding, update example.

Interesting idea, but isn't that what you already implemented in one of your projects? I remember you mentioned something like that for the feedback value calculation?

Nevertheless, I like the idea. However, it introduces a lag and some users might not want that. I know, it is hard to get it working without some kind of buffering. How about defining a minimum buffer fill level? The higher it is, the more robust it gets. For users which don't want a buffering, they can set the fill level to z...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2259: Fix UAC encoding, update example.

Interesting idea, but isn't that what you already implemented in one of your projects? I remember you mentioned something like that for the feedback value calculation?

It was for OUT transfer, in that case user code has the responsibility to calculate feedback correctly. For IN transfer the feedback is implicite, simply determined by how much data is sent.

After thinking current code only support fixed sample rate, it's necessary to calculate n<sub>avg</sub> based on sample rate to le...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #2282 UAC IN transfer improvements

Describe the PR

Currently UAC IN transfer always try to send all the data in FIFO, which comes with 2 issues:

  1. Recorded audio could have glitch depending on I2S clock variation.
  2. Multi-rate (eg. 44.1k & 48k) doesn't work as the packet size is different.

For TYPE-I format the allowed sample in each packet is navg+-1, for example 48kHz with a FS device gives 47~49 samples per packet.

This PR makes IN transfer size honor the constraint and resolve above 2 issues, by select ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
alrvid
[hathach/tinyusb] Issue opened: #2284 Out-of-bounds indexing causes memory corruption

Operating System

Others

Board

Portenta C33 (Renesas)

Firmware

What happened ?

An assert didn't catch out-of-bounds indexing of a multi-dimensional array, which caused memory corruption.

The problem occurs when get_new_address() returns address 5, and that number ends up at this line as dev_addr:

_hcd.ep[dev_addr - 1][dir_in][epn - 1] = num;

in hcd_edpt_open() in hcd_rusb2.c(). It becomes 4 and is then used to index the ep array. There's an assert that checks...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-u5a5
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #2282: UAC IN transfer improvements

Could you explain a bit how the blackout works please?

Well that's something need to be proven :) There are some reasons why I added it:

  • At startup as the FIFO is being filled, short packets will be sent until FIFO half filled, on my Windows machine I observed there are 1 or 2 samples missed when there are too many short packets (maybe it tries to correct clock drift, who knows), while capture shows packets are ok.
    <img width="400" alt="image" src="https://github.com/hathach/tinyus...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #2282: UAC IN transfer improvements

I see, sounds a bit like black magic stuff :)

From my side, I don't have any problems with merging your PR as it is already more robust than the current version. But I am curious, have you already conducted a long term test? Maybe for an hour? Or do you know if Linux works without issues? Lots of time consuming questions I know ;)

In any case, very nice work as usual!!

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

From what I have seen in the datasheet, it looks like the USB peripheral from the H5 might be the same as that in the G0 family (at least register names seem to match) but I haven't looked in the details yet

I have tried replacing G0 with H5 HAL just for a test and also changed:

  • manually edited dcd_stm32_fsdev_pvt_st.h to point to stm32h5xx
  • changed USB_UCPD1_2_IRQn to USB_DRD_FS_IRQn in dcd_stm32_fsdev.c
  • defined "STM32G0" to omit the "USB->BTABLE"

Just by doing these change...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
0x0fe
[hathach/tinyusb] Issue opened: #2285 HOST module UVC video capture on CH32V307

Related area

HOST

Hardware specification

CH32V307

Is your feature request related to a problem?

The status table is unclear about HOST mode on CH32V307 (there is no status). I want to run the video capture example, which is host mode, on ch32v307, if the status could be confirmed it would be nice.

Describe the solution you'd like

video capture example working on ch32v307

I have checked existing issues, dicussion and documentation

  • [X] I confirm I have checked e...
fallow birchBOT
#
MWP
[hathach/tinyusb] Issue opened: #2287 No CDC tud_cdc_rx_cb() callback with 64 bytes of data (or multiple of)

Operating System

Linux

Board

STM32H7 Custom

Firmware

Custom.
Quite simple firmware using a currently days-old pull of tinyusb trunk.
Using the tinyusb provided dcd_synopsys.c

#define CFG_TUSB_MCU OPT_MCU_STM32H7
#define CFG_TUSB_OS OPT_OS_FREERTOS
#define BOARD_DEVICE_RHPORT_SPEED OPT_MODE_FULL_SPEED
#define BOARD_DEVICE_RHPORT_NUM 0
#define CFG_TUSB_RHPORT1_MODE (OPT_MODE_DEVICE | BOARD_DEVICE_RHPORT_SPEED)

define CFG_TUD_ENDPOINT0_SIZE 64

#defi...

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

Klemen, would you mind creating a patch file that captures the changes you made to get the code to compile and run as far as you've described? I have been trying to get just to the point of being able to compile and keep getting stuck. Also could I see your tusb_config.h? Or are you using the one straight from the example?

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
maidnl
[hathach/tinyusb] New comment on pull request #2248: renesas: support micros with different number of HW pipes

Hi! I am really sorry to bother you on this topic again.
I would like to ask you if can reconsider the possibility to merge this PR.
As I wrote in my previous comment I initially mentioned the wrong renesas microcontroller (again I'm sorry for that):
the renesas microcontroller with less pipes is RA2A1 (he really is :-).
I think this PR is required to make possible the use of this renesas microcontroller and I hope you can reconsider it and merge it. This will allow us (Arduino) to swi...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: minor-update-max3421
fallow birchBOT
#
Lotharyx
[hathach/tinyusb] New comment on issue #2203: STM32H5 support

I think I reached the same "built and run" state as Klemen, but nothing happens when I connect the USB cable to the host PC (Windows 10). The tud_descriptor_device_cb callback is not hit. In my case it's a Nucleo board (still H563 chip) that has a Type-C connector for that port. Klemen, does your board use Type-C?

I've started a new discussion here in case I'm pulling this one too far off its original path.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
gustavowd
[hathach/tinyusb] Issue opened: #2298 STM32F429-Disco board support

Related area

new port support

Hardware specification

STM32F429-Disco

Is your feature request related to a problem?

I'm trying to port TinyUSB for the STM32F429 Discovery development board.
Such board uses the rhport = 1 (USB_OTG_HS).

The pins are different from the current port for the STM32F4 family.

__HAL_RCC_GPIOB_CLK_ENABLE();
/**USB_OTG_HS GPIO Configuration
PB13 ------> USB_OTG_HS_VBUS
PB14 ------> USB_OTG_HS_DM
PB15 ------> USB_OTG_HS_D...

fallow birchBOT
fallow birchBOT
#
gustavowd
[hathach/tinyusb] New comment on issue #2298: STM32F429-Disco board support

I manage to get USB to start the enumerate process, but i'm getting this error:
[ 8578.520458] usb 3-4: new full-speed USB device number 46 using xhci_hcd
[ 8578.520627] usb 3-4: Device not responding to setup address.
[ 8578.728658] usb 3-4: Device not responding to setup address.
[ 8578.936488] usb 3-4: device not accepting address 46, error -71
[ 8578.936690] usb usb3-port4: unable to enumerate USB device
[ 8828.424773] usb 3-4: new full-speed USB device number 49 using xhci_hcd
[ 8...

fallow birchBOT
fallow birchBOT
#
gustavowd
[hathach/tinyusb] New comment on issue #2298: STM32F429-Disco board support

STM32F429 doesn't have internal UTMI phy, so even if the port support high speed you are limited to full speed.

Yes, I know that. You can note in the linux dmesg info "new full speed device". I'm using the HS port configured to full speed.

#define BOARD_TUD_RHPORT 1
#define CFG_TUSB_RHPORT1_MODE OPT_MODE_DEVICE
#define BOARD_TUD_MAX_SPEED OPT_MODE_FULL_SPEED

// Enable Device stack
#define CFG_TUD_ENABLED 1
#define TUD_OPT_RHPORT 1

// Default is max sp...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-doc
fallow birchBOT
#
projectgus
[hathach/tinyusb] Pull request opened: #2303 Add optional hooks for DCD and HCD events

These are intended to allow bare metal platforms with one-shot scheduling capabilities to schedule the TinyUSB task handlers whenever they know there is work for them to do.

I've been experimenting with this approach for MicroPython, where we don't usually have an RTOS but we do have scheduling capability. Selectively scheduling tusb_task_ext() to run when we know there are events in the queue reduces latency for processing, while also avoiding the overhead of polling tusb_task_ext() w...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: remove-legacy-st-synopsys-driver
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: minor-upate-max3421
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-u5-uid
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
OpusElectronics
[hathach/tinyusb] Issue opened: #2309 tud_cdc_n_write_flush() blocks if the host isn't pulling data

Related area

CDC device class, probably others

Hardware specification

RP2040

Is your feature request related to a problem?

Unless I have missed something or not done something correctly, it seems that a call to tud_cdc_n_write_flush() can block if the host is not pulling data. I haven't tried yet, but I'm guessing that it's a more general issue that happens with the vendor device class as well, and possibly others.

Not completely sure how to deal with it gracefully. It's d...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-usbh-enumeration-removal-race
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #2310 Fix usbh enumeration removal race

Describe the PR
Fix a race condition where device is removed while enumerating (repeatedly sometimes when plugging in) which cause following symptons

[1:] USBH Defer Attach until current enumeration complete
[1:] USBH Defer Attach until current enumeration complete
[1:] USBH Defer Attach until current enumeration complete
[1:] USBH Defer Attach until current enumeration complete
[1:] USBH Defer Attach until current enumeration complete
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New branch created: typo
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
RobertDaleSmith
[hathach/tinyusb] New comment on issue #2163: HID host issues with RetroFlag Classic USB Gamepad

@RobertDaleSmith this kind of race is hard to troubleshoot without actual hardware. If you can send an hardware in question to me, I will try to take a look. However, there is no guarantee on the ETA at all, and I do live in Vietnam. If you are OK with that, please drop me an email, I will send you the shipping info.

I got you. And no rush. I appreciate you even offering.
robert [at] robert dale smith [dot] com

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2248 renesas: support micros with different number of HW pipes

I just checked the manual for RA2A1, it indeed only support 5 pipes, oddly enough pipe0 then 4-7 (1-3 seems to be not usable). RA2A1 (and other similar mcus) should be detected e.g BSP_MCU_GROUP_RA2A1 and addressed by tinyusb without the need of using external MACRO as suggested change.

I don't have RA2A1 hardware on hand, but I can try to add an bsp for it, and then make some adjumst to pipe allocation for it later on.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-ra2a1-ek
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-imxrt-family
fallow birchBOT
fallow birchBOT
#
byteit101
[hathach/tinyusb] Issue opened: #2322 USB MSC has some sort of race condition

Operating System

Linux

Board

Raspberry Pi PICO (RP2040)

Firmware

https://github.com/byteit101/test-tinyusb-pico

What happened ?

panic/assert/exit calls sometimes, but not always, on writes (I think?).

I have confirmed it on Debian 10, Linux pollux 5.10.0-21-amd64 #1 SMP Debian 5.10.162-1 (2023-01-21) x86_64 GNU/Linux

I haven't seen it on a "blank" flash (no filesystem)

I have confirmed it with G++ 8.3 and G++ 12.2 (the latter requires uncommenting `target_lin...

fallow birchBOT
#
ObligedTester
[hathach/tinyusb] Issue opened: #2323 tuh_hid_set_report to set keyboard LED causes unstable behaviour

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

0.15.0

What happened ?

When using tuh_hid_set_report to set leds, like this sample:

leds = KEYBOARD_LED_NUMLOCK;
tuh_hid_set_report(deviceadress, deviceinstance, 0, HID_REPORT_TYPE_OUTPUT, &leds, sizeof(leds));

It causes erratic behavior with two different keyboards.

I implemented a short program to toggle the leds while pressing a button. It initially seems to work.
But after some toggles, seemi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New branch created: dwc2_f429
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #2328 UAC2: Implement feedback by fifo counting.

Describe the PR
Finally I had time to integrate my feedback work into UAC2 class :)

Compared to other methods the only thing needed is add a callback to set sample rate, all calculations are done inside the class.

void tud_audio_feedback_params_cb(uint8_t func_id, uint8_t alt_itf, audio_feedback_params_t* feedback_param)
{
  // Set feedback methode to fifo counting
  feedback_param->method = AUDIO_FEEDBACK_METHOD_FIFO_COUNT;
  feedback_param->sample_freq = current_sample_...
fallow birchBOT
fallow birchBOT
#
lurch
[hathach/tinyusb] Issue opened: #2330 "Conding" typos

Operating System

Linux

Board

All

Firmware

n/a

What happened ?

There's a few places where the word "conding" has been used, which I assume is a typo for "coding"?
Obviously for backwards-compatibility the existing misnamed constants need to be kept, but I wonder if it'd be possible to use some #defines or something to also add correctly-spelt versions of the constants?

How to reproduce ?

...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-featherwing-max3421e
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-cond-typo
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-imxrt-usbphy
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix-h7-otg_fs-wfi
#
hathach
[hathach/tinyusb] Pull request opened: #2336 Fix h7 running on fullspeed phy has issue with WFI

Describe the PR
H7 running on full-speed phy need to disable ULPI clock in sleep mode. Otherwise, USB won't work when mcu executing WFI/WFE instruction i.e tick-less RTOS.

Note: there may be other family that is affected by this, but only H7 is tested so far

https://community.st.com/t5/stm32cubemx-mcus/why-stm32h743-usb-fs-doesn-t-work-if-freertos-tickless-idle/m-p/349480#M18867

  • also update clock setting for h743nucleo to run at 400mhz
  • update dwc2 info to extract dwc2 specs...
#
karlp
[hathach/tinyusb] Issue opened: #2337 BOARD=ek_tm4c123gxl doesn't link: .ARM.exidx section overlap issue

Operating System

Linux

Board

ek_tm4c123gxl

Firmware

Attempting to build the examples:

What happened ?

Linking fails due to an overlapping linker section.
arm-none-eabi/bin/ld: section .ARM.exidx LMA [000053f8,000053ff] overlaps section .data LMA [000053f8,0000746f]

I can't see anything obviously wrong with ./hw/mcu/ti/tm4c123xx/CMSIS/5.7.0/Device/ARM/ARMCM4/Source/GCC/gcc_arm.ld but I also can't see that it's being used...

How to reproduce ?

cd exam...
#
karlp
[hathach/tinyusb] New comment on issue #2337: BOARD=ek_tm4c123gxl doesn't link: .ARM.exidx section overlap issue

following patch "fixes" it, but unsure if that's where you want things done:

$ git diff
diff --git a/hw/bsp/tm4c123/boards/ek_tm4c123gxl/tm4c123.ld b/hw/bsp/tm4c123/boards/ek_tm4c123gxl/tm4c123.ld
index 351857bd6..f70f253bd 100644
--- a/hw/bsp/tm4c123/boards/ek_tm4c123gxl/tm4c123.ld
+++ b/hw/bsp/tm4c123/boards/ek_tm4c123gxl/tm4c123.ld
@@ -24,6 +24,7 @@ SECTIONS
         *(.fini)
         *(.rodata)
         *(.rodata.*)
+       *(.ARM.exidx*)
         . = ALIGN(4) ;
       ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: move-build-file
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2303 Add optional hooks for DCD and HCD events

thank you very much, this is a great idea and I really like it. Though I would like to tweak it to use weak callback function to be consistent with the rest of API. e.g

void tud_event_hook_cb(const void* event, bool in_isr) _weak
void tuh_event_hook_cb(const void* event, bool in_isr) _weak

The reasson to change to void* is dcd_event_t/hcd_event_t type are not public (not included with tusb.h).

Let me know if this suggestion make sense to you.

fallow birchBOT
fallow birchBOT
#
LarssonOliver
[hathach/tinyusb] New comment on pull request #2296: Allow external definition of TU_CP210X_PID_LIST

I was able to make it work with PID = 0x800A. I've not tested all the edge cases so I'm not 100% sure if everything works, but it seems to. And to be honest, I'm too unfamiliar with the protocol and the standard to be able to confidently do so either. Receiving and sending serial bytes works.

You are of course right with the naming convention. The reason I did it this way was so that the change was as unintrusive as possible and to not encourage the use of other PIDs that may or may not ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #2263: dcd_nrf5x: make it compile also with old Nordic SDK

They concurrently developed both 1.x and 2.x together since it is breaking changes. 1.9 is actually released after 2.0. It is supprising that nordicsemi didn't include NRFX_VERSION in their codebase.

This check make version v2.0 to v2.4 not compilable with tinyusb which is not correct. The correct check must ensure:

  • all v2.x compile as it is
  • additionally some of 1.x can be compiled, not all since there is a slash of MDK version.

From what I found MDK version for releases are

`...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #2303: Add optional hooks for DCD and HCD events

That's great, thanks! Would you like me to update the PR to change the hooks?

Yeah, please do it when you have the time.

Probably the "event" parameter can be removed from the hook. I added it on a whim as they're "free" with a macro, but I can't think of a use case so it can probably be removed.

I guess passing through "in_isr" is still potentially useful, though.

Yeah, you are right, application does not have any usage with internal data. Maybe we can change it to have r...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hid-set-protocol-pr
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release-0.16.0
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
karlp
[hathach/tinyusb] Issue opened: #2344 host: musb: hubs either fail to recognise, or assert

Operating System

Linux

Board

dk-tm4c129x (msp432e4 equivalent)

Firmware

examples/host/cdc_msc_hid

What happened ?

I'm not entirely sure from https://github.com/hathach/tinyusb/pull/1213 whether hubs are meant to be supported or not yet?

If I have the hub attached when the test app starts, it attempts to enumerate, but then asserts.
If I don't have the hub attached, let it boot, and then plug it in, it is simply not detected.

How to reproduce ?

build exa...

fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0.16.0
fallow birchBOT
#
sidd-kishan
[hathach/tinyusb] Issue opened: #2345 An new example of Rdnis + CDC

Related area

USB wifi dongle

Hardware specification

rp2040

Is your feature request related to a problem?

I have built a project to use Pi Pico W as a usb wifi dongle over RDNIS https://github.com/sidd-kishan/pico-webserver using the lwip example but I need a way to set wifi creds dynamically with cdc port

Describe the solution you'd like

There should be an example to demonstrate RDNIS to run with a cdc port.

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

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
rgrr
[hathach/tinyusb] New review comment on pull request #2263: dcd_nrf5x: make it compile also with old Nordic SDK

I'm actually not absolutely sure if this is required. This is more a defensive approach. If one guarantees, that "NVIC_EnableIRQ(USBD_IRQn)" works for all Nordic SDK, I'll remove those #ifdefs immedately. Same is true, if you accept the PR only if this construct is removed of course ;-)

is_sd_enabled() is not available in all Nordic SDKs. Before using another #ifdef I prefer a "generic" approach which works for all Nordic SDKs.

fallow birchBOT
fallow birchBOT
#
rpascalsdl
[hathach/tinyusb] New comment on issue #1949: uac2_headset on STM32F401 - TU_BREAKPOINT() on USB reconnect

I believe I have the same issue on RP2040. Don't have exact steps to reproduce, as I couldn't find an exact pattern when it happens. Here's an example of the problem when I was plugging and unplugging the Rasbperry Pi Pico from a Pixel 8 phone (flushed with uac2_headset example):

_exit(int status) (c:\Program Files\Raspberry Pi\Pico SDK v1.5.1\pico-sdk\src\rp2_common\pico_runtime\runtime.c:187)
panic(const char * fmt) (c:\Program Files\Raspberry Pi\Pico SDK v1.5.1\pico-sdk\src\rp2_co...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
b4yuan
[hathach/tinyusb] Pull request opened: #2351 Add CodeQL Workflow for Code Security Analysis

Describe the PR
This pull request introduces a CodeQL workflow to enhance the security analysis of this repository. CodeQL analysis results will be uploaded to Code Scanning under the Security tab. The workflow file also allows certain CodeQL queries to be filtered out that may result in false positives. Errors from the analysis may be dismissed for multiple reasons, e.g. false positive, won't fix, etc.

fail_on_error.py is a script that forces the entire workflow to fail should th...

fallow birchBOT
#
fbeser
[hathach/tinyusb] Issue opened: #2352 RP2040 assertion "hw_data_offset(next_buffer_ptr) <= USB_DPRAM_MAX" failed

Operating System

Windows 11

Board

Raspberry Pi Pico

Firmware

/tree/examples/device/uac2_headset

What happened ?

Actually, there is no problem with direct connection. However, when the computer stops making sound, it close the EP after a certain period of time. When I play the sound again, I get the error "hw_data_offset(next_buffer_ptr) <= USB_DPRAM_MAX". I can create this by simply pressing and waiting on the button used for windows to test audio devices.

How to r...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-hil-rp2040
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hil-esp32s3
#
hathach
[hathach/tinyusb] New branch created: codeql
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #2351 Add CodeQL Workflow for Code Security Analysis

superb!! Thank you, I was always wanting to add these static code analysis to action ci. This is a great feature to have. Though, due to sync issue, it failed current ci. Would you mind edit this PR to allow maintainer to edit so that I could help you to fix it or add me with write permission on your fork. If you are busy, I could just merge this as it is and make follow up PR later on.

fallow birchBOT
fallow birchBOT
#
github-advanced-security[bot]
[hathach/tinyusb] New comment on pull request #2351: Add CodeQL Workflow for Code Security Analysis

This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests wi...

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

Hey @nerdyscout,

You should include the TinyUSB library as an external library instead of copying the files in your project.
The TinyUSB config file does need to be part of your project and CFG_TUSB_CONFIG_FILE must point at it; I placed it in include/tusb_config.h.

I use the TinyUSB library on an RPI Pico with Arduino, and the platformio.ini looks something like:

[env:pico]
platform = https://github.com/maxgerhardt/platform-raspberrypi.git
board = pico
framework = arduino
...
fallow birchBOT
fallow birchBOT
#
dragonlock2
[hathach/tinyusb] Pull request opened: #2362 Add CH32V20x USB OTG/FS Driver

Describe the PR
Added support for the USB OTG/FS driver found in the CH32V20x microcontrollers, heavily inspired by the CH32V307 driver. Note there is an older incomplete PR https://github.com/hathach/tinyusb/pull/1995 for the same IP in the CH32V307.

Additional context
Driver does appear to be working well, I'm currently using it to implement a basic RPC using bulk transfers in [dragonlock2/miscboards/wch/rvice_adc](https://github.com/dragonlock2/miscboards/tree/main/wch/rvice_a...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
angmolin
[hathach/tinyusb] Issue opened: #2365 Alignment flag triggers warning: assuming pointer wraparound does not occur

Operating System

Linux

Board

rp2040

Firmware

Any example.

https://github.com/angmolin/tinyusb/tree/bugfix/gcc%2B12-strict-overflow-warning

What happened ?

When you try to compile tinyusb examples with gcc >= 12 it annoyingly triggers -Wstrict-overflow:

tinyusb/src/class/audio/audio_device.c:1568:23: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]
 1568 |         while (p_desc < p_desc_end)
    ...
#
angmolin
[hathach/tinyusb] Pull request opened: #2366 Fix strict-overflow warning when compiling with gcc >= 12

Describe the PR
A clear and concise description of what this PR solve.
This PR solves a problem with strict-overflow when compiling the tinyusb examples with gcc >=12. Here is the output:

tinyusb/src/class/audio/audio_device.c:1568:23: error: assuming pointer wraparound does not occur when comparing P +- C1 with P +- C2 [-Werror=strict-overflow]
 1568 |         while (p_desc < p_desc_end)
      |                ~~~~~~~^~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add-hil-s3
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more-s3-hil
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hil-add-nrf52840
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Lurcy38
[hathach/tinyusb] Pull request opened: #2373 Add Support stm32h5 for stm32h573i based on stm32_fsdev G0 implementa…

Describe the PR
Add Support stm32h5 for stm32h573i based on stm32_fsdev stm32g0
Board supported : STM32H573I-DK
Implementation Tested on Windows with IAR and GCC toolchain ( via cubeide) and working properly

Additional context
Tested only with audio examples, but sould be ok for other examples
cmake patched : but not tested Linux build : not tested
Added a temporary workaround in make file to support H5 HAL repo ( ARMCC_VERSION=0)

fallow birchBOT
#
davekeck
[hathach/tinyusb] Issue opened: #2374 STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

Operating System

MacOS

Board

custom

Firmware

stm32f723disco

What happened ?

I'm running the stm32f723disco example on a custom board. (Actual chip: STM32F730I8K6.)

USB comms work reliably when connected to an Intel Mac.

USB comms are flaky when connected to an ARM Mac, in which case the USB_OTG_DIEPINT_TOC / DIEPINT_TOC interrupt is occurring on EP0. This causes TinyUSB to loop in handle_epin_irq() (because it never clears the DIEPINT_TOC interrupt). Howev...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hil-add-samd51
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
ObligedTester
[hathach/tinyusb] Issue opened: #2378 Set caps-lock fails on lenovo keyboard

Operating System

Linux

Board

Raspberry Pi Pico

Firmware

1.5.1

What happened ?

Keyboard caps lock control wont work.(Control STALLED, xferred_bytes = 0)
Seem to isolated to this keyboard, out of three that i have available.
Reads keystrokes without issues to debug log.

How to reproduce ?

Plug keyboard in, try to switch on capslock LED with:
tuh_hid_set_report(deviceadress, deviceadress, 0, HID_REPORT_TYPE_OUTPUT, &leds, sizeof(leds));

Keyboard Lenovo SK-8827
...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: tweak-hil-pi4
#
HiFiPhile
[hathach/tinyusb] New review comment on pull request #2376: IAR CMake native support

It gives something like this:

.
├── build.ninja
├── build-Debug.ninja
├── build-Release.ninja
├── build-RelWithDebInfo.ninja
├── cmake_install.cmake
├── CMakeCache.txt
├── CMakeFiles
│   └──...
├── Debug
│   ├── audio_4_channel_mic.elf
│   ├── audio_4_channel_mic.elf.map
│   ├── audio_4_channel_mic.jlink
│   └── libboard_stm32f439nucleo.a
├── Release
│   ├── audio_4_channel_mic.elf
│   ├── audio_4_channel_mic.elf.map
│   ├── audio_4_channel_mic.jlink
│   └── libboard_s...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
davekeck
[hathach/tinyusb] New comment on issue #2374: STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

This issue occurs when using the OTG HS peripheral on the STM32F7. Interestingly the issue disappears when configuring the OTG HS peripheral to operate in full-speed mode with this change:

diff --git a/src/portable/synopsys/dwc2/dcd_dwc2.c b/src/portable/synopsys/dwc2/dcd_dwc2.c
static void phy_hs_init(dwc2_regs_t* dwc2) {
...
-  dcfg |= DCFG_DSPD_HS << DCFG_DSPD_Pos;
+  dcfg |= DCFG_DSPD_FS_HSPHY << DCFG_DSPD_Pos; // Tell HS peripheral to operate in FS mode

This issue app...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
davekeck
[hathach/tinyusb] New comment on issue #2374: STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

Good news: setting USB_HS_PHYC_TUNE to 0 fixes this issue, so that's a strong indicator that this issue is in the analog domain:

+++ b/src/portable/synopsys/dwc2/dwc2_stm32.h
@@ -197,7 +197,7 @@ static inline void dwc2_phy_init(dwc2_regs_t* dwc2, uint8_t hs_phy_type) {
       // Control the tuning interface of the High Speed PHY
       // Use magic value (USB_HS_PHYC_TUNE_VALUE) from ST driver for F7
-      USB_HS_PHYC->USB_HS_PHYC_TUNE |= 0x00000F13U;
+      USB_HS_PHYC->USB_H...
fallow birchBOT
#
davekeck
[hathach/tinyusb] New comment on issue #2374: STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

The root cause appears to be that we're or'ing the USB_HS_PHYC_TUNE register with the magic value, instead of setting USB_HS_PHYC_TUNE to the magic value. This causes the default value of the LFSCAPEN bit (bit 2) to be retained, where LFSCAPEN is described by the reference manual as:

LFSCAPEN: Enables the Low Full Speed feedback capacitor.

This capacitor is presumably messing up our analog signals, which makes sense because it appears to be intended for low/full-speed mode, ...

fallow birchBOT
#
davekeck
[hathach/tinyusb] Pull request opened: #2380 STM32F7: correct USB_HS_PHYC_TUNE configuration

Fix issue #2374 by assigning USB_HS_PHYC_TUNE to the magic value, instead of performing a bitwise-or.

Previously, the bitwise-or causes the default value of the LFSCAPEN bit (bit 2) to be retained, where LFSCAPEN is described by the reference manual as:

LFSCAPEN: Enables the Low Full Speed feedback capacitor.

This capacitor interferes with the D+/D- signals (which makes sense because it appears to be intended for low/full-speed mode, but we're in high-speed mode), which break...

fallow birchBOT
#
davekeck
[hathach/tinyusb] New comment on issue #2374: STM32F7: DIEPINT_TOC with ARM (Apple silicon) Mac

Upon further testing, the assign-to-magic-value-instead-of-oring solution (which has the effect of clearing the LFSCAPEN bit) only fixes USB comms when the device is connected to the USB ports on the left side of my ARM Mac. USB comms are still flaky when the device is connected to the USB port on the right side. 🤯

I'm guessing the signal integrity of the D+/D- signals isn't great with the USB_HS_PHYC_TUNE magic value of 0xF13.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update-freertos-11.0
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #2385 dcd_nrf5x: Fix dcd_edpt_open for iso endpoint

Describe the PR
When ISO endpoint handling was introduced two lines that clear stall and data toggle bit were left unchanged and they were effective for ISO endpoint as well.
This is incorrect behavior since EPSTALL and DTOGGLE registers have only 3 bits for address.
Leaving code that clears toggle bit results in endpoint 0 toggle bit being reset when iso endpoint (8) is opened.

Now code that clears stall and toggle bit is applied to non-iso endpoint only as it was done before iso h...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #2382: fixed device/video_capture/src/images.h,main.c CFG_EXAMPLE_VIDEO_DISA…

Thank you for debug video_capture example. It looks good for me regarding video_capture example. But, I can't confirm patches for bluepill board because I don't have the board.

If you want to merge video_capture part quickly, please separate this PR into two PRs: one for the video_capture part and the other for the bluepill part. Then, I will merge the PR for video_capture part immediately.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
gb88
[hathach/tinyusb] Issue opened: #2387 USB_EVT_READY stuck forever

Operating System

Windows 10

Board

Custom board with nRF52840

Firmware

Any bluefruit example

What happened ?

when the board is connected to USB charger with wall adapter the program will stuck at line 1044 ( while ( !(USBD_EVENTCAUSE_READY_Msk & NRF_USBD->EVENTCAUSE) ) { }) in the file dcd_nrf5x.c

How to reproduce ?

Should happen in any board powered by USB with wall adapter where is no enumerated

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

no log available...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max3421e-support-rp2040
#
hathach
[hathach/tinyusb] Pull request opened: #2390 support max3421e for rp2040

Describe the PR
allow rp2040 to use max3421e as host controller

  • fix warnings build hcd max3421 with rp2040
  • add tinyusb_host_max3421 target for rp2040 cmake, -DMAX3421_HOST=1 will enable this
  • add max3421 driver implementation for rp2040 family
  • update tusb_config for host to allow easy enable host selection for
    rp2040: native(default)/pio-usb/max3421e
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
DRNadler
[hathach/tinyusb] Issue opened: #2394 Race condition in wait_for_disk_io causes hang

Operating System

Windows 10

Board

imxRT1024

Firmware

This appears to be a generic problem for FreeRTOS (or any RTOS) applications...
Custom FreeRTOS application, using tinyUSB host mode with a USB stick attached.
Per tinyUSB examples, my FreeRTOS application has a task dedicated to processing USB events as follows:

void usb_host_task(void*) {
  tuh_init(BOARD_TUH_RHPORT);  // Initialize device stack on configured roothub port.
  while (1) {
    tuh_task();  // bloc...
fallow birchBOT
fallow birchBOT
#
gguichard
[hathach/tinyusb] Pull request opened: #2395 CDC device line state notification

Allow a CDC-ACM device to send a line state notification to the host (DCD/DSR/RING etc).

It has been tested using statserial command on Linux host side to verify UART-like line status.
It looks like that the notification endpoint size must be at least 10 bytes in order to hold the entire notification packet (which means this won't work for USB low speed devices).

fallow birchBOT
#
hrvach
[hathach/tinyusb] Issue opened: #2396 tuh_task() gets stuck when used for both device and host

Operating System

Linux

Board

RP2040 Pico

Firmware

Latest github branch (commit 86c416d4c0fb38432460b3e11b08b9de76941bf5 (HEAD, tag: 0.15.0))

What happened ?

Hi!

First please allow me to thank you for making and maintaining this library, it's incredible!

The issue is a small one - I've noticed tusb_inited() does:

bool tusb_inited(void)
{
  bool ret = false;

#if CFG_TUD_ENABLED
  ret = ret || tud_inited();
#endif

#if CFG_TUH_ENABLED
  ret = ret |...
fallow birchBOT
#
tlyu
[hathach/tinyusb] New comment on pull request #2395: CDC device line state notification

I'm commenting as an observer who's delved into the relevant parts of the USB specs for a while.

endpoint size must be at least 10 bytes in order to hold the entire notification packet (which means this won't work for USB low speed devices).

I'm pretty sure that low-speed USB devices aren't allowed to have bulk endpoints, which rules out typical CDC ACM implementations, so this concern probably doesn't apply.

fallow birchBOT