#tinyusb

1 messages ยท Page 16 of 1

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #859 Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Thank you very much for your effort putting into this PR. This is lots of work and testing, there is also fixes to existing rx driver as well. However, the weak function walk-around is not good enough and is a total deal breaker. It is totally not your fault but rather mine for choosing the weak function for user convenience and assume that most toolchain would support it.

I think we either have to come up with another walkaround for weak function or have to merge other changes first. And ...

fallow birchBOT
#
hac425xxx
[hathach/tinyusb] Issue opened: #880 Multiple out of bound read Vulnerabilities In tinyusb

These bugs are caused by the failure to check request->wLength.

hidd_control_xfer_cb

case 1

if request->wLength > the size of p_hid->epin_buf it could lead buffer out of bound read.

      case HID_REQ_CONTROL_GET_REPORT:
        if ( stage == CONTROL_STAGE_SETUP )
        {
          uint8_t const report_type = tu_u16_high(request->wValue);
          uint8_t const report_id   = tu_u16_low(request->wValue);

          uint16_t xferlen = tud_hid_get_report...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #880: Multiple out of bound read Vulnerabilities In tinyusb

Ah thanks, I thought you would have a running examples so that we could quickly test it out and fix it. Regardless, these are valid issue. Ultimately we shouldn't just host for its length.

  • The 1) can be fixed by limited the requestlength to the endpoint size.
  • For 2 DFU, it is newly added, I have an plan to enhance it later on, will keep this in mind.
  • For 3) same as 1.

Thanks for your issue, if you have time please submit PR if possible. Otherwise, It is great enough, I will try...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: mindmotion\-followup
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New review comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Putting the bit field ordering at the beginning and the end of a structure declaration is fine for me.
BTW: I'm not sure if the bit field order is really important on every bit field. I did not haven't a deeper look on it, if it is a local used bit field. I guess it is only important, if the bit field is transferred over USB or if it is mapped over a RAM/HW region and not if it is used as a local status variable.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #874: Add dcd\_edpt\_xfer\_fifo\(\) for RX63N

#859 also modify the same driver, do you see any conflict. If not, we could merge this first, and pull update for 859.

There are some conflicts between this branch and #859. I did some refactoring to add dcd_edpt_xfer_fifo(), so there are conflicts. I will fix up these conflicts after #859 is merged.

Thanks, let's wait for 859 a bit, if the issue with weak function isn't resolved anytime soon, we could merge this first instead

#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Of course, the easiest way would be to leave the weak macro for the CCRX port undefined. It would the be required by the user to implement all the functions which have the weak attribute in the GCC port. But I can not estimate does this have any impact on the execution speed (means calling empty callback function all the time) ?

If I see a negative impact on the project I'm using tinyUSB, then I might make a local change to overcome the problem for the time being.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Of course, the easiest way would be to leave the weak macro for the CCRX port undefined. It would the be required by the user to implement all the functions which have the weak attribute in the GCC port. But I can not estimate does this have any impact on the execution speed (means calling empty callback function all the time) ?

If I see a negative impact on the project I'm using tinyUSB, then I might make a local change to overcome the problem for the time being.

It should be tha...

#
kkitayam
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

If the compiler does not support a weak feature, why not call the default inline callback function specified by the compiler argument? I tried that the following experiment.

#include <stdio.h>
static inline void default_cb(void){}
int main(void) {
    if (hello) {
        printf("ok\n");
        hello();
    }
    return 0;
}

I compiled the above file which name is hello.c with following command.
`ccrx.exe -change_message=information -output=src -isa=rxv2 -inline -de...

fallow birchBOT
#
mmosca
[hathach/tinyusb] Pull request opened: #882 Add optional support for 32 button gamepads

Describe the PR
More buttons = more better

This pull request implements a configuration option to switch between the current 16 buttons and 32, with the current 16 buttons being the default value.

Adding "#define CFG_TUD_MAX_BUTTONS 32" to tusb_config.h enables the extra 16 buttons.

Additional context

While trying to map a real life RC transmitter to a controller that can easily integrate with flight sims I quickly run out of buttons to map all my 3 position switch...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-rp2040\-host\-transferred\-bytes
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

inline function may not work with

if (weak_func) weak_func()

Since it does not emit symbol. Also the static inline require function must be included by the class driver, and which means all the weak function must be implemented in header file of tusb_config.h (or one of the file it includes). Which can grow very unpleasantly. Therefore I still prefer to force the strong symbol on CCRX, eventually when they support weak symbol, we can easily flip the TU_ATTR_WEAK to support ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #882: Add optional support for 32 button gamepads

I have no problems making 32 buttons the only option.

The reason I went the long way around was that I though people might be bothered by the increase in size of the joystick report.

Yeah, but don't worry, people shouldn't be affected if using the helper API. Those that uses the raw API should know what to do :)

I also updated the GAMEPAD_BUTTON_ entries and comments. GAMEPAD_BUTTON_15 is now GHAMEPAD_BUTTON_16 to match how windows and most game reference the buttons.

I am...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hac425xxx
[hathach/tinyusb] New comment on issue #880: Multiple out of bound read Vulnerabilities In tinyusb

out of bound in proc_read10_cmd

p_cbw and p_csw is receive from other usb device

static void proc_read10_cmd(uint8_t rhport, mscd_interface_t* p_msc)
{
  msc_cbw_t const * p_cbw = &p_msc->cbw;
  msc_csw_t       * p_csw = &p_msc->csw;

  uint16_t const block_cnt = rdwr10_get_blockcount(p_cbw->command);
  uint16_t const block_sz = p_cbw->total_bytes / block_cnt;

  // Adjust lba with transferred bytes
  uint32_t const lba = rdwr10_get_lba(p_cbw->command) + (p_msc->xfe...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kamathba
[hathach/tinyusb] Issue opened: #884 net\_lwip\_webserver reaches "endpoint busy" race condition on STM32F411DISCO

Set Up
Compile the example: make DEBUG=1 BOARD=stm32f411disco all

  • Ubuntu 20.04.2 LTS
  • STM32F411DISCO
  • master (1b8473902fb0e808c32183f306938accc9ce0d5)
  • Firmware e.g examples/device/net_lwip_webserver

Describe The Bug

I reach the following assert when connecting to my host pc over usb:

usbd_edpt_xfer (rhport=rhport@entry=0 '\000', ep_addr=129 '\201', buffer=buffer@entry=0x2000001c  "\001", total_bytes=)
    at /home/bkamath/.dev/fb/tinyusb/src...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach Some note about the missing weak attribute on CCRX. I tried to cleanup the code and removing my solution of the weak functionality. While doing so I found the following code situation:

https://github.com/hathach/tinyusb/blob/1b8473902fb0e808c32183f306938accc9ce0d5f/src/device/usbd.c#L998-L1008

If I implement an empty tud_descriptor_device_qualifier_cb what would the return value be ? I think it should be NULL, but this is maybe a problem because the return value is actually ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAME70 DCD Support

Hi, at the moment this PR is tested on bulk transfer but other types of transfer remain untested (should work)

I've done some more work about fifo support but also remain untested.

Getting cdc_msc and hid_composite running is good enough for PR to merge. The rest can be done as follow up PRs. It is not easy to get everything right for the 1st pr.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-update
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
gionatha
[hathach/tinyusb] New comment on pull request #809: Esp32s2 \- make net lwip webserver workable

Hi Gionatha,
Esp32 MCUs are running esp-idf.
Freertos is a submodule of esp-idf.
Hence this operating system is the default operating system for all esp32 projects.

Ok, I use nxp development board.
Could I see the main project file and the library configuration files to see if they can help me solve my problem?
I probably have problems with assigning lwip library functions to FreeRTOS tasks

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-rp2040\-double\-buffer
#
hathach
[hathach/tinyusb] Pull request opened: #891 RP2040 double buffer

Describe the PR
This PR implements double buffered for RP2040, rework/refactor the existing quite a log

  • we don't have to deal with RP2040-E4 hardware our of synce
  • faster transfer for control and bulk
  • Should fix https://github.com/raspberrypi/pico-sdk/issues/442 with logitech universal receiver (8-byte control in Fullspeed) and wired keyboard with 8byte control in Lowspeed
  • Lots of internal rp2040 usb renaming

Since rp2040_usb is also used by device, but tested on device i...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Pull request opened: #892 DCD SAM3U Support

Signed-off-by: Rafael Silva

Describe the PR
Implementation of a DCD driver for the SAM3U.

Additional context
The SAM3U seems to have a similar USB core to the SAMx7x family, for which support is being added in #693, but the register map seems to be completely different.
That said, thanks to that it should be easier to port.

  • [ ] Port dcd based on SAM7X;
  • [ ] Successful build;
  • [ ] Working examples (cdc_msc, hid_composite);
fallow birchBOT
fallow birchBOT
#
torstenmay
[hathach/tinyusb] New comment on pull request #809: Esp32s2 \- make net lwip webserver workable

Hi Gionatha,
Esp32 MCUs are running esp-idf.
Freertos is a submodule of esp-idf.
Hence this operating system is the default operating system for all esp32 projects.

Ok, I use nxp development board.
Could I see the main project file and the library configuration files to see if they can help me solve my problem?
I probably have problems with assigning lwip library functions to FreeRTOS tasks

Hi Gionatha,

please check the two things:

  • CMakeFiles
  • sdkco...
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
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #884: net\_lwip\_webserver reaches "endpoint busy" race condition on STM32F411DISCO

thanks for the issue, I also encouter the ASSERT with 0x81 endpoint, however, it seems to be "normal" since currently the net driver doesn't check the busy state of the notification endpoint and can send one while previous one doesn't received by host yet. This will be fixed later but in general it does affect the example as this also appear on other working MCUs as well.

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

After reading SAM3U's manual, it seems they are very similar in functionality.

But there are too much differences in register map, I'm afraid we need to spam #ifdef in order to merge them.

It is doable with by extracting function to common API and/or some other works. There is no rush to support SAM3U, we do it little by little.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

I got some problem testing HID example, seems like HID descriptor was not sent correctly ?

USBD init
HID init
USBD Bus Reset : Full Speed

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

USBD Setup Received 00 05 01 00 00 00 00 00
  Set A...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zhangslice
[hathach/tinyusb] New comment on pull request #896: add mm32 dsp

Okay, I'll try again tomorrow after fork

------------------ย ๅŽŸๅง‹้‚ฎไปถย ------------------
ๅ‘ไปถไบบ: "hathach/tinyusb" @.>;
ๅ‘้€ๆ—ถ้—ด:ย 2021ๅนด6ๆœˆ16ๆ—ฅ(ๆ˜ŸๆœŸไธ‰) ๆ™šไธŠ8:20
@.>;
@.@.>;
ไธป้ข˜:ย Re: [hathach/tinyusb] add mm32 dsp (#896)

@ha...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-hid\-host
fallow birchBOT
fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New comment on issue #880: Multiple out of bound read Vulnerabilities In tinyusb

I reviewed the dfu_req_dnload_setup and do not see this as a bug, provided that the CFG_TUD_DFU_TRANSFER_BUFFER_SIZE is in the descriptor. For this case to happen, the host would have to non-compliant. I will add a check here so that if the host were to send a request too long the issue would be more easily traceable.

On review, I did discover that I do have a bug elsewhere:

static uint16_t dfu_req_upload(uint8_t rhport, tusb_control_request_t const * request, uint16_t block_num,...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New review comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

I need to have deeper look at that. It seems to be a problem between the endian macros found in descriptor macro and the bit field definition in the tusb_desc_endpoint_t struct. Especially in the big endian configuration (in little endian configuration the code seems to work).
BTW: Sorry for the time delay, but at the moment I'm very busy at work. I hope to get it done this weekend

fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach Maybe I could support you a little bit. I don't also like the FIT modules (I had to much negative experience with it, like with other similar technique from other vendors). Is there a board support package available for your board ? It would at least help you to speed up the clock programming for the first time.

BTW: Sorry for the time delay about this PR, but at the moment I'm very busy at work.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #897: add mm32 bsp

I have added makefile (family.mk and board.mk) to allow building the mb39 board, though It needs https://github.com/zhangslice/mm32sdk/pull/1 to be merged first to add the startup file for gcc.

@zhangslice I couldn't find a way to flash the board to test its functionality. My windows VM couldn't able to connect to the mcu using mm32-link. The led next to the link usb connection blinking forever. Any tips to connect and flash the board would be helpful.

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

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach Maybe I could support you a little bit. I don't also like the FIT modules (I had to much negative experience with it, like with other similar technique from other vendors). Is there a board support package available for your board ? It would at least help you to speed up the clock programming for the first time.

That would be great to have more help, here is link to my board from renesas site https://www.renesas.com/us/en/products/microcontrollers-microprocessors/rx-32-bit-perfo...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-nrf\-control\-bulk\-race\-condition
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zhangslice
[hathach/tinyusb] New comment on pull request #897: add mm32 bsp

The.ld file is added in DSP, and the.s file is in my branch. All products with ARM kernel can use JLink. The on-board debugger we brought with us also provides a JLink socket. I have sent you the schematic diagram of the board for you to check, and it is marked accordingly. You don't need to use our own upper computer software. If you want to use it, you need to install the driver and there are instructions on the official website.
------------------ย ๅŽŸๅง‹้‚ฎไปถย ------------------
ๅ‘ไปถไบบ: ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #897: add mm32 bsp

@zhangslice I don't see the startup file (.S) for gcc in your PR. There is also other typo (incorrect file name which will failed to compile on case-sensitive OS like Linux). Can you check out the PR and merge it to your sdk https://github.com/zhangslice/mm32sdk/pull/1

For using Jlink, I also like to use it as well, however, the supported list from jlink does not cover your MM32F327 yet https://www.segger.com/downloads/supported-devices.php?m=MindMotion , which device should I use to flash...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-rx65n\-board
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-midi
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #904: dcd\_transdimension ISO transfer

yeah, it is not yet supported. I don't actually implement any ISO transfer myself since It has no application/audio driver to test with until recently. I have a bad habit of not writing code that aren't run yet.

PS. I measured a raw bulk out throughput of 14MB/s maybe due to slow Flash access time.

How did you carry out the test ? I haven't done much of speed optimization just yet.

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #904: dcd\_transdimension ISO transfer

CFG_TUD_CDC_RX_BUFSIZE/CFG_TUD_CDC_TX_BUFSIZE

It's 512 as default.

With 1024 I got 21MB/s and 27MB/s for 2048. If I remove tu_fifo_write_n(&p_cdc->rx_ff, &p_cdc->epout_buf, xferred_bytes); in cdcd_xfer_cb I got 2MB/s quicker.

I haven't done much of speed optimization just yet.

Seems the throughput is already good (a tud_task() call while idle still need ~250 cycles).

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #904: dcd\_transdimension ISO transfer

For ISO it seems there is a catch in queue management:

For ISO, when a dTD is retired, the next dTD is primed for the next frame. For 
continuous (micro) frame to (micro) frame operation the DCD should ensure that the dTD 
linked-list is out ahead of the device controller by at least two (micro) frames.

Actually in audio_device we finish the current one before schedule the next one.

#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach I had a look at the documentation of your board. Here are some hints (maybe more or less useful):

  • The onboard E2 Lite debugger can only use the FINE interface for debugging/programming, JTAG is not supported
  • For the board there is board description file available, that should lower the entry level to get the board working

I would suggest to use the board description file and the smart configurator to setup the clock system, because this part is sometimes tricky and the gr...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
robert-rozee
[hathach/tinyusb] New comment on issue #872: CDC hardware flow control can not be disabled

on the RP2040, after sending around 1000 characters from a (linux) host without DTR being asserted (characters which are being echoed back by the RP2040), the USB subsystem on the host locks up solidly for around 30 seconds before returning a 'try again' error message back to the user application. while this seems to be a problem with the host/linux, it would be good for the RP2040/tinyUSB to instead be configurable to ignore the state of DTR and just keep sending characters back to the h...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

And, I will try Renesas Flash Programmer CLI.

I was able to confirm the writing with rpi-cli by using following steps on Windows 10. I think that it works on Linux.

make BOARD=rx65n_cloud_kit
rx-elf-objcopy -O ihex _build\rx65n_cloud_kit\board_test.elf board_test.hex
rfp-cli -d RX65x -t e2l -if fine -fo id FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -auth id FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF -a board_test.hex

rfp-cli had output following logs.

Renesas Flash Programmer CLI V1....
fallow birchBOT
fallow birchBOT
#
robert-rozee
[hathach/tinyusb] New comment on issue #872: CDC hardware flow control can not be disabled

at the moment, with RP2040+tinyUSB, if DTR is not asserted by the host (in my case a desktop PC running linux), the RP2040 stops sending characters to the host. it looks like tinyUSB attempts to buffer these characters. after approximately 1000 characters have been buffered a malfunction occurs. this scenario can be demonstrated with micropython running on a RP2040 (micropython uses tiny USB).

**what i would like to be able to do, is to configure tinyUSB so that it ignores the state of DTR...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #872: CDC hardware flow control can not be disabled

at the moment, with RP2040+tinyUSB, if DTR is not asserted by the host (in my case a desktop PC running linux), the RP2040 stops sending characters to the host. it looks like tinyUSB attempts to buffer these characters. after approximately 1000 characters have been buffered a malfunction occurs. this scenario can be demonstrated with micropython running on a RP2040 (micropython uses tiny USB).

Have you tried to figured out why tinyusb stop sending data to host. Any log from stack ? It se...

fallow birchBOT
#
robert-rozee
[hathach/tinyusb] New comment on issue #872: CDC hardware flow control can not be disabled

the software engineer developing for the RP2040 is located in the UK, the other side of the world to where i am (in New Zealand). his perspective is that it works ok for him (win10, using teraterm as a terminal emulator) and he has no interest in testing for anything other than his own setup; he is a 'challenging' person to deal with. the source code will only become available to me once his code is 'released to production'.

hence my reproducing the behaviour with micropython, where the so...

fallow birchBOT
#
thierer
[hathach/tinyusb] Pull request opened: #911 Enable empty transfers for tud\_vendor\_n\_write\(\)

Extend tud_vendor_n_write() to make a zero length transfer when buffer==NULL && bufsize==0, as discussed in #903.

I consider implementing this via a flag to maybe_transmit() the best solution:

  • tud_vendor_n_write() doesn't have access to neither buffer nor bufsize, so it can't make the decision.
  • Implementing it completely in tud_vendor_n_write() would mean duplicating some functionality of maybe_transmit() (but judging by your latest comment maybe that's what you prefe...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #872: CDC hardware flow control can not be disabled

I see and understand your problem since you are not familiar with mcu. However for this issue to be addressed, and if you still want it to. Please update your 1st post to provide all the setup information with specific version of each software (mp, picosdk, tinyusb) and step to reproduce issue. Then change the label to Bug. Though since I don't often use mp, this will have huge delay for me to even try to reproduce it.

fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New review comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

I did some test about this issue here. First I setup a new build variant with GCC in big endian order to check if the same problem occurs as with the CCRX. This was not successfully, build my test project with GCC in big endian order shows a problem in the tinyUSB sources with bitfields.

First the order of the bitfields is changed and second there is no possibility to change the ordering of the bitfields in GCC (at least I found no possibility). Every thing I tried (for example `#pragma ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #891: RP2040 double buffer

