USB TESTMODE　Register

Hi Michi,

The TESTMODE register at addresses 0x4740_140F or 0x4740_1C0F has no special logic that prevents writing to it.  Are the clocks on and the reset not enabled?

Also make sure you are using 8-bit write access to these 8-bit registers.

BR,

Pavel

Pavel-san,

Thank　you for your support.

Our customer can write to the USB TESTMODE register. But USB signal does not be output.

They tested the following bit of the register.

TEST_K

TEST_J

TEST_SE0_NAK

They could not see the signal output with the above register setting.

Also they tested test packet. But it also can't output from AM3874.

Is there any problem?

This is urgent. Please reply me soon>

I appreciate your support.

Best regards,

Michi

Michi,

Michi Yama said:

Our customer can write to the USB TESTMODE register. But USB signal does not be output.

Do you mean that you have nothing on the USBx_DP/DM pins when enter in test mode?

Refer to the below wiki page:

http://processors.wiki.ti.com/index.php/Usbgeneralpage

To send test packet

 #echo "test packet" > /sys/kernel/debug/testmode 

To generate test K pattern

 #echo "test K" > /sys/kernel/debug/testmode 

To generate test J pattern

 #echo "test J" > /sys/kernel/debug/testmode 

To generate test SE0 NAK pattern

#echo "test SE0 NAK" > /sys/kernel/debug/testmode

Best regards,
Pavel

Dear Pavel-san,

Thank you for your support.

> Do you mean that you have nothing on the USBx_DP/DM pins when enter in test mode?

Yes, You right. Customer could not see any signals on USBx_DP/DM pins when enther in test mode.

Also I tried to enter the testmode on TI EVM. But the result was same. I could not see anything.

 I tried to write the testmode register directly. Please see the above memory dump list.  When I wrote "0x80" to 0x4740 140F (USB0_TESTMODE), some memory were

written at same time. The red number shows it. But it was no signal on DP/DM.

What is the wrong? Please give me your advice.

I must find this reason and work around in this week.

I appreciate your quick reply.

Best regards,

Michi

Michi,

Michi Yama said:

Customer could not see any signals on USBx_DP/DM pins when enther in test mode.

Michi Yama said:

I could not see anything.

Michi Yama said:

But it was no signal on DP/DM.

How do you measure the signal on USBx_DP/DM, with oscilloscope?

Do you have signal on USBx_DP/DM when USB in normal mode (not test mode)?

Please refer to the below links, might be in help:

http://processors.wiki.ti.com/index.php/Usbtest

http://processors.wiki.ti.com/index.php/Hardware_Design_Checklist#USB

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/261933.aspx

http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/154545.aspx

AM387x TRM, section 25.5.1.8 USB 2.0 Test Modes

Each USB2.0 controller supports the four USB 2.0 test modes (Test_SE0_NAK, Test_J, Test_K, and Test_Packet) defined for high-speed functions. It also supports an additional “FIFO access” test mode that can be used to test the operation of the CPU interface, the DMA controller and the FIFO RAM block.

The test modes are entered by writing to the TESTMODE register. A test mode is usually requested by the host sending a SET_FEATURE request to Endpoint 0. When the software receives the request, it should wait until the Endpoint 0 transfer has completed (when it receives the Endpoint 0 interrupt indicating the status phase has completed) then write to the TESTMODE register.

Note: These test modes have no purpose in normal operation.

25.5.1.8.3 TEST_K
To enter the Test_K test mode, the software should set the TEST_K bit in the TESTMODE register to 1. The USB controller will then go into a mode in which it transmits a continuous K on the bus. -- in this mode we should see K on the bus (DP/DN)

BR
Pavel

Dear Pavel-san,

Thank you for your quick reply.

As to your question, my customer 's USB logic is no problem. They are already using USB I/F with WEC7. Customer would like to measure the USB signal. So they would like to use TESTMODE register.

Is it needed some USB device for uisng TESTMODE? As to my understanding, AM3874 output the test pattern signal without device conection. Is it right?

Also, when I wrote "82h" to TESTMODE register, it indicates FORCE_HOST bit and TEST_J bit are set,  but I could not see any signal on DP/DM by oscilloscope.

Is there any my fault? 

And one more question,  you said me that TESTMODE register addresses are 0x4740_140F and 0x4740_1C0F. But I could not find it  on data sheet and TRM.

How did you find its offset address? 

Please let me know.

Best regards,

Michi

Michi,

Michi Yama said:

Is it needed some USB device for using TESTMODE? As to my understanding, AM3874 output the test pattern signal without device conection. Is it right?

I am not sure about this. Let me check with the USB designer. Meanwhile, can you try to attach some USB device, just for the test.

Michi Yama said:

