USB NEXT loopback class with linux testusb util

RE: USB NEXT loopback class with linux testusb util

bb_elaDial — Wed, 12 Mar 2025 13:54:23 GMT

Hi Hieu,

USB hell is working to an extent that I can get a better understanding of the loopback.c (Since Shell commands also using content of loopback.c). but as far as linux-testusb goes I cannot get it to working. I will monitor the pull request. Thank you

RE: USB NEXT loopback class with linux testusb util

bb_elaDial — Mon, 10 Mar 2025 14:55:05 GMT

sample_usbd_init_device is comming from zephyr\samples\subsys\usb\common\.

You are right about the zephyr-testusb it,s not using the Next stack.

I found the following commit samples: usb: testusb: use new USB device stack by jfischer-no · Pull Request #85929 · zephyrproject-rtos/zephyr tring to do exactly what I want. but it was not merged yet.

let me try the shell example and get back to you, Thanks for assist

RE: USB NEXT loopback class with linux testusb util

Hieu — Mon, 10 Mar 2025 13:41:42 GMT

Is sample_usbd_init_device a custom function from you?

I looked into the testusb sample, and it doesn't use the Next stack by default. See testusb/prj.conf.
The USB Shell sample uses the Next stacks and also supports the Loopback class though. Could you please give it a try?

RE: USB NEXT loopback class with linux testusb util

bb_elaDial — Fri, 07 Mar 2025 15:29:13 GMT

Hi Hieu,

Apiologies for, not properly describing the testing process.

I'm not using any samples provided with zephyr.

however, I'm using zephyr\samples\subsys\usb\common as my initiating functions.

with zephyr\subsys\usb\device_next\class\loopback.c by Enabling the CONFIG_USBD_LOOPBACK_CLASS and CONFIG_USB_DEVICE_STACK_NEXT.

I did replace the ncs2.9 loopback.c file with one in the mainstream. due to missing functions that needed

my main.c is

static void msg_cb(struct usbd_context *const usbd_ctx,
                   const struct usbd_msg *const msg)
{
        LOG_INF("USBD message: %s", usbd_msg_type_string(msg->type));

        if (usbd_can_detect_vbus(usbd_ctx))
        {
                if (msg->type == USBD_MSG_VBUS_READY)
                {
                        if (usbd_enable(usbd_ctx))
                        {
                                LOG_ERR("Failed to enable device support");
                        }
                }

                if (msg->type == USBD_MSG_VBUS_REMOVED)
                {
                        if (usbd_disable(usbd_ctx))
                        {
                                LOG_ERR("Failed to disable device support");
                        }
                }
        }
}
int main(void)
{
        struct usbd_context *sample_usbd;
        int ret;

        sample_usbd = sample_usbd_init_device(msg_cb);

        if (!usbd_can_detect_vbus(sample_usbd))
        {
                ret = usbd_enable(sample_usbd);
                {
                        if (ret)
                        {
                                LOG_ERR("Failed to enable usb support !");
                                return ret;
                        }
                }
        }
        return 0;
}

Yes, I'm using the test that you mentioned above.

even though above test(s) failing , I managed to do vender request loopback and blk-out transaction with libusb (lusb-1.0) based application

before approaching this method I also ran the zephyr-testusb sample that included with ncs2.9 against linux-testusb and it passes all the tests. which also based on usb next api (If I correctly understand the sample)

so I'm curious to know, compatibility of loopback class with linux-testusb.

Thank you

RE: USB NEXT loopback class with linux testusb util

Hieu — Fri, 07 Mar 2025 11:08:44 GMT

Hi bb_elaDial,

I would like to confirm a few details to figure out a direction with this.

Are you running the USB CDC-ACM sample with usbd_next_prj.conf?
On the Linux end, by testusb, do you mean this? linux/tools/usb/testusb.c at master · torvalds/linux
Could you describe the test in more details?
When you say that only a few of them passed, how are you testing here? Are you testing one nRF device against multiple PCs, or are you testing multiple nRF devices against one PC?
Do you observe this on a Development Kit or on a custom hardware? If it's on a custom hardware, can you reproduce the issue on a Development Kit?
Do things work without using the USB Next stack?

Hieu