Sorry for the delay here. The code looks good to me. I don't have much time to test it at the moment because I am working on a different project. @kilograham do you have any thoughts?

No problem at all, I am busy with other works anyway. Note currently the double buffered is not fully operated (skip with device IN), but we could address this later. For now, anyone that could help with testing would be great.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #918: Add fifo get function to CDC class for DMA transfer

In fact CDC streaming is needed by my company's project which restarted recently, following my tests last year.

For the short time expose the fifo fit my need, of cause we can make something better for example expose only fifo_info even add edpt_xfer_fifo support.

It is easy to expose an API, but it is very hard to drop one. I would prefer to figure it all out first. I think for now, you could make an "hack" for your fork e.g dropping static in the function/variable in the cdc_dev...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Issue opened: #920 High\-speed streaming capacity of CDC class

Is your feature request related to a problem? Please describe.

Raw throughput of USB can be high but once you make some data copy the speed will drop significantly. Currently there is no way to skip fifo & buffer in CDC class:
USB HW Buffer ==> ep_out_buf ==> rx_ff ==> User app
Besides DMA is not supported.

We had some discussions on this subject, for example expose the fifo or add xfer_fifo support.

Describe the solution you'd like
Sort out a solution to make CDC class ...

fallow birchBOT
fallow birchBOT
#
mfp20
[hathach/tinyusb] New comment on issue #920: High\-speed streaming capacity of CDC class

@HiFiPhile which one?

Last month I saw you had some discussion about DMA and CDC, have you sorted it out ?

No.

I wrote a "dma pump" to allocate DMA channels and use on request of heterogeneous consumers. But performance were not as good as integrating dma in peripheral's functions. Probably working a bit more on that route would bring good results, but it is too much work to circumvent the lack of control over buffers. The easiest path would be to be able to supply your own b...

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #920: High\-speed streaming capacity of CDC class

Though expanding it can increase code complexity since there is more mcu that does not support that than one does. But definitely what we could take a look.

Yes I agree with you, currently 30MB/s is close to the limit, I think it's easier to focus on reduce CPU utilisation.

I'll try to add edpt_xfer_fifo support for CDC class and have few questions @hathach , @PanRe :
For OUT xfer:
Is the caller's responsibility to check free space (DCD just do the queue) ?
For IN xfer:
Is the cal...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #920: High\-speed streaming capacity of CDC class

HI,
As for the OUT transfer, i would say since CDC is a supposed to be a reliable connection (Bulk EP), i would set the FIFO to be non-overwriteable, check within the CDC driver if the received frame can be stored within the FIFO entirely and if not don't acknowledge the successful reception such that the host resends the frame again (hoping that later on there will be space available). Within UAC2, i selected the FIFO to be overwriteable and every frame gets acknowledged. This, however, cor...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #920: High\-speed streaming capacity of CDC class

This, however, corresponds to the nature of iso streams. So i would say the caller (i guess you mean the end user)

Sorry it's not very clear, I mean between class driver and dcd edpt_xfer_fifo implementation. Seems like class drivers check if everything ok before call edpt_xfer_fifo but I'm not sure...

For IN transfers, i am currently not sure what total_bytes

I mean the argument of edpt_xfer_fifo

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #920: High\-speed streaming capacity of CDC class

Ah ok. Yes i would say it is the class drivers responsibility to check everything and the DCD only queues the ordered number of bytes given by total_bytes. This is the same as the linear buffer functions dcd_edpt_xfer() does. I always would restrict to total_bytes and never send more... Since it is a FIFO, there is a chance that the number of bytes in the FIFO is bigger at the time when the transmit gets executed compared to the point in time where the class driver scheduled the transm...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
DuMaM
[hathach/tinyusb] Pull request opened: #923 GCC 11 build fix for nrf5x

During Adafruit Bootloader compilation, I spotted bellow error which do not allow me build project.

    inlined from 'hfclk_running' at lib/tinyusb/src/portable/nordic/nrf5x/dcd_nrf5x.c:785:13:
lib/tinyusb/src/portable/nordic/nrf5x/dcd_nrf5x.c:792:31: error: 'is_running' may be used uninitialized [-Werror=maybe-uninitialized]
  792 |     return (is_running ? true : false);
      |            ~~~~~~~~~~~~~~~~~~~^~~~~~~~

Describe the PR
A clear and concise description ...

fallow birchBOT
glad sequoia
#

is this just a git feed or intended for discussion/questions about tinyusb?

odd swan
#

Discussions and questions as well

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Pull request opened: #926 Add xfer\_fifo support for CDC and dcd\_transdimension

Describe the PR
Various improvements in order to improve CDC efficiency.

Test result can be found in https://github.com/hathach/tinyusb/issues/920, which shows a great increment in throughput and
and reduce execution time.

  • Add xfer_fifo support for CDC and dcd_transdimension
  • Add functions to support direct (DMA) fifo transfer
  • tud_cdc_rx_wanted_cb is still WIP since can't be done without accessing underlying fifo struct members

Additional context
Linear buffer is...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #922: Update some settings for rx65n board

I added a commit for flash. At first I only checked it with JLink.
rpi-cli sometimes report the following error, but after a few tries it succeeds.

[Error] E4000004: A framing error occurred while receiving data. (BFW: 0354)

Just a reminder, after programming, the RX65N reset will not be released unless EJ2 is shorted.

Yeah, thank, rpi-cli does has issue but not very often. It requires me to manually insert header to enter debug mode when flashing, th...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #927 Add rx65n board

Describe the PR
This PR add support for Rensas RX65N cloud kit board, rename bsp from rx63n to simply rx. Huge thank to @kkitayam to sort out most of the issue. Most examples has been tested and working including: msc_cdc, hid_composite, net_lwip_webserver, midi_test

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: house\-keeping
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on pull request #922: Update some settings for rx65n board