Also, when I wrote "82h" to TESTMODE register, it indicates FORCE_HOST bit and TEST_J bit are set,  but I could not see any signal on DP/DM by oscilloscope.

Can you try with just set bit TEST_J, does it make any difference?

Michi Yama said:

And one more question,  you said me that TESTMODE register addresses are 0x4740_140F and 0x4740_1C0F. But I could not find it  on data sheet and TRM.

How did you find its offset address? 

USB0_TESTMODE register address is calculated as: USBSS base address (0x4740_0000) + USB0 Mentor Core base address (0x1400) + USB_TESTMODE offset (0xF)

USB1_TESTMODE register address is calculated as: USBSS base address (0x4740_0000) + USB1 Mentor Core base address (0x1C00) + USB_TESTMODE offset (0xF)

See AM387x TRM, section 25.9.6 USB Mentor Core Registers

BR
Pavel

Dear Pavel-san,

Thank you for your quick reply again.

Regarding TEST_J, I also tested it. And the result was same. There was no signal.

Then, thank you so much for address offset information.

I wait to receive more information from you again.

I really appreciate your quick answer.

Best regards,

Michi

Dear Pavel-san,

Thank you for your support.

I need to receive more information from you soon.

I appreciate your quick reply.

Best regards,

Michi

Michi,

I will check again with the USB designers. Sorry for the delay. Meanwhile, have you tested with external USB device attached?

BR
Pavel

Dear Pavel-san,

Thank you for your reply.

As to your question, Yes, I have tested both condition with USB device(mouse) and without USB device.

But result were same. I could not see any signal.

Best regards,

Michi

Dear Pavel-san,

Thank you for your support.

I am waiting to receive some information from you.

Then, I have one more request. If you have some source code for outputing test signal, please offer it to me.

Best regards,

Michi

Michi,

You can find several files from the linux kernel which are related to the USB test:

linux-src/drivers/usb/musb/musb_core.c
linux-src/drivers/usb/musb/musb_virthub.c
linux-src/drivers/usb/musb/musb_gadget_ep0.c
linux-src/drivers/usb/musb/musb_debugfs.c
linux-src/drivers/usb/musb/musb_procfs.c

The USBx_TESTMODE register is refered as MUSB_TESTMODE in the above source code.

Also I found some info regarding USB test mode for DM644x device, but might be similar with our DM814x/AM387x device:

If you are performing this test as a Device, after invoking the test, you will need to flip the switch so that you block the traffic coming from the Host.

If you are performing the test as a Host, after invoking the test, you will need to remove the attached device.

In both the above cases, if the fixture you are using does not allow to block the traffic or if you do not remove the target device, then there is some bus activity thag is caused by the attached device that would compromise your effort.

The best way to determine what is on the bus is to use a snooper and observe that the 53 bytes packet you are transmitting is seen on the bus repeatedly.

you can enumerate a known working device, like a Thumb Drive, then after you can force it to go into Test Mode (specifically Test Packet) in this case and the H/W will do what it is supposed to do. Of-course, prior to placing it into Test Mode, you would need to place the 53 bytes packet into the FIFO. Once you go into test mode, you will need to remove the known device.

The other way is to bybass the enumeration process that is done with a known good device and force it directly into test mode. Since you have no device attached to it, there is nothing to remove.

USB 2.0 Specification requires the support into going to test mode via h/w.

So long as you have initialized the core properly, for host operation, you pretty much have to do what you have done above.

unsigned int test_packet[53],i;

usb_init(); // you have this in the user's guide.

//Load 53 Bytes Packet
for (i=0; i<13; i++)
 usbRegs->FIFO0 = test_packet[i++];
usbRegs->FIFO0=((unsigned char)test_packet[53]);

//Go into TEST_PACKET Testmode
usbRegs->TESTMODE = 0x08;

//Start Driving Test Packet Data Out
usbRegs->PERI_CSR0 = 0x02; // Set TxPktRdy
while(1);

-------------------------------------------------------------------------------------

From other thread related to AM1x device:

The test packet data has to be written to the FIFO before putting the controller in the Test packet mode.

Two more threads that might be in help:

http://e2e.ti.com/support/embedded/wince/f/353/t/75845.aspx

http://e2e.ti.com/support/embedded/linux/f/354/t/203367.aspx

Best regards,
Pavel

Dear Pavel-san,

Thank you for your support.

Unfortunately our customer does not succeed to see the USB test signal yet.

They follwoed the instruction on the TRM for FIFO access. However they can't confirm the signal on the bus.

Do you have any advices to our customer?

Please let me know.

Best regards,

Michi

Michi,

Sorry for the late reply, I was out of office during the last week. Here are the answers for your questions: