USB power output issue with electrical test with AM335x

Hi Manbir,

I will forward this to the USB experts.

Manbir Jhawer said:

Also the wave pattern is not fully correct for the packet test on our own product

What do you mean by 'pattern is not fully correct'? Please provide mode details.

What SDK version do you use?

How did you initiate the test mode?

For SDK7.0 or 8.0, please refer to wiki http://processors.wiki.ti.com/index.php/UsbgeneralpageLinuxCore#musb_driver_TEST-MODE_debugfs_support for using MUSB test mode.

Hi Bin
The wave is not correct means that the wave doesn't seem to represent the 53 bytes sent by musb layer. Following is what we found in addition to my yesterday's query.
Actually the wave is correct for the first time. After the AM335X based board is boot-up, all three tests i.e. test J, K and test packet give correct o/p:
1) test J: +400 mV2) test K: -400 mV
3) test packet : correct wave as per the 53 bytes.
The issue happens after step 3. For example after board boot-up, the following sequences work
1) Reboot -> test J2) Reboot -> test K3) Reboot -> test packet
4) Reboot -> test J->test K-> test packet.
Anything additional will not work. For example, test j->test K-> test packet-> test J or K or packet will produce dramatically different results in the last step.
We got the following change to lock out another test from running, when one test is in progress:
diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 179d885..7119639 100644--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -189,6 +189,12 @@ static ssize_t musb_test_mode_write(struct file *file,
u8 test = 0;
char buf[18];
+ test = musb_readb(musb->mregs, MUSB_TESTMODE);+ if (test) {
+ dev_err(musb->controller, "Error: test mode is running\n");
+ return -EINVAL;+ }+ memset(buf, 0x00, sizeof(buf));
if (copy_from_user(&buf, ubuf, min_t(size_t, sizeof(buf) - 1, count)))
My query is as follows:
1) Why we need to lock out another test from running when one is in progress. Can we not stop the previous test being executed?
2) How to stop a test already in progress?My SDK version is version 7.
Thanks and RegardsManbir Singh Jhawer

Manbir,

Manbir Jhawer said:

4) Reboot -> test J->test K-> test packet.
Anything additional will not work. For example, test j->test K-> test packet-> test J or K or packet will produce dramatically different results in the last step.

Thanks for the clarification. Please revert the patch you mentioned, and use the following patch to see if the additional test will work.

diff --git a/drivers/usb/musb/musb_debugfs.c b/drivers/usb/musb/musb_debugfs.c
index 61638b7..5857913 100644
--- a/drivers/usb/musb/musb_debugfs.c
+++ b/drivers/usb/musb/musb_debugfs.c
@@ -207,8 +207,10 @@ static ssize_t musb_test_mode_write(struct file *file,
                test = MUSB_TEST_FORCE_HS;

        if (!strncmp(buf, "test packet", 10)) {
+               test = musb_readb(musb->mregs, MUSB_TESTMODE);
+               if (!(test & MUSB_TEST_PACKET))
+                       musb_load_testpacket(musb);
                test = MUSB_TEST_PACKET;
-               musb_load_testpacket(musb);
        }

        if (!strncmp(buf, "test K", 6))

Manbir Jhawer said:

We got the following change to lock out another test from running, when one test is in progress:

This patch was from me.

Manbir Jhawer said:

1) Why we need to lock out another test from running when one is in progress. Can we not stop the previous test being executed?

I noticed running 'test packet' test multiple times causes incorrect test packets on the bus, and the USB2.0 Specs require bus reset to exit test mode, so I made this patch to prevent the failure. But now I am thinking this patch may not be the proper fix. So could you please take the patch I pasted in this response instead and let me know your test result, then I will make a proper fix to the driver.

Manbir Jhawer said:

2) How to stop a test already in progress?My SDK version is version 7.

Right now the only way to stop a test is reboot the board, which leads to bus reset. But based on your test result with my new patch above, we might have a better way to stop it without reboot.

Manbir,

Here is another way to reset USB bus without reboot the board. You can use it to stop the current test and switch to a new test without reboot.

Assume the port under testing is usb1:

# cd /sys/bus/usb/drivers
# echo usb1 > unbind
# echo usb1 > bind

Thanks Bin Liu

Just correcting the path in previous post, in case someone else also needs:
cd /sys/bus/usb/drivers/usb