I much prefer jlink, btw, how would you add jlink to the rx65n target board. I may need it when doing doing more extensive work. It is not very clear in the board user manual.

@hathach
Yeah, the board user manual has no information regarding JLink. But, since both JLink and RX family are compatible with the JTAG standard, we can refer the pin connections regarding JTAG.

I have checked JTAG connections for schematics and [JLink connector](https://www.segger.com/products/debug-probes/...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #922: Update some settings for rx65n board

@kkitayam superb !! thank you very much again, this is really useful information. I totally need this for later working with it.Thank you again. Your board to be the same to my rx65n target board (part of the cloud kit). I think it is better to just name it rx65n target board instead of cloud kit, since more people will have the target board.

Note: reason I order more expensive cloud kit because it has the daughter board with USB connector, since I have no idea if a simple jumper to usb b...

fallow birchBOT
#
diggit
[hathach/tinyusb] New comment on issue #900: Only first bulk OUT EP write works

I got rid of RTOS.
CDC works normally. (ar at least some data are comming into device, LEDs are counting in binary). See cdc_task below
So i'd consider HW being OK. I do not have any of supported board at hand.

static void cdc_task(void) {
	uint8_t itf;

	static unsigned int cnt = 0;

	for (itf = 0; itf < CFG_TUD_CDC itf++) {
		// connected() check for DTR bit
		// Most but not all terminal client set this when making connection
		// if ( tud_cdc_n_connected(itf) )
		{
		...
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #900: Only first bulk OUT EP write works

The issue seems to be the stack's vendor driver, currently it doesn't guard against race condition as cdc. I haven't updated the vendor driver once introducing the usbd_edpt_claim() for race protection. I actually have an plan to abstract these to stream/buffered endpoints API for driver and haven't got time to do so.

https://github.com/hathach/tinyusb/blob/master/src/class/vendor/vendor_device.c#L109
https://github.com/hathach/tinyusb/blob/master/src/class/cdc/cdc_device.c#L83

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: update\-rx65n\-bsp
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: poison\-obsolete\-callback
#
hathach
[hathach/tinyusb] Pull request opened: #934 add tud\_vendor\_control\_request\_cb\(\) to poisoned list

Describe the PR
Add poisoned list (only gcc) for renamed callbacks, so that it make it easier to spot and fix the issue. Otherwise it can be under radar with the only warning is function not used. Original idea comes from https://github.com/hathach/tinyusb/discussions/921

Put to tusb_compiler.h since gcc seem to be the only compiler to support this, update/expand/refactor later on when needed.

fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Issue opened: #935 audiod\_tx\_done\_cb overflow

Operating System

Windows 10

Board

Core4357

Firmware

examples\device\uac2_headset

What happened ?

Playing with uac2_headset I found there are output samples in the buffer, but mic input is always silence.

Initially there are IN xfer, but as soon as OUT intf is opened, IN xfer stops.

00>   AUDIO xfer callback
00>   Queue EP 81 with 0 bytes ... OK
00> USBD Xfer Complete on EP 81 with 0 bytes
00>   AUDIO xfer callback
00>   Queue EP 81 with 0 bytes ... OK
00> ...
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

Did you use the fix fix uac2_headset example #849?

Yes it's the latest master, and this PR is minimum.

Did you try disabling the debug messages?

Yes at first I didn't enable the log, since no data flow in EP IN I enabled it to see what happens.

we need to debug audiod_get_AS_interface_index()...

That makes sens, it should returns 1 ?

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

You have different return in your board ?

I never tested this example on my own. I only adapted the changes required for the new version of the UAC2 driver.

Looking at the example in more detail i see that there are two AS interfaces defined in the audio descriptors, yet CFG_TUD_AUDIO_FUNC_1_N_AS_INT = 1 is defined within tusb_config.h. It should be CFG_TUD_AUDIO_FUNC_1_N_AS_INT = 2 yielding alt_setting_1 to be of length two. If interface 1 is opened, idxItf = 0 should be th...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

I think it's a logic problem on tmp increment, tmp should increase only on alt0 interface descriptor, now it's good :)

    uint8_t tmp = 0;
    while (p_desc < p_desc_end)
    {
      // We assume the number of alternate settings is increasing thus we return the index of alternate setting zero!
      if (tu_desc_type(p_desc) == TUSB_DESC_INTERFACE && ((tusb_desc_interface_t const * )p_desc)->bAlternateSetting == 0)
      {
        if (((tusb_desc_interface_t const * )p_desc)->...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

Jep feel free to enhance it! Change of sample resolution from 16/24/32 bit may also be nice but is not mandatory. Some time ago i tried to do this, but i did not manage it to get 24 bits working on Windows. The standard UAC2 Windows driver ignored my 24 bit alternate interface setting for some reason i don't know yet. Have you done this before?

#
HiFiPhile
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

I haven't tried 24bit yet.
For EP wMaxPacketSize it can be figured out more smartly with maximum sample frequency, for example with xmos:

/* Max packet sizes:
 * Samples per channel. e.g (192000+7999)/8000 = 24
 * Must allow 1 sample extra per chan (24 + 1) = 25
 * Multiply by number of channels and bytes      25 * 2 * 4 = 200 bytes
 * TODO Output doesn't get modified by channel count
*/
#define MAX_PACKET_SIZE_MULT_OUT_HS ((((MAX_FREQ+7999)/8000)+1) * NUM_USB_CHAN_OUT)
#defin...
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #935: audiod\_tx\_done\_cb overflow

Mh i tried something like that... i read that the standard windows driver selects the alternate interface whose wMaxPacketSize is just big enough to handle the desired bandwidth. So i had
(48000 / 1000 + 1) * N_Ch * N_BYTES_PER_SAMPLE for N_BYTES_PER_SAMPLE = 2, 3, 4
But this did not work so far...
Anyway, thanks for fixing the example!!

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Issue opened: #939 tu\_fifo overflow correction error

Operating System

Windows 10

Board

STM32L0

Firmware

Reproduce code:

tu_fifo_t ft;
uint8_t dummy[512];
uint8_t dummy2[512];
uint16_t n;
void main(void)
{
    tu_fifo_config(&ft, dummy, 512, 1, 1);
    ft.wr_idx = 466;
    ft.rd_idx = 827;
    printf("Count %d, rd_idx %d \r\n", tu_fifo_count(&ft), ft.rd_idx);
    n = tu_fifo_read_n(&ft, dummy2, 200);
    printf("Read %d, count %d rd_idx %d  \r\n", n, tu_fifo_count(&ft), ft.rd_idx);
    n = tu_fifo_read_n(&ft, d...
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] Pull request opened: #941 Add rx\_rtt\_printf\(\) to work RTT logging with NEWLIB on Renesas RX family\.

Describe the PR
Add rx_rtt_printf() to work RTT logging with NEWLIB on Renesas RX family.
rx_rtt_printf() should be set to CFG_TUSB_DEBUG_PRINTF. The function just call SEGGER_RTT_vprintf.

Additional context
OPTLIB is removed from GCC 8.3.0.202002-GNURX. So, we need to make RTT work properly with NEWLIB.
I don't know why, but RTT didn't work via _write with NEWLIB. Using `SEGGER_RTT...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #939: tu\_fifo overflow correction error

Mh i thought a bit of the problem you described but i don't really see where the problem comes from and why casting to uint16_t solves the problem. After the first read, the second condition should hit as
(p + offset > f->max_pointer_idx) which is 827 + 200 = 1027 > 1023
and the read index should become
rd_idx = mod(827 + 200 + 64512, 16) = 3,
where 64512 is non_used_index_space . Do you have any ideas on this?

#
PanRe
[hathach/tinyusb] New comment on pull request #940: Fix fifo overflow correction\.

For advance_pointer

  if ((p > p + offset) || (p + offset > f->max_pointer_idx))
  {
    p = (p + offset) + f->non_used_index_space;
  }
  else
  {
    p += offset;
  }

I feel like the check can be simplified into if (p + offset > f->max_pointer_idx)), have I missed something ?

The first condition covers the case when p overflows solely by offset. It is possible that the second condition never hits i.e. if offset is big e...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #939: tu\_fifo overflow correction error

After the first read, the second condition should hit as

It failed at 1st read, since the fifo is in overflowed state, in _tu_fifo_peek it tries to correct the rd_idx by backward the pointer.

I'm not sure which C language rule apply, but without casting to uint it generate signed compare machine code, since (p - offset) is negative the result is always false.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #939: tu\_fifo overflow correction error

The GCC++17 have the warning when compiling with this as well, since haven't got time to trace it down, I just put the warning comment there :D. For C : I think any expression involved minus will be treated as signed number ( I guess ).

// TODO warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #939: tu\_fifo overflow correction error

After the first read, the second condition should hit as

It failed at 1st read, since the fifo is in overflowed state, in _tu_fifo_peek it tries to correct the rd_idx by backward the pointer.

I'm not sure which C language rule apply, but without casting to uint it generate signed compare machine code, since (p - offset) is negative the result is always false.

I see, thanks for fixing!

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
mfp20
[hathach/tinyusb] New comment on issue #651: Support running entire stack safely in ISR

currently it can only be safe to call tud_task() if you don't use RTOS. Otherwise calling the mutex API within ISR can cause issues depending on your RTOS. The idea of introducing tud_task_isr() is to skip mutex API.

Well, RPi Pico doesn't have an RTOS but I've spotted both mutex (irqs on) and critical_section (irqs off) used in code; don't know HOW they are used tough.

In any case yes, having a isr safe tud_task() would help a lot.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: hid\-set\-report
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #938: Bug fix and Enhancements of UAC2

@PanRe I've some problem in sending feedback. I want to call tud_audio_n_fb_set inside tud_audio_set_itf_cb to initialize feedback value to default value, but since _audiod_fct[func_id].ep_fbwas still 0, fb_val was sent in EP0.

Actually there are multiples tud_audio_set_itf_cb inside audiod_set_interface, in the callback there is no way to identify them.

I see, this means we can not rely on the host to open the feedback EP first. Anyway, it should be possible t...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #938: Bug fix and Enhancements of UAC2

Ahhh man, i need more sleep ^^ Yes you are right! Mhhh... ok it seems passing the request pointer to the user is kind of useless then. How about splitting the CB into four parts: CB_EP_IN, CB_EP_OUT, CB_FB_IN, and CB_FB_OUT. I am currently not sure which parameters to pass for the CB functions but i guess those which are parsed within set_interface() are enough for the beginning! What do you think?

fallow birchBOT
wanton gust
#

does anyone know of a good tutorial for tinyusb on the raspberry pico in c?

fallow birchBOT
fallow birchBOT
glad sequoia
#

I'm trying to communicate between two Picos using CDC, the exchange goes:

  • A->B init
  • B->A data (repeated every 100ms)
  • A->B ack (at least every 2000ms)

I'd gotten as far as receiving data, but when I try to send the ack, it hits a panic: ```*** PANIC ***

ep 2 out was already available```

Is this a stack bug or am I doing something wrong, eg are there restrictions on where/when I can call tuh_cdc_send?

#

I've tried in either a cdc_task function in the main loop, or via a timer callback, same result in both cases.

glad sequoia
#

found a comment here which I think may explain: https://github.com/hathach/tinyusb/discussions/925#discussioncomment-933932 - the RP2040 USB controller can only do a single bulk or control transfer at once, which isn't what the host code expects... wondering if that's my issue

GitHub
RP2040/Pico USB serial host ยท Discussion #925 ยท hathach/tinyusb

I'm trying to have an RP2040/Pico act as a USB host for a USB serial adaptor. I can get the adaptor to be detected, but attempting to use tuh_cdc_receive results in a stalled error code, an...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #900: Only first bulk OUT EP write works

OT: looking onto claim/release functions, they are using mutex with RTOS... Did you consider using atomic_compare_exchange? It may require chaging that struct to bitfield (I am not very familiar with atomics in C, I work in C++), but locking mutex seems like an overkill for this.

There are 2 issue

  • atomic is gcc extension, also it kind of requires C11 or higher, not sure but it is technically resolvable (just take time...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
webbbn
[hathach/tinyusb] New comment on pull request #809: Esp32s2 \- make net lwip webserver workable

Thanks for putting in the effort to get this example at least partially working on the esp32-s2. I have been able to confirm that it at least brings up a valid network interface on Linux. For some reason Windows doesn't want to pull an IP address, but I've had that issue in the past, so It's not surprising. As you say, the web server is not working.

Any thoughts on moving this forward? The S2 seems like an obvious target, since it already has a full network stack.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #938: Bug fix and Enhancements of UAC2

I think I'm finished.

I have a question about interleaved copy decode/encode, nBytesToCopy is nChannelsPerFifo*nBytesPerChannel, in case of 2ch/24bit & 2ch/32bit nChannelsPerFifo has to be 1 since it handle only 1-4 bytes copy ?

Actually no, you have found another bug here! Instead of nBytesToCopy it should be nBytesPerSample i.e. audio->n_bytes_per_sampe_tx within audiod_interleaved_copy_bytes_fast_encode and likewise for the decode function. The amount of bytes t...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on pull request #938: Bug fix and Enhancements of UAC2

I think I'm finished.
I have a question about interleaved copy decode/encode, nBytesToCopy is nChannelsPerFifo*nBytesPerChannel, in case of 2ch/24bit & 2ch/32bit nChannelsPerFifo has to be 1 since it handle only 1-4 bytes copy ?

Actually no, you have found another bug here! Instead of nBytesToCopy it should be nBytesPerSample i.e. audio->n_bytes_per_sampe_tx within audiod_interleaved_copy_bytes_fast_encode and likewise for the decode function. The amount of byt...

fallow birchBOT
#
xmos-jmccarthy
[hathach/tinyusb] New comment on pull request #950: DFU improvements

Maybe additional buffer check is needed if transfer size is different for each alt settings.

CFG_TUD_DFU_TRANSFER_BUFFER_SIZE will have to be set to the largest buffer size used by an any given storage type. The recently added checks to prevent out of bounds memory accesses should be sufficient to catch these cases and alert the user if they make a mistake, but if you could add a note of that to the API header that would be great.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #950: DFU improvements

using alt interface as partition doesn't seem to be standard for USB DFU

In fact it's in the spec:

* Alternate settings can be used by an application to access additional memory segments.  In this case, 
it is suggested that each alternate setting employ a string descriptor to indicate the target memory 
segment;  e.g., โ€œEEPROMโ€.  Details concerning other possible uses of alternate settings are beyond the 
scope of this document.  However, their use is intentionally not restric...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #950: DFU improvements

In fact it's in the spec:

* Alternate settings can be used by an application to access additional memory segments.  In this case, 
it is suggested that each alternate setting employ a string descriptor to indicate the target memory 
segment;  e.g., โ€œEEPROMโ€.  Details concerning other possible uses of alternate settings are beyond the 
scope of this document.  However, their use is intentionally not restricted because the authors 
anticipate that implementers will d...
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@Wini-Buhhow I am still catching up with this PR. Would you compile rxcc on windows with stock example, I tried to use make command, however, since rxcc use different compile and linker option from command line than rxgcc and I don't understand it enough to make change to makefile to get it compiled. I guess you are having an e2studio project file, It would be great if you could share the file so that I could compiler and test it out.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach I will try to build a "stock example" with the e2studio and give you the project file. But I need to do that at the weekend and I can't test the example because I do not own the board used for the RX examples. In the meantime I show you the arguments given to the compiler, assembler and linker so you could see the how the command line options look like. You should find the description of each argument in the manual of the toolchain.
[commandline_options_examples.txt](https://github....

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #950: DFU improvements

In fact I missed out that only one functional descriptor is used in DFU class. (Thanks to dfu-util maintainer)

Indeed, I totally missed this one as well, I just checked the specs, it will be only 1 Functional DFU descriptor at the end after the series of the Alt Interface

ALT 0
ATL 1

ATL n
DFU Functional

I think in this case we need a refactor which expose only one time parameters in functional descriptor. Some VA_ARGS trick like TUD_BTH_DESCRIPTOR ?

we prob...

fallow birchBOT
fallow birchBOT
#
caipifrosch
[hathach/tinyusb] Issue opened: #957 write sequence of 512 byte blocks mixed up?

Operating System

Windows 10

Board

custom LPC1788

Firmware

custom firmware

What happened ?

TinyUSB with msc example got configured with 48 msc_disk[] blocks, 512 bytes each. Adding up to 24kB in total.

Writing a 16k file will start on SRAM memory blocks msc_disk[6] to msc_disk[21], then proceeds writing on block msc_disk[3] to msc_disk[5].

First: written blocks are less than 16kB (reading back file shows missing bytes as undefined, see screenshot)

Second: would ...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #957: write sequence of 512 byte MSC blocks mixed up? writing less than expected?

hmm, I have a feeling this may not be TinyUSB bug at all. It probably has something to do with FAT FS. The msc ramdisk example is a quick hack. You probably need to have a better fatfs implementation. TinyUSB work well with elm-chan fatfs on actual flash device and ghostfast (virtual fs) https://github.com/adafruit/tinyuf2/blob/master/src/ghostfat.c.

However, lpc1788 isn't used much, It could be lpc1788 specific issue. Can you try to enable the LOG=3 to see if there is any abnormal in t...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

thanks, a project file to compile with stock example is very useful, if you could make one for cdc_msc (for testing) then the net_lwip_server as well so that I could help. The example for compile option txt is useful, I wish I know these well enough to put that into makefile to easily switch between rxgcc and rxcc. But I don't think I could pull it off, and could be error prone. It is better to address one thing at a time and stick with things that work first.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #957: write sequence of 512 byte MSC blocks mixed up? writing less than expected?

Do you happen to have any samd21/51 or nrf52, pico boards to test with. Those are most used and tested mcus, just to rule out lpc1788 specific issue. Note: If you need my help to test this, please attach

  • modified example of cdc_msc
  • your 16KB file that is used to write to the disk

Note: I forgot to mention, the ramdisk example have 1 cluser = 1 sector = 512 bytes, you need to keep it in mind when inteprete the fat data, and need to make sure the total data (file payload + overhead) is...

fallow birchBOT
#
caipifrosch
[hathach/tinyusb] New comment on issue #957: write sequence of 512 byte MSC blocks mixed up? writing less than expected?

Thanks for picking this up. There is not enough ram to further increase ramdisk.

But after some debugging with 512byte sectors I can say:

  1. all sectors are written to 24kB ramdisk now
  2. unfortunately ramdisk is still starting 1st file at ramDisk sector 6
  3. missing sectors in flash are related to an LPC ram to flash copy problem (IAP copy function raises source address problem, probably because of some AHB peripheral blocking its access)

Because of point 3, I decided to complete...

fallow birchBOT
fallow birchBOT
#
KarlK90
[hathach/tinyusb] Pull request opened: #959 \[DRAFT\]\[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

Describe the PR

This is a rough first draft to support the GD32VF103 RISC-V MCU by GigaDevice. It uses the same Synopsys USB OTG full-speed peripheral that is found on the STMF105 and STM32F107. I have added the nuclei-sdk that adds support for the GD32VF103. I chose to extract register definitions for the OTG peripheral from the stm32f105.h headers and put them into synopsys_common.h in order to not rename all registers in the sources, ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-midi\-data
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #950: DFU improvements

No it is the correct approach !

tinyusb will response as busy in the mean time.

As the CPU is blocked by the Flashing process (Flash is even stalled) how does tinyusb respond ?

Take a look at DFU diagram, device should start flashing after the DFU_GETSTATUS response.
image

And my discussion with dfu-util maintainer also confirm this:

The device should allow the data tran...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #950: DFU improvements

@HiFiPhile @xmos-jmccarthy I have updated with lots of rename (minor) and also tweak behavior as well as flow for DFU callback . I also migrated away from state machine since I found it a bit more complicated (left in code for review only). In sum up

  • get_timeout() will be invoked (by GET_STATUS) before download_cb() and manifest_cb(). Since either has potential flashing op.
  • finish_flashing(status) ( renamed from download_complete() ) is called from application after download/manifes...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: HiFiPhile\-dfu
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #892: DCD SAM3U Support

I ported the initial driver from the samx7x, without dual port and dma implementation to reduce complexity, I have yet to test compile, but everything should be more or less ready.

If anyone could take a look to try to catch any major oversights by me, I don't know If I fully understood the working of the usb core :sweat_smile:.

I'm going to be out for a week, I won't pick this up again until then.

fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Issue opened: #966 Documentation

What is the current status with the documentation? It seems it has been left on hold while prioritizing other parts of the project, not criticizing ofc, I say this because of things like the domain www.tinyusb.org, is this the case?

That said I wanted to contribute and do some work on documentation, I think some online pages like this are best, is it ok If I work on that?
If so, what approach would be best? we can use something like github p...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #966: Documentation

thank you for your willing to contribute, indeed, documentation is lacking behind. since I don't quite have time to do it. For the approach, indeed, I prefer to to readthedocs #6 , the docs will be served via github pages. The domain is mostly for redirecting. Though, I haven't got time to set them up just yet, any PRs are welcome.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #950: DFU improvements

@HiFiPhile I only use auto format with portion of text selection where I want to. Normally I will just manual type it. Auto format is not enabled, since I couldn't figure out how to get it auto align =. Also it is a bit too strict, as long as the code look good, it is ok to go over line boundary (which I set to 120) or break rule. It is not too important, don't worry too much about it.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
BennyEvans
[hathach/tinyusb] Issue opened: #968 dcd\_synopsis driver fails to flush data of length 256 bytes when in HS mode

Operating System

Windows 10

Board

STM32H7

Firmware

examples/device/dcd_msc (tinyUSB 10.1)

What happened ?

The dcd_synopsys.c driver fails to flush when the data to flush is exactly 256 bytes in length in HS mode. Writing more data will eventually cause a flush but calling to flush with 256 bytes of data does not actually perform the transfer.

The line that I believe causes the issue is:
https://github.com/hathach/tinyusb/blob/21bfd11683c4bb6e0996130bd1061a97d3049121...

fallow birchBOT
#
cr1901
[hathach/tinyusb] New comment on issue #968: dcd\_synopsis driver fails to flush data of length 256 bytes when in HS mode

Unsigned overflow/changing requirements strikes again :(. This is definitely wrong, and was probably there since the initial PR. When I originally wrote the driver, I wrote it for a board without a HS PHY. HS was completely out of scope, and I don't think tinyusb supported it at all. In FS, the max xfer is 64 (IIRC), so I used a uint8_t and forgot about it. When HS support was added, the maximum possible xfer size went from 64 (IIRC) to 512, and nobody (incl me) updated that var to account ...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

I have tested this out on my same70 xplained board. It works well with board_test work for led & button. However on cdc_msc & hid_composite examples, but I couldn't get it enumerated at all.

here is my compile output (gcc9.3.1) , size seems to be a bit small

LINK _build/same70_xplained/cdc_msc.elf
CREATE _build/same70_xplained/cdc_msc.bin
CREATE _build/same70_xplained/cdc_msc.hex

   text    data     bss     dec     hex filename
  11080    8244    5060   24384    5f40...
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Are you also doing test with same70_xplained or other board

I test on same70-xplained and my own hardware.

It seems in board_init it lacks the switch to external xtal, and UDP_Handler should be USBHS_Handler

I'll try to update the BSP with my clock config:

/* Marco for register access */
#ifndef CLEAR_REG
#define CLEAR_REG(REG)        ((REG) = (0x0))
#endif

#ifndef WRITE_REG
#define WRITE_REG(REG, VAL)   ((REG) = (VAL))
#endif

#ifndef READ_REG
#define REA...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
josjkasan
[hathach/tinyusb] Issue opened: #972 ESP32\-S2 compile problem

Operating System

Windows 10

Board

ESP32-S2 Dev

Firmware

TinyUSB library, Arduino IDE, ESP Core 2.00A,

What happened ?

Hello! Sorry to start new issue, but I waste a lot of time with compile any example. I try Adafruit, Chegewara libraries, but anyway I didn't get any succes. Can you help me with list of all required steps and addons do be able to flash my chip? Or link with tutorial, or advice which IDE to use? Due to fact of using Windows 10, I'm not able to do like de...

#
HiFiPhile
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

I think something is wrong with the redundant init of clock, I removed the clock init in dcd and there is no more enumeration failure.

Once again EP0 bugged, OUT packet miss-aligned by one transfer.

USBD Setup Received 21 20 00 00 02 00 07 00
  CDC control request
  Set Line Coding
  Queue EP 00 with 7 bytes ...
USBD Xfer Complete on EP 00 with 0 bytes
NULL
  CDC control complete
  Queue EP 80 with 0 bytes ...
USBD Xfer Complete on EP 80 with 0 bytes

USBD Setup Received A1...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Clock initiation is supposed to be done outside tinyusb anyway is it not?

That also depends on the port, if the clock depends on bsp component such as xtal, and/or clock source etc. Generally, having it out of dcd make dcd more portable e.g easier to support other mcu such as sam3u etc..

@HiFiPhile I am currently busy on other work and couldn't help to fix this. We could merge this as it is and create an issue for it so that we could come back later on when having time. Of course, it...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #973: custom HID

There is an example of generic IN/OUT : examples/device/hid_generic_inout

It's pretty easy to customize, you can take a look of predefined descriptors in /src/class/hid/hid_device.h and replace TUD_HID_REPORT_DESC_GENERIC_INOUT with your own descriptor.

//--------------------------------------------------------------------+
// HID Report Descriptor
//--------------------------------------------------------------------+

uint8_t const desc_hid_report[] =
{
  TUD_HID_REPO...
fallow birchBOT
#
thierer
[hathach/tinyusb] New comment on pull request #911: Enable empty transfers for tud\_vendor\_n\_write\(\)

Something like this? (Compiles, but not tested).

It does not exactly what you wrote in that it doesn't check for a multiple, but the equivalent of the endpoint size, because the actual transfer can't really be bigger than the EP size? Or were you referring to the last bufsize parameter to tud_vendor_n_write()? If so, I don't understand what you want to achieve.

Even so I don't fully get the rationale behind that requirement. On the protocol level, the device can still send p...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: max\-endpoint
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

You know what, I fight for NAKed transfer for 2 days with a bad cable !

This cable works on my lpc4357 so I assume it's ok but in fact the connector of same70-xplained is a little loose lol...

It is probably more than the cable, I found that the bus is very sensitive. I could see it get passed enumeration if attached to the PC, but same70 refuse to communicate when using hardware analyzer. Which indicate it has some bus/phy issue.

Update: With [eec927e](https://github.com/ha...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

@HiFiPhile with latest push the cdc_msc now work great yeah !!! For analyzer, you are right about the cable, it work with very short cable (0.3m length), while other 0.5-1m doesn't, even that it works with other HS board such as lpc18xx. I guess it is more peaky than others.

Finally it works, though I go further to test with net lwip example, but it failed that one. Look like setup is still missing, it is probably overrun or race condition.

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

#
hathach
[hathach/tinyusb] Pull request review submitted: #693 SAMx7x \(E70, S70, V70, V71\) DCD Support

Superb work !! Thank you very much for your PR and effort to troubleshoot the issue with the PR. I have tested cdc_msc, hid_composite example both work greats. There is still issue with net_lwip_webserver and webusb examle, it is probably due to race condition and/or the missing setup etc ... Which we could definitely fix later with followup PRs. The race condition is more severe with HS since bus is much faster and so does the mcu.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #950 DFU improvements

Thank you @HiFiPhile for stating this PRs, and @xmos-jmccarthy for helping with the review. This PR is now ready, and I am glad that you are both happy with the changes. There is quite a bit of rename though, but it is to make it more like other class. If there is nothing else that need changes, I wink we could merge this. Any issues can be fixed as follow up PRs.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@Wini-Buh late response, I tried to import your project files, though look like it expect some certains file structure, and also missing some of your local files to build. This is why I don't like from IDE, it takes lots time to configure and setting up for an port/board and may not portable to other users.
image

Anyway, since I got the gccrx working well now, I will try to update PR t...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@hathach I will try to build a "stock example" with the e2studio and give you the project file. But I need to do that at the weekend and I can't test the example because I do not own the board used for the RX examples. In the meantime I show you the arguments given to the compiler, assembler and linker so you could see the how the command line options look like. You should find the description of each argument in the manual of the toolchain.
[commandline_options_examples.txt](https://git...

fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

@Wini-Buh late response, I tried to import your project files, though look like it expect some certains file structure, and also missing some of your local files to build. This is why I don't like from IDE, it takes lots time to configure and setting up for an port/board and may not portable to other users.

Anyway, since I got the gccrx working well now, I will try to update PR to my best effort so that we could merge this soon. Since the pr has been pending for so long, and have some...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Ok. Great to hear you got CCRX working well now. I mentioned that the project file alone maybe is not very useful for you.
If required I could of course build a complete e2studio project (with all sources) and send it to you.

Actually not rxcc, the gccrx though, sorry for not being clear enough. That allows to make changes, mostly rename compiler attribute and other minor clean up with confidence. I have push update to your fork to update PRs. Please pull first if you want to do furth...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #859 Adaptations for Renesas CCRX toolchain and Rx72N controller performed

It has been pending for awhile, although I couldn't get tested with ccrx, the modification look good. It also contains bug fix when using the stack with big-endian mcu (which isn't tested yet). I think it is best to merge it for now, and resolve the net_lwip_webserver example with ccrx as follow up PR later on. That example is complicated, there may need some config tweak with lwip (much like tinyusb) to work with rxcc as intended as well.

I did a bit of rename and cleanup (please do pu...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New branch created: readme
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #977 Support DFUse \(st extension\)

Is your feature request related to a problem? Please describe.
ST extension is aka DFU 1.1a has some special command such set address, erase etc... I am not sure if it is preferable over std DFU 1.1 but it seems to be popular.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Wini-Buh
[hathach/tinyusb] New review comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

For me it's OK to revert it. It is definitively required in the project I'm using tinyUSB, which is build in big endian and left bitfield order. I have already setup test code to investigate the problem deeper (for me it looks like a problem of the CCRX toolchain if the configuration I mentioned is used... and if so, there is maybe another workaround for it).
I keep you informed about the result of the investigation about this problem.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] Pull request opened: #983 Docs

Rework of the documentation

This unifies all the current information about the project in an online documentation page, this will be hosted on readthedocs.
This PR adds very little NEW information, but it builds a good foundation where further documentation can be built uppon.

To simplify the visualization of the PR the new docs can be preview here https://perigoso.github.io/tusb_docs_showcase/

Some docs need some priority work, like the new supported devices table, because i am not...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #983: Docs

superb !! Thank you very much for the hard work, it looks fabulously. There is only 2 minor issues

  1. I still want to keep most of the project information as part of the readme since that is where most github user will look at. I rather to present it right away than require an extra click to external doc page. We can rename it to readme.rst like contributors.rst
  2. The logo font doesn't look right, I would prefer to keep using the current logo. Do it need to be svg, I could try to export cu...
#
hathach
[hathach/tinyusb] New comment on issue #966: Documentation

You might notice the logo looks different, theres no particular reason for the change, except that I wanted an svg logo to embed in the docs and I had to make one from scratch, and I took some creative liberties.

Ah right, I notice that as well, to be honest, I like the old logo font more, I will try to export an svg using existing desgin file to use with doc page. Give me a bit of time, I am not really good with these image tool.

fallow birchBOT
fallow birchBOT
#
proppy
[hathach/tinyusb] New comment on issue #179: Repeated disconnections causes the cdc\_msc demo to stop functioning\.

I also eems to be getting error after flashing cdc_msc example on the fomu,

make BOARD=fomu CROSS_COMPILE=riscv64-unknown-elf-
dfu-util -D _build/fomu/cdc_msc.bin

See below:

[34541.026812] usb 2-3.3.2: USB disconnect, device number 50
[34541.298728] usb 2-3.3.2: new full-speed USB device number 51 using xhci_hcd
[34541.426773] usb 2-3.3.2: device descriptor read/64, error -32
[34541.662737] usb 2-3.3.2: device descriptor read/64, error -32
[34541.898728] usb 2-3.3.2: ...
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #859: Adaptations for Renesas CCRX toolchain and Rx72N controller performed

Thanks for confirmation, I will leave it on for now since you actually need it for ccrx. We could update it later as follow up PR. However, the bmAttributes (just right above) also use bitfield within struct, you may also need to check it out as well. Too bad, I couldn't test ccrx myself, they make it difficult to run on Linux.

Anyway, when you have time please try to run an very simply example using tusb_desc_endpoint_t struct (copy it to helloworld example), then write an value to the wM...

#
HiFiPhile
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Hi @fjgpereira ,

had to adapt the code to the new microchip include files from Harmony3 - XC32.

So with Harmony3 the register defines are different ?

Detected a few cache/DMA issues that were solved with 2 clean/invalidate cache instructions.

In the DCD driver I haven't included cache clean/invalidate since it's configuration dependant. For example in my case I use DTCM/ITCM and set normal sram to non-cached.

I can add a define to enable them when needed.

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #980 Waveshare OpenH743I\-C BSP

superb! thank you very much for your PR and effort to put the board hw issue note for user with same hardware. I understand there is a few special config for this board that prevent it to be part of the stm32h7 family here https://github.com/hathach/tinyusb/tree/master/hw/bsp/stm32h7/boards. e.g

  • Different ULPI DIR, NXT pin selection than the reset (this is easy)
  • Require an way to delay resetting PHY, but it is doable with nop and/or dwt I think

However, I still prefer to integrate it...

#
BennyEvans
[hathach/tinyusb] New comment on pull request #980: Waveshare OpenH743I\-C BSP

@hathach happy to help where I can and happy to test on my hardware if you integrate it later on. I agree that integrating it will be a better solution and less maintenance.

If you don't get around to integrating it within the next few weeks then I can have a go at it if you'd like? But I then run into the same problem of not having the other hardware to test on and ensure I haven't broken anything on those boards.

#
proppy
[hathach/tinyusb] Issue opened: #984 cdc\_msc fails to start on fomu

Operating System

Linux

Board

fomu

Firmware

examples/device/cdc_msc

What happened ?

I seem to be getting enumeration errors after flashing cdc_msc example on the fomu:

[34541.026812] usb 2-3.3.2: USB disconnect, device number 50
[34541.298728] usb 2-3.3.2: new full-speed USB device number 51 using xhci_hcd
[34541.426773] usb 2-3.3.2: device descriptor read/64, error -32
[34541.662737] usb 2-3.3.2: device descriptor read/64, error -32
[34541.898728] usb 2-...
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #983: Docs

Hm, I understand, the problem with that is that you end up with 2 places with the same information that you need to make sure is updated at the same time.
Maybe we could link the internal files used in the docs in the readme, it should be readable on github since it's just rst, the user still has to click but doesn't need to go outside github, it's a good compromise?

I can do the logo myself, do you know the name of the font? If not I can trace manually. SVG is vector graphics so you can't e...

fallow birchBOT
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Hi,

The include files i found on the Harmony3 project seem to have suffered a few changes, but for the most part the symbols are the same.
For instance most macros now require a value/parameter, etc, the USBHS_DEVDMA array now is spelled in upercase, etc.

In case it has any use, I placed a patch/diff file with the changes at [http://inocam.com/~fjp/dcd_samx7x_H3.diff]

Regarding cache, everything looked to be working fine with ICache enabled and DCache disabled, but to enable DCache
...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #983: Docs

Hm, I understand, the problem with that is that you end up with 2 places with the same information that you need to make sure is updated at the same time.
Maybe we could link the internal files used in the docs in the readme, it should be readable on github since it's just rst, the user still has to click but doesn't need to go outside github, it's a good compromise?

readme.rst should be displayed as readme.md on github if I am not mistaken e.g https://github.com/adafruit/circuitpytho...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

I think it's better to add a on/off switch, also for dcd_transdimension.
Clean/invalidate cache will cause hardfault in case of it is not enabled.
How I edited your comment :D

I didn't see any issue with rt10xx so far, I don't remember caching within stock example. If it is an issue on other MCU, it is better to detect if cached is enabled or not. Adding an macro is easy, but that config file is growing and already complicated to user (than I would like it to).

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #984: cdc\_msc fails to start on fomu
  1. It has been a while ( a year ) since last time I tested with fomu. I remembered last time I need to update its bitstream to certain version for it to work. Make sure you update it to latest first.
  2. Also, have you reported this issue to fomu team https://github.com/im-tomu , they understand their hw much better than me. If yes please provide the link, it may provide useful information to me. If not, please do so.
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Don't know about Microchip plans, but I looked into the include files supplied with XC32 compiler and found that it also uses the new naming conventions.

I didn't check if there are any standard macros to detect the Microchip tools/versions, but as the registers pointer names are different, maybe you can use something like this:

#ifdef USBHS_REGS
#define USBHS USBHS_REGS
#define PMC PMC_REGS

define MP (1)

#else

defne MP

#endif

and then add __MP...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

It is possible, but (transdimention) tdi is a bit extreme since all naming and register address and mapping is totally different between lpc and rt10xx. It is probably needed if we also bundle sam3u etc into the same dcd. However, it will depend on actual register naming/mapping from microchip. The naming here is not that bad, it seems only take an extra argument for some macros. Anyway, I would prefer to review actual code before making any decision at all.

fallow birchBOT
fallow birchBOT
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Actually most of the CPU initialization code and peripheral libraries is generated automatically by Harmony3 and I usually only look inside that code when I find some bug or hardware feature not implemented by the default code generated automatically, so I probably am not able to help.

However, MPU is disabled in the Harmony3 graphical tool, but I didn't check if it applies any default configuration.
Looking at the generated code, I also don't find any MPU initialization
(that is: I cann...

fallow birchBOT
fallow birchBOT
#
perigoso
[hathach/tinyusb] New comment on pull request #983: Docs

I have rebased with the logo you provided, I also added local links in the readme to all of the documentation, it's not perfect, but it's good enough for a quick glance at the documention without leaving github.

notice:
I have brought down the documentation repo
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

That's strange... so basically Harmony3 enable cache without prior MPU region configuration ?

I think that is the default Harmony3 settings for new projects.

When the MPU is enabled, it does offer a recommended configuration with 6 regions, ITCM, DTCM, SRAM, EBI_SMC, EBI_SRAM and QSPI, ranging from 0x0 to 0x8ffffffff, but I don't know what applies to 0xA0100000 without specifically defining another region.

fallow birchBOT
fallow birchBOT
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

And that is why Harmony is not used

So far I've found a few bugs in the auto-generated code, specially with unusual device configurations, but all in all, I think it has saved me a lot of time. However, I almost only use CPU and peripheral initialization code, avoiding other libraries and RTOS.
The tools for pin assignment were specially useful to draw the board schematics, as it helped choose peripherals and assign pins to each function. I think it helped get the first prototype PCBs w...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
fjgpereira
[hathach/tinyusb] New comment on pull request #693: SAMx7x \(E70, S70, V70, V71\) DCD Support

Sure you can save a lot of time, and if you're lucky you can have a good experience with it. But you run the risk of having a veeery bad time, it's just not reliable.

I suspected that and decided to use just a minimal set of features.
That's why I decided to try tinyusb instead of the Harmony's USB stack
that has lots of dependencies with other libraries and rtos.
For the same reason, avoided the E70 GMAC and corresponding TCP/IP stack and
instead chose an WizNet W6100 for TCP/IP.

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
majbthrd
[hathach/tinyusb] New comment on issue #884: net\_lwip\_webserver reaches "endpoint busy" race condition on STM32F411DISCO

Alas, this seems to be a "feature" of the RNDIS driver bundled into recent Linux distributions. This newer Linux RNDIS driver fires off a bunch of RNDIS queries (via EP0) without first reading the notification EP response to the query/queries that it already sent. D'oh.

The workaround that Iโ€™m tempted to submit as a PR would be to add an if-busy check to netd_report() in ./src/class/net/net_device.c:

void netd_report(uint8_t *buf, uint16_t len)
{
  // skip if previous report no...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-midi\-available
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kripton
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Okay, got it working. Commit still pending, need to clean up some bits. Just for quick reference:
New function:

void flatten(void *arg, uint8_t *buffer, uint16_t size) {
    pbuf_copy_partial(arg, buffer, size, 0);
}

Then modify the existing linkoutput_fn:

static err_t linkoutput_fn(struct netif *netif, struct pbuf *p)
{
    (void)netif;
      if (!tud_ready())
        return ERR_USE;

      tud_ncm_xmit(p, p->tot_len, flatten);
      return ERR_OK;
}
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: perigoso\-docs
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #983: Docs

@perigoso thank you very much for the update. This is a great update so far, I couldn't pull it off myself. However, in addition to dedicated documentation site, I still think the github readme.rst is one of the most important doc and should present the complete overview of the project like it does before. I wouldn't mind if there is duplication at this stage, we will try to enhance the rst doc later on (I still have to learn how to write doc for API anyway) and reduce the duplication later o...

fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #959 \[DRAFT\]\[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

Sorry for keeping you waiting, I have been overwhelmed with other paid work and non-work (real life) issue that we are all facing. Anyway, I finally manged to review this PR, it is much easier than I thought, you are doing a really great work !! Though there are only couple of minor feedbacks

  1. nuclei-sdk is overkill, please use the simpler firmware library from gigadevice for low level mcu. Since the stack doesn't need anything else
  2. please add the ST license to the synopsys_common.h
#
hathach
[hathach/tinyusb] New review comment on pull request #959: \[DRAFT\]\[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

ah right, this is quite a pain that GD32V name register differently despite they are pretty much the same thing. I am ok adding this for gd32, some other non-stm may need this as well since synopsys dwc controller is quite popular. There is only one issue though, I think most of the definition is from ST driver, we should keep their license in this file, luckily it is compatible with MIT so we are all good.

fallow birchBOT
fallow birchBOT
#
KarlK90
[hathach/tinyusb] New review comment on pull request #959: \[DRAFT\]\[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I completely agree that the nuclei-sdk is overkill for this port, but I had chosen it over the multiple other repositories of the GD32VF firmware on github because their repository is the most up to date one and actively maintained by nucleisys which provided the RV32 core IP. Furthermore there is a bug in the startup code that throws an compilation error if -Wundef and -Werror is used with GCC, for which I had opened a PR. Therefor...

fallow birchBOT
#
kripton
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Hi @majbthrd: Thanks for having worked on this! I've had a look at the code and used it in my project. It works just as fine as the version in this PR, with fewer changes in the library-using code. Well done, thanks!
Of course, it's still an API-breakage for everyone using tud_network_can_xmit I guess?

I've added the "Microsoft OS 2.0 compatible descriptor" with "WINNCM" string to my project. The device works like before on Linux. Didn't test macOS this time. On Windows, the device enum...

fallow birchBOT
#
majbthrd
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Hi @majbthrd: Thanks for having worked on this! I've had a look at the code and used it in my project. It works just as fine as the version in this PR, with fewer changes in the library-using code. Well done, thanks!

Thanks @kripton

My goal was keeping things as similar as possible, but if complete backwards compatibility is deemed necessary for code acceptance, this can be remedied by having a new API tud_network_can_xmit_bytes() to provide the size that the NCM driver wants and the...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I pull the nuclei and did a quick check, the https://github.com/GigaDevice-Semiconductor/GD32VF103_Firmware_Library is more updated in term of the mcu driver. The last activities you said in 2020 is update the mcu lib to v1.1. while nuclei still uses the v1.0 version. nuclei is more maintained by it is mostly for their platform, tinyusb is only interested in low level mcu driver (clock, register def). Therefore I think it make more sense to move to the said repo.

#
hathach
[hathach/tinyusb] New comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I have rebased on the latest master and pushed my changes! Thanks for your review and no need to apologize, I hope everything is well

If you find the time, then I'm curios what you find out about the strange errors I had with the demos and tinyuf2 bootloader.

I will look at that, though I think firstly we need to make sure all stock examples in this repo run well with vf103 first. Since it is new port, it ma...

fallow birchBOT
#
KarlK90
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I'm a bit confused the latest firmware library from GigaDevice is 1.1.2 from June 2021 but can only be found on http://www.gd32mcu.com/en/download/0?kw=GD32VF1 so all the repos are outdated. Judging from the activity in repositories all but nuclei-sdk seem to be unmaintained, as no pull request are merged or answered.

I hope that I don't bother you with this discussion, but I think that nuclei-sdk is the better choice from a maintenance perspective and I would happily open a PR to update t...

#
KarlK90
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

The whole risc-v ecosystem is really young and because of the decentralized and open nature of the ISA I doubt that something universal as CMSIS is going to emerge. So NMSIS is largely Nuclei specific as the processor core have vendor specific extensions but very well designed in my opinion. It also provides a CMSIS compatibility layer. Although for this port very few parts are actually used.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #983 Docs

Thank you very much @perigoso, this is a huge thing in my todo list. And I surely wouldn't pull it off without your help. This PR will make future updating document much easier than ever. There is still no API docs yet, but we will slowly but surely fill it up later on.

#
perigoso
[hathach/tinyusb] New branch created: perigoso\-readme\-patch
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I am not bothered at all, I have looked a bit more closer. To be honest, at first I thought Nuclei is a 3rd party, but look like they are IP creator similar to ARM. And Giga put Nuclei's N200 risc-v core into their silicon. Furthermore, Nuclei seems to spend much more effort on the software/firmware side than Giga does. And I could see why you prefer to go with their sdk. Feel free to correct me if I get it wrong.

https://github.com/Nuclei-Software/NMSIS is indeed a really great repo whic...

fallow birchBOT
#
kripton
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Yeah, I honestly don't mind the API change. I could have also lived with the much-changed API proposed by this PR if I can just have NCM working on Linux, macOS and Windows hosts ;). But of course less changes are to be preferred and it makes totally sense to not just ask if an xmit is possible but if an xmit with X bytes can be done. So the API change makes sense in the end.

I can confirm that the code from @majbthrd's branch is working fine on Linux (5.13.4, amd64), macOS (11.2.3, amd64)...

fallow birchBOT
#
kripton
[hathach/tinyusb] New comment on pull request #550: Add CDC NCM implementation

Sorry for the spam today but I got it working :+1:
The problem was that I copied the ms_os_20 descriptor table from https://github.com/hathach/tinyusb/blob/master/examples/device/webusb_serial/src/usb_descriptors.c#L169 and just replaced WINUSB with WINNCM. However, then of course it still referenced ITF_NUM_VENDOR (which was defined in my code since I wanted to use WebUSB's "landing page" feature) but was of course wrong for NCM. When I replaced that with ITF_NUM_CDC_NCM_CMD it sta...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #985: SAMx7x improvements

I checked out and tried with the PR but got into lots of USB issue, and cdc_msc doesn't mounted. Same setup work with existing master though. The symptom is pretty similar when using with long usb cable: enumeration complete but further transfer got stuck, I think it is due to PHY/bus unstable, it is probably already existed in master, but pr just make the timing (race condition) right to amplify the issue.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-doc
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
KarlK90
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

I am not bothered at all, I have looked a bit more closer.

That is good to hear!

You are totally right about Nuclei, they provided the N200/BumbleBee Core for the GD32VF103 to GigaDevice and kind of co-developed the firmware library. I'm not sure why GigaDevice doesn't show a bit more effort with their firmware, it is a bit frustrating.

I still don't want to force any other users to use nuclei sdk just to run the usb stack. They may already be on another platform/framework, that...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #985: SAMx7x improvements

I checked out and tried with the PR but got into lots of USB issue, and cdc_msc doesn't mounted.

a698dda fixed speed detection, maybe it's the problem.

Otherwise I'm a little out of idea...

I've tried self/bus powered, low/high optimization, with/without RTT logging...

@perigoso Could you make a test if your board ready ?

Perfect, this fixed the issue with my set up, work g...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

That is good to hear!

You know this much better than me, there is obvious reason why you prefer the nuclei sdk

You are totally right about Nuclei, they provided the N200/BumbleBee Core for the GD32VF103 to GigaDevice and kind of co-developed the firmware library. I'm not sure why GigaDevice doesn't show a bit more effort with their firmware, it is a bit frustrating.

Yeah, I figured it out, Giga doesn't spend much effort like ST do with their stm32

But by doing so we have a ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
Frogieder
[hathach/tinyusb] Issue opened: #1008 Examples not building for RP2040

Operating System

Linux

Board

Raspberry pi pico

Firmware

All example files

What happened ?

I tried building the example files according to the getting started guide. I copy-pasted all commands, choosing raspberry_pi_pico as BOARD. The build failed. Everything worked well when I chose feather_nrf52840_express as BOARD.

How to reproduce ?

Follow the steps in getting started guide and choose raspberry_pi_pico or pico_sdk as BOARD

Debug Log

**_../examples/device/...

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

@KarlK90 everything look great with latest commit, however, when I tried to flash your pr to my longan nano board, it does not seems to run at all. Maybe I haven't done it correctly,

  • I tried with both your recommend toolchain from embecosm and nuclei toolchain from https://nucleisys.com/download.php .
  • use dfu-util (flash target) to download firmware, and press reset button to reboot it.
$ make BOARD=gd32vf103_longan_nano all

   text    data     bss     dec     hex filename...
fallow birchBOT
fallow birchBOT
#
KarlK90
[hathach/tinyusb] New comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

@KarlK90 everything look great with latest commit, however, when I tried to flash your pr to my longan nano board, it does not seems to run at all. Maybe I haven't done it correctly

Great that my changes look good.

I think the flashing problem is connected to the buggy GigaDevice DFU bootloader that reports a transfer size of 2048 bytes, dfu-util versions 0.10 or the current master branch use the correct size of 1024 bytes. My suggestion is to confirm that the dfu-util version does ...

fallow birchBOT
#
PanRe
[hathach/tinyusb] New comment on issue #540: Better dcd synopsys fifo allocation for ISO

Maybe it is not the best approach to skip closing EPs for ISO stuff completely! This would prevent users to reduce the required EP size (by reducing the sample rate or the resolution) dynamically e.g. when some other EP needs to be opened. The UAC2 spec specifically mentions this kind of flexibility. I am quiet aware this is rarely used but right now it is possible to do so.

Can the DCDs of such devices not take care of this special requirements on their own? I admit there are some ideas r...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: correct\-hid\-inout\-example
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

Ah you are right, upgrading to dfu-util 0.10 and it successfully flash the device (even tried to force the upload-size with 1024 on 0.9 just to test, but it doesn't help). Thanks for suggestion, I will wire up to use it with jlink for faster developement.

The cdc_msc example have the cdc echo fine, however, the msc does not, I hook it into analyzer. Look like there is some issue when host read 4k of data. Notice that the data is corrupted with 0x55AA repeatedly somehow. Host give up a...

fallow birchBOT
#
KarlK90
[hathach/tinyusb] New comment on pull request #959: \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

Good to hear that the upgrade solved the problem with the flashing.

You are right about the timer, I set the wrong reload value. The systick timer is driven by the AHB clock divided by 4. On the current implementation the AHB clock should equal the system clock (72Mhz by default). I quickly pushed a fix, hopefully that corrects the blinking frequency.

Thank you for the debugging effort, you clearly have tools and knowledge that I lack :muscle:. The tinyusb HID examples worked fine from ...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: fix\-newline\-keycode\-usage
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1017 da1469x: Handle VBUS interrupt

Describe the PR
For salf-powered code should handle VBUS changes.
Function tusb_vbus_chaneged() was present but not used in bsp;

dcd_connect() was called only at startup which is fine for
bus-powered devices.
If device was self-power and started without VBUS present
some registers would not be correctly set.

Now tusb_vbus_changed() is called whenever actual change on VBUS
is detected starting and stopping USB state machine.

Additional context
Tested only with da1469x_d...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
NikitaKhalyavin
[hathach/tinyusb] Issue opened: #1018 stm32\_fsdev builded by keil with \-\-gnu option \- enumeration fails

Operating System

Windows 10

Board

custom board with stm32f103c8t6

Firmware

examples/device/cdc_msc, but adopted manually for keil project with --gnu compiler option

What happened ?

When project is builded by keil armcc compiler, enumeration fails. The reason is a weak attribute in dcd_edpt0_status_complete function definition (dcd.h, string 135). The armcc compiler ignores function implementation in dcd_stm32_fsdev.c, and because of that device address is never actually...

fallow birchBOT
#
kasjer
[hathach/tinyusb] Pull request opened: #1019 da1469x: Fix no VBUS startup

Describe the PR
For self powered device if device started without VBUS present
it would not be correctly attached to USB bus even if tusb_vbus_changed()
was later called.

This modifies dcd_init() so it starts USB state machine without checking
if VBUS is present or not, like all others drivers do.
tusb_vbus_changed() function is also removed its content was moved to dcd_init.

Additional context
VBUS connect/disconnect handling similar to what is done in NRF5x maybe
do...

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: rp2040\-disconnect\-suspend
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1020 Add Rp2040 suspend & resume support

Describe the PR
This PR update rp2040 devvice

  • Add supsend and resume support, comment out disconnection interrupt since it is not detectable since we are forcing vbus detect
  • comment / whitespace / clean up dcd rp2040 e.g stall / clear stall
  • reset all endpoints upon bus_reset (previously only allocated once per power), however, device can dynamically change its configuration. It is better to enumerate with a clean state.

hopefully fix https://github.com/adafruit/circuitpytho...

karmic falcon
#

Hi, I am trying to work with TinyUSB on the Feather M4 CAN so that it shows up as an MSC device. I have the ramdisk example running, but I was wondering if there was a way to change the name of the drive when it is mounted to the computer. Currently it is "TinyUSB MSC" and I don't see and commands to change it on the device. Any help would be appreciated!

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1019: da1469x: Fix no VBUS startup

I am totally OK with changes, though would it increase the power usage since USB PHY is now enabled even without attaching to a host. I am not familiar with DA1469x enough to tell, though on nRF5x (which is also BLE mcu), which has its own off the standard API for managing power event ( vbus detect, ready, removed)
https://github.com/hathach/tinyusb/blob/master/src/portable/nordic/nrf5x/dcd_nrf5x.c#L839

It will only enabled USB peripheral and highspeed clock when vbus is stable (ready) a...

fallow birchBOT
#
kasjer
[hathach/tinyusb] New comment on pull request #1019: da1469x: Fix no VBUS startup

@hathach I think we could merge it like this for now. I will prepare VBUS handling since users will want to use power saving but for now it is more important to have USB working when it was not present on reset.

I already had something working to detect VBUS. In my first attempt I used dcd_connect/dcd_disconnect when VBUS was detected/lost (I think it worked). But then I was not so sure if this is correct way do handle this.
Maybe tud_connect and tud_disonnect are meant for application le...

fallow birchBOT
#
NikitaKhalyavin
[hathach/tinyusb] New comment on issue #1018: stm32\_fsdev builded by keil with \-\-gnu option \- enumeration fails

Ok, sorry for this. I've created a repo with working project.
How to reproduce:

  1. git clone https://github.com/NikitaKhalyavin/tinyusb_stm32f103_test_in_keil
  2. cd tinyusb_stm32f103_test_in_keil/
  3. git submodule update --init --recursive
  4. open usbTest.uvprojx in Keil
  5. build and run on bluepill board - this causes enumeration error
  6. rebuild with removed weak attribute in function dcd_edpt0_status_complete definition (file tinyusb/src/device/dcd.h) and rebuild - this works correc...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #959 \[PORT\] Add GD32VF103 support and Sipeed Longan Nano Board support

@KarlK90 Thank you very much for the PR and your patient. I have spent an hour or so trying to see if I could spot any obvious issue. Unfortunately, I couldn't, it may need a overall revise of the dcd. which I don't have the bandwidth to do at the moment. It is relatively normal for an new port, I have to do something similar with esp32 (also using synopsys IP). Therefore I think it is best to merge this to master and then file an issue so that other people can get on helping to resolve this...

#
hathach
[hathach/tinyusb] Issue opened: #1022 GD32VF103 issue with MSC

Operating System

Linux

Board

Sipeed Longan Nano

Firmware

examples/device/cdc_msc

What happened ?

The cdc_msc example have the cdc echo fine, however, the msc does not, I hook it into analyzer. Look like there is some issue when host read 4k of data. Notice that the data is corrupted with 0x55AA repeatedly somehow. Host give up and decide device isn't properly formatted. It is probably buffer/endpoints config/overflow issue etc .. which is typical for a new port ba...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: nrf\-suspend\-resume
fallow birchBOT
#
duempel
[hathach/tinyusb] New comment on issue #179: Repeated disconnections causes the cdc\_msc demo to stop functioning\.

I just tested the bugfix from #1021 with a simple CDC application on a custom STM32F105 hardware.

Using the last commit 89e4586 before bugfix led into the known behavior which stopped the CDC class to work after a few reconnections.
Using the commit 48f17ef just after bugfix has always been stable to me. Even after 30 reconnections everything worked fine. Same positive behavior with the current master of course ๐Ÿ˜‰.

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: add\-hid\-boot\-example
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: suspend\-resume\-followup
#
hathach
[hathach/tinyusb] Pull request opened: #1026 skipped suspend/resume if not connected

Describe the PR
follow up to #1023 , while unplugging, the bus condition is not stable, suspend (bus idle for 3ms) and/or resume event can be accidentally triggered by hw detection e.g suspend -> resume -> unplug . This PR skipped suspend/resume handling if not connected i.e unplug is detected and suspend/resume is not handled yet. Not perfect, but reduce noise to application.

fallow birchBOT
#
hathach
[hathach/tinyusb] New review comment on pull request #1024: Fix nuc126 buffer copy with IAR

I checked the manual as well, it is not mentioned. But It is very likely that USB SRAM is byte access. So yeah, this PR is spot on and needed.
https://github.com/majbthrd/nuc_driver/blob/master/nuc126/StdDriver/inc/usbd.h#L524

Only 1 request, would you mind adding an comment at this line and usb_memcpy below to explain the reason something like although it is not mentioned in manual, but the USB SRAM seems to only support byte access and memcpy could possibly do it by words etc ...

fallow birchBOT
fallow birchBOT
#
Wikingus
[hathach/tinyusb] New comment on issue #842: Usb host: controller pad and midi host

Hello
I join the request.
We need a good library to support a PS4 Pad for Rp pico with Bluetooth support.
A library that supports more than just buttons, but also colors and vibration.
I was about to start writing one, but I have no idea about tinyusb, I just tried to learn something, but at the moment I have no knowledge to write such a library with HOST USB and BT support.

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1027: Remove redundant SOF processing from the Renesas RX family\.

great thanks, I was wanting to do this as well as follow up, since #1023 is focused on nrf. Though I think we should only enable SOF when suspended and disable it afterwards. The reason is that SOF is currently not used at all by USBD https://github.com/hathach/tinyusb/blob/master/src/device/usbd.c#L1082 didn't submit the SOF event to usbd task queue. The reason is that I am not entirely sure if SOF is really needed for driver, mostly only audio/video where it has strict timing constraint wit...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request review submitted: #809 Esp32s2 \- make net lwip webserver workable

Sorry for the wait, I have tried to compile and flash this PR to saola_1 board. It shows up as network interface (great works). However, I couldn't access the webserver at 192.168.3.1 . I have checked the modification, unfortunately, I am not too familiar with esp network stack to notice any obvious issue.

I agree with the approach using esp native stack API, which is most people would do. However since it is not compatible with other port which use generic lwip. I think it is best to mak...

fallow birchBOT
#
me-no-dev
[hathach/tinyusb] New comment on pull request #809: Esp32s2 \- make net lwip webserver workable

I agree with the approach using esp native stack API, which is most people would do. However since it is not compatible with other port which use generic lwip. I think it is best to make this as spin-off example as net_esp_webserver and leave the existing example as it is.

I agree with @hathach here :) ESP should have it's own example. It will not mix with the other MCUs (which do not include LwIP in their SDK) and also make the ESP support much cleaner.

fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: merge\-waveshare\-h7
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: group\-f1
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: improve\-host\-stack
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
diggit
[hathach/tinyusb] Issue opened: #1039 CDC device receives garbage if it transmits first

Operating System

Linux

Board

Custom board with ULPI PHY and STM32H730

Firmware

cdc_dual example, with these changes:

  • with only one CDC enabled
  • loopback code disabled
  • Instead of looping back data from host back to host, device transmits data periodically since boot
  • CDC buffers raised to 4 kiB
	tusb_init();
	auto prev = ticks; // ticks are volatile variable incremented every 1 ms (systick).
	std::uint8_t data = 0;
	for(;;) {
		tud_task();

		const a...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] Issue opened: #1040 Potential fifo racing on self powered device

Operating System

Windows 10

Board

Custom NUC126

Firmware

In loop:

   uint8_t data[64];
    if(tud_vendor_write_available() >= sizeof(data))
    {
        tud_vendor_write(data, sizeof(data));
    }

What happened ?

This could happen on CDC & Vendor class which use fifo when USB is re-plugged.

Take Vendor class as example, fifo is cleared in vendord_reset when re-plugged, if fifo is fully written between vendord_reset and vendord_open, it will...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zxtxin
[hathach/tinyusb] Issue opened: #1042 API to get \_ctrl\_xfer status

I am porting tinyusb to the USB IP 'musbfdrc' from Mentor Graphics .
musbfdrc deals with the control transfer in a slighly different way that it needs CPU to explicitly denote a packet if it is the last packet of the transaction.
musbfdrc_ep0.pdf
Here is a brief introduction about what the CPU needs to do when dealing with control transfer. We can see that during IN DATA PHASE, when we put the last packet into the FIFO, w...

fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

when we put the last packet into the FIFO, we must set DATAEND bit.

you can detect that by using the xfer length of the dcd_edpt_xfer(). Maybe I miss something, would mind illustrate the issue you are having with the pseudo code based, with comment what is your issue, which info is missing. It is much easier to discuss over actual work.

fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: more\-host\-improvement
#
mbruno-xmos
[hathach/tinyusb] New comment on issue #537: Race protection for multiple core MCU

Related, though perhaps not exactly the same, it would be nice if tud_task() was safe to call from multiple RTOS threads.

I have an application that does USB audio, which requires that the UAC2 driver be pretty responsive with low latency. The same same application also handle vendor requests on endpoint 0 inside tud_vendor_control_xfer_cb(). Responding here can be slow, and can cause tud_vendor_control_xfer_cb() to block for several milliseconds. While it is blocked, the audio endpoint tr...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: host\-hid\-controller
fallow birchBOT
fallow birchBOT
#
jcummings2
[hathach/tinyusb] Issue opened: #1048 tud\_ready returning true when not connected to mass storage host

Operating System

Windows 10

Board

Feather M0 with added flash and battery including switch

Firmware

/*********************************************************************
 Adafruit invests time and resources providing this open source code,
 please support Adafruit and open-source hardware by purchasing
 products from Adafruit!

 MIT license, check LICENSE for more information
 Copyright (c) 2019 Ha Thach for Adafruit Industries
 All text above, and the splash ...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #842: Usb host: controller pad and midi host

host hid controller is added with ps4 dualshock support here https://github.com/hathach/tinyusb/pull/1047 .
video demo https://twitter.com/tinyusb/status/1430406301553594372

For more advance feature e.g set LED. vibrate motor etc check out linux driver for hint https://github.com/torvalds/linux/blob/master/drivers/hid/hid-sony.c

I will close this issue for now, midi host driver will take very long time since there is no plan (and no time) for it at the moment.

fallow birchBOT
fallow birchBOT
#
mws-rmain
[hathach/tinyusb] Pull request opened: #1049 Added support for Microchip Curiosity Nano SAMD21 board \(DM320119\)

Added support for Microchip Curiosity Nano SAMD21 board (DM320119) under hw/bsp/samd21/boards/curiosity_nano
The nEDBG on this board requires dap_protocol be specified as SWD (changed in examples/rules.mk)

NOTE: requires entry (03eb:2175) for VID:PID of nEDBG be added to /etc/udev/rules for pyocd

Describe the PR
A clear and concise description of what this PR solve.

Additional context
If applicable, add any other context about the PR and/or screenshots here.

#
hathach
[hathach/tinyusb] New comment on issue #537: Race protection for multiple core MCU

tud_task() is safe to called from RTOS as long as osal mutex is implemented. tud_task() essentially get event from rtos queue to process. This issue is more about MCU with multiple cores running on bare metal (no RTOS) and 2 cores can potentially cause race condition to each other. Btw which RTOS you are running.

Note: current vendor driver isn't thread safe , which is mentioned here. https://github.com/hathach/tinyusb/issues/900#issuecomment-870261839 Therefore it could be an issue, I wi...

fallow birchBOT
fallow birchBOT
fallow birchBOT
#
GrantMTG
[hathach/tinyusb] Issue opened: #1050 USB Ch 9 Set Configuration \(1\) fails following Set Configuration \(0\)

Operating System

Windows 10

Board

STM32F103BluePill

Firmware

Stock firmware example for stm32f103bluepill. HID example. File in question is usbd.c.

This is an uninformed guess, but if the Assert is removed, the test passes. I apologize if I don't understand the care and feeding of TU_ASSERT.

      case TUSB_REQ_SET_CONFIGURATION:
       {
         uint8_t const cfg_num = (uint8_t) p_request->wValue;

// GB:          if ( !_usbd_dev.cfg_num && cfg_num ) TU_A...
fallow birchBOT
#
dshadoff
[hathach/tinyusb] Issue opened: #1051 Host HID\_controller issues with controllers on RP2040

Operating System

Others

Board

Raspberry Pi Pico (RP2040)

Firmware

examples/host/hid_controller
Cloned from current tinyusb 'head' on August 25
Used in conjunction with current release of pico-sdk (1.2.0)

What happened ?

Tested with 2 controllers; results are as follows:

  1. Hori HORIPAD mini4 was enumerated/identified as VID = 0f0d, PID = 00ee, but example did not respond to any controller actions or button presses
    -> Modifying src/hid_app.c ( function 'is_sony_ds...
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1050: USB Ch 9 Set Configuration \(1\) fails following Set Configuration \(0\)

thank for your PR, I am able to reproduce the issue. The configuration switching requires an extra works with additional dcd API to make sure it is working correctly. Although it is possible to cheat the test since we only have 1 configuration, it is still better to implement it properly. I will try to get the stack fully passed the USBCV compliance test asap, so stay tuned.

PS: I did fixed an TD 9.4 test as well which is easier.

#
hathach
[hathach/tinyusb] New branch created: usbcv\-compliant\-test
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on issue #1050: USB Ch 9 Set Configuration \(1\) fails following Set Configuration \(0\)

getting it passed for now with a new empty API. There is a really stretch test with 150 enumerations with CV, really nice thing

Now Starting Test: TD 9.16 - Enumeration Test(repeat 150 times)
Start time: Aug 26, 2021 - 17:13:02
Device speed is Full.
Beginning enumeration test with 150 enumerations.  This may take several minutes to complete.
......................... 25 enumerations
......................... 50 enumerations
......................... 75 enumerations
...............
fallow birchBOT
#
mws-rmain
[hathach/tinyusb] New comment on pull request #1049: Added support for Microchip Curiosity Nano SAMD21 board \(DM320119\)

Updated the PR with your 'PYOCD_OPTION' suggestion - great idea (I figured a global change like that would be an issue).

For what it's worth, I reported the issue with nEDBG not responding to correctly unless the protocol was explicitly set to swd. The maintainer was 'surprised', but just figures it's a bug in the implementation with that specific device (nEDBG has different USB PID than EDBG).

Thanks for the tip re:ataradov/edbg. Will check it out at some point, but since your projec...

fallow birchBOT
#
jcummings2
[hathach/tinyusb] New comment on issue #1048: tud\_ready returning true when not connected to mass storage host

most of other adafruit has external flash on board, is your Feather M0 an non-express version without spi flash on it ? Do you have any other M0, M4 board to test with.

Correct, the Feather M0's I have are the non-express version that does not have external flash. I believe the first firmware above should work with minor modifications to point at the on-board external flash.

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1040: Potential fifo racing on self powered device

it may not be needed, can you reproduce the issue with cdc ?

If the user protocol is character based it won't be needed since buffer will be flushed at next write.

But if the protocol is packet based it could happen, same as I experienced in vender class.

void main(void)
{
    board_init();
    tusb_init();
    while(1)
    {
        tud_task();
        cdc_task();
    }
}

typedef struct
{
    char text[40];
    uint32_t a;
    uint32_t b;
}Status_t;

Status_t...
fallow birchBOT
fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

@zxtxin
Why not check wLength of a setup packet in order to know the actual total length requested by the host of each transfer.
My understanding, only the last packet of a data stage should be set DATAEND bit. If it true, I guess wLength should be check.

For example, net_lwip_webserver log is shown below.

USBD Setup Received 80 06 00 02 00 00 4B 00 
  Get Descriptor Configuration[0]
  Queue EP 80 with 64 bytes ...
USBD Xfer Complete on EP 80 with 64 bytes
  Queue EP 80...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
zxtxin
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

@zxtxin
Why not check wLength of a setup packet in order to know the actual total length requested by the host of each transfer.
My understanding, only the last packet of a data stage should be set DATAEND bit. If it true, I guess wLength should be check.

For example, net_lwip_webserver log is shown below.

USBD Setup Received 80 06 00 02 00 00 4B 00 
  Get Descriptor Configuration[0]
  Queue EP 80 with 64 bytes ...
USBD Xfer Complete on EP 80 with 6...
#
zxtxin
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

@zxtxin when the dcd_edpt_xfer() is called with 64, it means there is only 64 bytes, and you must set DATAEND bit. DCD must not add ZLP, if an ZLP is needed dcd_edpt_xfer with an length of zero will be called afterwards.

For GET_CONFIGURATION request, usb device often send more than 64 bytes to EP0_IN endpoint. For example, the length is 80 bytes, tinyusb will call dcd_edpt_xfer(64) for the first time and then call dcd_edpt_xfer(16). So the DATAEND bit should be set at dcd_edpt_xfer(16)...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

But now there is no API that I can use to get wLength.

@zxtxin
I think you can get wLength without any API.
A typical USB controller has dedicated registers to indicate whether a received packet is a setup packet or not. dcd layer, when it receives a packet, checks the dedicated register to detect whether the packet is a setup packet or not. If the packet is a setup packet, dcd layer has to call dcd_event_setup_received to pass the setup packet into usbd layer.
At that point, you ...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

But there is a risk. If the total length of DATA PHASE is just 64, there might be only one 64 byte-packet. In this circumstance, this code can't set DATAEND bit correctly.

Your implementation is totally ok, if the DATA PHASE length is 64 bytes USBD layer will send another ZLP packet.

So with ZLP packet last = true and DATAEND is set.

There is no need to read wLength.

fallow birchBOT
#
BennyEvans
[hathach/tinyusb] New comment on pull request #1033: merge waveshare to h7 family

@hathach I've just tested and most seems to be working except for the FreeRTOS example. I believe you still need SysTick->CTRL &= ~1U; at the beginning of the initialisation to ensure you don't enter the systick ISR. I'm not sure if you want to add that in a broader sense or just for this board.

I haven't tested every example but have tested a few in both FS and HS. UART logging all seems to be working well. Once the FreeRTOS examples are fixed, I'll perform some more testing. My board i...

fallow birchBOT
#
kkitayam
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

I think that when host requests a control read transfer with a multiple of 64(=max packet size) bytes length, it needs to check wLength.

In Universal Serial Bus Specification, Revision 2.0 5.5.3, data stages are described as follows.
image

My understanding is followings. When wLength is greater than the actual data size and is a multiple of 64, USBD layer needs to send ZLP. ...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1042: API to get \_ctrl\_xfer status

My understanding is followings. When wLength is greater than the actual data size and is a multiple of 64, USBD layer needs to send ZLP. When wLength is equal to the actual data size and is a multiple of 64, USBD layer does not send ZLP.

You're right.

Sorry I missed out that no ZLP is sent on data stage if length is multiple of 64.
https://github.com/hathach/tinyusb/blob/8d97f0e81f775d8c7646dfc75ee59b7e938bbf8d/src/device/usbd_control.c#L197

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New comment on pull request #1033: merge waveshare to h7 family

Thank you @BennyEvans for testing this out, yeah you are right, it is best to explicitly disabled systick to prevent its ISR triggered before scheduler start. It should be done for other family as well, but it is less of an issue since most of them board_init() finishes fast enough before the tick expire. I have expanded this to other stm families, should do for all, but I will do it gradually later on.

From your testing feedback, I think the PR is good for merged, no need for further tes...

fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: release\-0\.11\.0
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New tag created: 0\.11\.0
fallow birchBOT
#
hathach
[hathach/tinyusb] Pull request opened: #1058 nrf5x USB Compliance Verification Test suite

Describe the PR

Initial PR to get TinyUSB passed the USB complaince verification test suite (USBCV). The test suite include many corner cases which require changes to both usbd and dcd to pass. This PRs include the update to get nrf52840 ( board feather_nrf52840_express) to pass following:

  • Chap9 tests suite
  • HID test suite for hid_composite example
  • MSC test suite for cdc_msc/msc_dual_lun examples

More PRs to get all other MCU passed test suite will follow up in the future.
...

fallow birchBOT
#
hathach
[hathach/tinyusb] Issue opened: #1059 USB Compliance Verification Test Suite \(USBCV\)

What is this issue for

The test suite include many corner cases which require both update of usbd and dcd to pass. This issue is used to keep track of current status of compliance test of tinyusb device stack on each DCD ports. Once it is all passed, we could close this.

What is USB Compliance Verification (USBCV)

USBCV is test suite tool used by usb-if to verify all usb hardware/software/controller which is required to passed in order to have USB logo on the product. ht...

fallow birchBOT
#
HiFiPhile
[hathach/tinyusb] New comment on issue #1059: USB Compliance Verification Test Suite \(USBCV\)

I'm trying to test my project based on STM32L071.

SetConfiguration passed even without #1058

TD 9.13 - SetConfiguration Test (Configuration Index 0)Passed
INFO
Start time: Aug 30, 2021 - 14:23:20
INFO
SetConfiguration with configuration value : 0x1
INFO
Unconfigured the device
INFO
SetConfiguration with configuration value : 0x1
INFO

Stop time: Aug 30, 2021 - 14:23:21
INFO
Duration:  1 second.
INFO
Stopping Test [ TD 9.13 - SetConfiguration Test (Configuration Index 0...
fallow birchBOT
fallow birchBOT
fallow birchBOT
fallow birchBOT
#
hathach
[hathach/tinyusb] New branch created: samd\-compliance