Access to USB_CTRL Register

Hi Zinovity,

Can you check if you can write in bit USB_CTRL[8] PHYCLKSRC ? This bit is 0 after reset, so can you try to write 1, and then verify that is 1. Thus we will be sure that you are in a supervisor (privilege) mode and nothing prevents you to write in this register.

Regards,

Pavel

Hi Pavel,

Yes, I can write to USB_CTRL[8] PHYCLKSRC.

Regards,

Zinovy.

Hi Pavel,

One more observation. After writing 0x02 to CM_DEFAULT_L3_SLOW_CLKSTCTRL[1-0] CLKTRCTRL bits I am expecting that bit 8 (CLKACTIVITY_USB_GCLK) in the same register should go high but that never happens. Is that Ok?

Regards,

Zinoviy.

Hi Zinoviy,

Can you try to write 0x2 in CM_DEFAULT_USB_CLKCTRL[1:0] MODULEMODE bit field. After this, bit CM_DEFAULT_L3_SLOW_CLKSTCTRL[8] CLKACTIVITY_USB_GCLK should be 1. Can you also confirm that bit MAINPLL_PWD[6] PWD_CLK6 is 0 ?

In DM816x TRM, section 3.2.6.1 USB PHY Power Down Control, is stated:

The USB modules can be clock gated using the PRCM; however, this does not power down/clock gate the PHY logic. You can put the USB PHY in the lowest power state, when not in use, by writing to the PWRDN bits in the USB control register (USB_CTRLx) of the Device Configuration Registers.

I am trying to locate the PWRDN bits. I suspect we have some misalignment in the TRM. I will let you know when I find something.

Regards,

Pavel

Hi Pavel,

Bit CM_DEFAULT_L3_SLOW_CLKSTCTRL[8] CLKACTIVITY_USB_GCLK  goes high after I write  0x2 in CM_DEFAULT_USB_CLKCTRL[1:0] MODULEMODE bit field. Also MAINPLL_PWD[6] PWD_CLK6 is 0.

Regards,

Zinoviy.

Hi Pavel,

Thank you for your clarification.

It seems like USB PHY is powered and working because I am able to bring the USB 0  in host mode. But I have met another register that can't be modified. This time it is Type Register (Host mode only) (USBn_HOST_TYPE0) register. The whole picture looks like the following. After USB PHY has been initialized the program resets the USB 0 controller by writing '1' into soft reset bit within USB0CTRL register and waits until reset is done. Then Host mode is selected by clearing bit8 (iddig) in USB0MODE register. Also bit 21 (otgdisable) is cleared in USB0UTMI register. Finally session is started by setting bit0 (SESSION) in USBn_DEVCTL  and the program waits untill a USB device is connected to the bus and host mode is enabled. For this USBn_DEVCTL register is polled untill bit2 (HOSTMODE) goes high.  When a USB device is connected the USB bus reset is signalled on the bus (set RESET bit in USBn_POWER register) . Reset is held for 30 msec and after that it is cleared (clear RESET bit in USBn_POWER register). Then the program waits for 20 ms to let the device recover from reset and determines if the connected device is a high/full/low speed device. Having determined the speed  of the device the program attempts to write the same speed in SPEED field of USBn_HOST_TYPE0 register . But USBn_HOST_TYPE0 register can't be modified. It's value remains 0. At the time when the program tryes to modify USBn_HOST_TYPE0 register the USBn_DEVCTL register value is 0x5D. 

What might be wrong ?  I am not able to write to USBn_HOST_TYPE0  register and as a consequence can't communicate with the terget device correctly.

Please, help!

Regards,

Zinoviy. 

// the reset.

Hi Zinoviy,

Can you first tell me the value of USB_CTRL0[16] USBID bit? 0 is for host mode, 1 is for peripheral mode.

Then I need to know the full address of the USBn_HOST_TYPE0 register that you use.

Also note that this is 8-bit register, and needs 8-bit access. Can you post the line of code that you use to access/write this register.

Regards,

Pavel

Hi Paul,

SB_CTRL0 register at 0x48140620 => value 0x0

USBn_HOST_TYPE0 register at  0x4740150A => value 0x0. This register is accessed like this:

HW_WRITEC(musb_speed << 6, &musbbr->ep[0].ep0.host_type0);

where,

#define HW_WRITEC(v,a) (*(volatile unsigned char*)(a) = (v))

musbbr is a pointer to Mentor USB core register overlay structure

Regards,

Zinoviy. 

Hi Paul,

Below is a log of U-boot session on 816x/389x EVM that demonstrates the problem with accessing USBn_HOST_TYPE0 register:

U-Boot 2010.06 (Jun 01 2011 - 12:30:57)

TI8168-GP rev 1.1

ARM clk: 987MHz DDR clk: 796MHz

I2C:   ready

DRAM:  2 GiB

NAND:  HW ECC Hamming Code selected

No NAND device found!!!

0 MiB

*** Warning - bad CRC or NAND, using default environment

Net:   <ethaddr> not set. Reading from E-fuse

Detected MACID:40:5f:c2:20:a3:12

Ethernet PHY: GENERIC @ 0x01

DaVinci EMAC Hit any key to stop autoboot:  0

TI8168_EVM#

TI8168_EVM#md.l 0x48180B14 1

48180b14: 00000000    ....

TI8168_EVM#mw.l 0x48180B14 0x00000060 1

TI8168_EVM#md.l 0x48180B14 1

48180b14: 00000000    ....

TI8168_EVM#md.l 0x48180514 1

48180514: 00000001    ....

TI8168_EVM#mw.l 0x48180514 0x00000002 1

TI8168_EVM#md.l 0x48180558 1

48180558: 00070000    ....

TI8168_EVM#mw.l 0x48180558 0x00070002 1

TI8168_EVM#md.l 0x48180558 1

48180558: 00000002    ....

TI8168_EVM#md.l 0x48140620 1

48140620: 00000000    ....

TI8168_EVM#md.l 0x47401014 1

47401014: 00000000    ....

TI8168_EVM#mw.l 0x47401014 0x01 1

TI8168_EVM#md.l 0x47401014 1

47401014: 00000000    ....

TI8168_EVM#md.l 0x474010E8 1

474010e8: 00000100    ....

TI8168_EVM#mw.l 0x474010E8 0x80 1

TI8168_EVM#md.l 0x474010E0 1

474010e0: 00200002    .. .

TI8168_EVM#mw.l 0x474010E0 0x02 1

TI8168_EVM#md.l 0x474010E0 1

474010e0: 00000002    ....

TI8168_EVM#md.b 0x47401460 1

47401460: 80    .

TI8168_EVM#mw.b 0x47401460 0x81 1

TI8168_EVM#md.b 0x47401460 1

47401460: 5d    ]

TI8168_EVM#md.b 0x47401401 1

47401401: 60    `

TI8168_EVM#mw.b 0x47401401 0x68 1

TI8168_EVM#md.b 0x47401401 1

47401401: 78    x

TI8168_EVM#mw.b 0x47401401 0x70 1

TI8168_EVM#md.b 0x47401401 1

47401401: 70    p

TI8168_EVM#md.b 0x4740150A 1

4740150a: 00    .

TI8168_EVM#mw.b 0x4740150A 0x40 1

TI8168_EVM#md.b 0x4740150A 1

4740150a: 00    .

Regards,

Zinoviy

This seems to work at my side, the 0x4740150A is 0x40:

Net:   <ethaddr> not set. Reading from E-fuse
Detected MACID:0:18:31:e6:da:e0
Ethernet PHY: GENERIC @ 0x01
DaVinci EMAC
Hit any key to stop autoboot:  0
TI8168_EVM#md.l 0x48180B14 1
48180b14: 00000000    ....
TI8168_EVM#mw.l 0x48180B14 0x00000060 1
TI8168_EVM#md.l 0x48180B14 1
48180b14: 00000000    ....
TI8168_EVM#md.l 0x48180514 1
48180514: 00000001    ....
TI8168_EVM#mw.l 0x48180514 0x00000002 1
TI8168_EVM#md.l 0x48180558 1
48180558: 00070000    ....
TI8168_EVM#mw.l 0x48180558 0x00070002 1
TI8168_EVM#md.l 0x48180558 1
48180558: 00000002    ....
TI8168_EVM#md.l 0x48140620 1
48140620: 00000000    ....
TI8168_EVM#md.l 0x47401014 1
47401014: 00000000    ....
TI8168_EVM#mw.l 0x47401014 0x01 1
TI8168_EVM#md.l 0x47401014 1
47401014: 00000000    ....
TI8168_EVM#md.l 0x474010E8 1
474010e8: 00000100    ....
TI8168_EVM#mw.l 0x474010E8 0x80 1
TI8168_EVM#md.l 0x474010E0 1
474010e0: 00200002    .. .
TI8168_EVM#mw.l 0x474010E0 0x02 1
TI8168_EVM#md.l 0x474010E0 1
474010e0: 00000002    ....
TI8168_EVM#md.b 0x47401460 1
47401460: 80    .
TI8168_EVM#mw.b 0x47401460 0x81 1
TI8168_EVM#md.b 0x47401460 1
47401460: 19    .
TI8168_EVM#md.b 0x47401401 1
47401401: 60    `
TI8168_EVM#mw.b 0x47401401 0x68 1
TI8168_EVM#md.b 0x47401401 1
47401401: 60    `
TI8168_EVM#mw.b 0x47401401 0x70 1
TI8168_EVM#md.b 0x47401401 1
47401401: 60    `
TI8168_EVM#md.b 0x4740150A 1
4740150a: 00    .
TI8168_EVM#mw.b 0x4740150A 0x40 1
TI8168_EVM#md.b 0x4740150A 1
4740150a: 40    @
TI8168_EVM#

Some of the other register values are not the same as yours, you can check these.

Regards,

Pavel

Hi Pavel,

Your register values are different because you don't have USB stick plugged in USB port 0.

If I unplug the USB stick I see the same rusult as yours exept the value in  register at 0x4740150A. It is always zero.

How do you boot your EVM ?  What is the CPU version?    I boot from the SD card.

Regards,

Zinoviy

I also boot from SD card. The version is TI8168-GP rev 2.1, 816x/389x EVM rev J.

I am using EZSDK 5.04.00.11 with u-boot-2010.06-psp04.04.00.01.

Regards,

Pavel

Hi Pavel,

I am using 816x/389x EVM rev G, CPU TI8168-GP rev 1.1, u-boot-2010.06-psp04.00.00.10.

I think that the problem is in CPU revision. Is it possible to find out what was changed between these two versions of CPU?

Regards,

Zinoviy.

Hi Zinoviy,

I will try to find what is the difference between CPU TI8168-GP rev 1.1 and rev 2.1.

Meanwhile, can you try with the new u-boot-2010.06-psp04.04.00.01. Do you have the same problem with the new u-boot?

Best Regards,

Pavel

Hi Pavel,

I have checked  u-boot-2010.06-psp04.04.00.01. The same problem :(. This time I boot EVM from the NOR flash but I don't think this is important.

Regards,

Zinoviy.

Hi Zinoviy,

At some places in TRM, the offset of the USBn_HOST_TYPE0 register is 0x10A, thus the full address is 0x4740150A. But in other place in TRM, the offset is 0x1A! Can you try to write the 0x40 value in 0x4740141A. I am still trying to find/confirm what is the correct offset for the USBn_HOST_TYPE0 register.

Other related information that I found, is located in the DM816x Silicon Errata

Advisory 1.1.15 USB Host Mode Cannot Perform Write Operation to TxFunction/TxHubPort/TxHubAdr Controller Addresses
Revisions Affected: 1.1, 1.0
Details: The USB controller does not support devices connected through a hub when operating as USB host. Due to this, writing to the TxHubPort/TxHubAdr results in the write being ignored.
Workaround: There is no workaround for this issue.

TxFunction should be USBn_TXFUNCADDRm, TxHubPort should be USBn_TXHUBPORTm, TxHubAdr should be USBn_TXHUBADDRm. All these 3 register groups belongs to the Mentor Core register map. There is nothing mentioned about the USBn_HOST_TYPE0 register, but as it belongs to the Mentor Core register map, I suspect that this silicon bug is valid here also. If true, you will have to switch to rev 2.0 or 2.1.

I will let you know when I find something more.

Regards,

Pavel

Hi Zinoviy,

I received confirmation that the full address for the USB0_HOST_TYPE0 is:  0x4740141A (0x47401000 + 0x400 + 0x1A)

Do you have the same problem (not able to write) with this address?

Best Regards,

Pavel

Hi,

Since we are not using the USB module, we would like to reduce power consumption by turning its PHY off.

I'm writing 1 to the PHYPDWN bit in the usb_Ctrl0/1 register, but when reading the register value its value is always zero.(The only bit that I managed to change in is the PHYCLKGD).

Since we don't have a way of measuring the power consumption of the USB module, we would like to use the value of this register to decide if the PHY is turned on, and if so to turn it off, and verify the writing by reading it back.

FYI. before trying to set the phypdwn bit I've made all the actions requiered by the process from the TRM:

*0x48180B10 &= 0xFFFFFF9F; // RSTCTRL (Release USB Module from Reset)
while ((0x48180B14 & 0x00000060)>>5)!=0x3); // Wait until Modules come out Reset
*0x48180B14 |= 0x00000060; // RSTST (Clear Reset Presence)
*0x48180514 |= 0x2; // L3_SLOW_CLKSTCTRL (Enable Interconnect Clock)
*0x48180558 |= 0x2; // USB_CLKCTRL (Enable USB OCP Clock)
while(((*0x48180558) & 0x70000)>>16)==0x7); // Wait until USB Module is Ready

Hi Asaf,

asaf hakun70 said:

Since we are not using the USB module, we would like to reduce power consumption by turning its PHY off.

You can try completely disable the USB from the linux kernel, thus it will be never enabled:

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

 [ ] USB support  --->

Or you can disable only the USB PHY:

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

 [ ] NOP USB Transceiver Driver

Regards,
Pavel

Hi,

Thanks for your reply.

We already done what you suggested, but still I'm not sure the phy it turned off.

What I'm talking about is in uboot level before kernel uploads..

You can look at the stages I've made at the beginning of this thread using mw/md commands.

This thread was closed because the guy wanted to turn the phy on, and it was already on in uboot level..

I would like to turn it off.

Why cant I change the value of the  PHYPDWN bit in the usb_Ctrl0/1 register although it is a r/w bit according to the TRM.

Asaf

Asaf,

Could you please open/create new E2E post with your specific questions.

Regards,
Pavel

Hi,

This thread represents exactly the problem I encountered.

I can open a new one if you like but could you please explain why it is needed?

Thanks,

Asaf

Asaf,

Are you using DM816x device? Are you using EZSDK 5.05.02.00?

Regards,
Pavel

we are using DM8168.

uboot version:

U-Boot 2010.06 (Jun 24 2014 - 17:25:47)

TI8168-GP rev 1.2

kernel version:

Linux netra 2.6.37 #1 Tue Jun 24 17:39:37 IDT 2014 armv7l GNU/Linux

the filesystem was built here using buildroot

Regards,

Asaf

Asaf,

This is what we have in DM816x TRM:

section 3.2.6.1 USB PHY Power Down Control

The USB modules can be clock gated using the PRCM; however, this does not power down/clock gate the PHY logic. You can put the USB PHY in the lowest power state, when not in use, by writing to the PWRDN bits in the USB control register (USB_CTRLx) of the Device Configuration Registers.

So, before trying to power down the USB PHYs, you should first switch/gate off the clock.

In EZSDK 5.05.02.00 u-boot (u-boot-2010.06-psp04.04.00.01), the USB and USB PHYs are disabled by default. We do not have USB support in u-boot. Thus clocks are switch/gated off.

TI8168_EVM#md 0x48180514 1
48180514: 00000001    ....
TI8168_EVM#md 0x48180558 1
48180558: 00070000    ....

Make sure you have the below values for:

CM_DEFAULT_L3_SLOW_CLKSTCTRL (addr 0x48180514) = 0x00000001 - this register switch on/off the USB PHY clock

CM_DEFAULT_USB_CLKCTRL (addr 0x48180558) = 0x00070000 - this register switch on/off the USBSS clock

Regards,
Pavel

Hi,

I have the register values as you described:

TI8168_EVM#md 0x48180514 1
48180514: 00000001 ....
TI8168_EVM#md 0x48180558 1
48180558: 00070000 ....
TI8168_EVM#

however trying to set PHYPDWN to 1(PHY powered off) is not working..

TI8168_EVM#mw.l 0x48140620 0x01
Entering do_mem_mw with address 0x48140620 count: 0x00000001 val: 0x00000001
TI8168_EVM#md.l 0x48140620
48140620: 00000000 ....

Regards,

Asaf

Hi,

Another input: when trying to write all ones to the usb_ctrl0 register the only bit that changes is PHYCLKGD:

TI8168_EVM#mw.l 0x48140620 0xffffffff
Entering do_mem_mw with address 0x48140620 count: 0x00000001 val: 0xffffffff
TI8168_EVM#md.l 0x48140620 0x1
48140620: 00000100 ....

Regards,

Asaf

Asaf,

asaf hakun70 said:

TI8168_EVM#mw.l 0x48140620 0x01
Entering do_mem_mw with address 0x48140620 count: 0x00000001 val: 0x00000001
TI8168_EVM#md.l 0x48140620
48140620: 00000000 ....

As I said, the USBSS and USB PHY are disabled by default in the EZSDK u-boot. Besides the clock signals switched off, I also have this value at my side:

TI8168_EVM#md 0x48140620 1
48140620: 00000000    ....
TI8168_EVM#mw.l 0x48140620 0x01
TI8168_EVM#md 0x48140620 1
48140620: 00000000    ....

Which means this is the correct value (0x00000000) in USB_CTRL for USB PHY to be powered off. I suspect our DM816x TRM (SPRUGX8B – March 2013) is not correct in some of its sections. In most of the cases DM816x datasheet (SPRS614E – MARCH 2011 – REVISED FEBRUARY 2014) is more up-to-date than the TRM, and in datasheet we have:

Table 5-4. Device Configuration Registers Summary

0x4814 0620 - USB_CTRL - USB Control
0x4814 0624 - USBPHY_CTRL0 - USB0 Phy Control
0x4814 0628 - Reserved
0x4814 062C - USBPHY_CTRL1 - USB1 Phy Control

This means we have one USB_CTRL register (not USB_CTRL0/1 registers). Also in DM816x TRM we have:

24.2.7 USB PHY Initialization
The registers used to control the PHY are USB_CTRL, USBPHY_CTRL0, and USBPHY_CTRL1. See Section 24.9.8 for the definitions of these registers.

*0x48140620 =0x0000_0003 //USB_CTRL Use PLL Ref Clock, Wake USB PHY1/00

24.9.8 USB Related Clock/PHY Control Registers
24.9.8.2 USB_CTRL Register - this looks to be the correct register description of the USB_CTRL register (not the one from section 1.16.1.3.8 USB Control Register 0 (USB_CTRL0)).

From this description, bits [0] PHYSLEEP0 and [1] PHYSLEEP1 are used to power on/off the PHYs:

USB PHY0/1 sleep mode control. Places Phy0/1 in Sleep mode per USB 2.0 LPM addendum.

0x0: sleep mode

0x1: Normal operating mode

This is aligned with the PHY init section:

*0x48140620 =0x0000_0003 //USB_CTRL Use PLL Ref Clock, Wake USB PHY1/0

Regards,
Pavel

Hi Pavel,

 Sorry but now I'm totally confused..

Zinoviy Lusatn opened this thread on 1/10/2012. He wanted to turn the usb PHY on, and tried to use the procedure being described in 24.2.7(usb phy initialization) in order to do so.

This procedure is based on one usb_Ctrl register located in 0x48140620. After writing 0x3 to this register in order to wake usb phy1/0(*0x48140620 =0x0000_0003 //USB_CTRL Use PLL Ref Clock, Wake USB PHY1/00), he read the register value back and got 0x00000000.

You replied to his post on 12/10/2012 and wrote that :

"According to some internal document data, on offset 0x620 is USB_CTRL0 register, which controls the USB0 PHY", And bit [0] PHYPDWN is :

USB PHY power down control

0x0: PHY powered

0x1: PHY power off (reset value)

(you also described the second usb ctrl register(USB_CTRL1)located in offset 0x628)

…According to this data, the USB PHY should be powered and working"

Zinoviy confirmed your claim by writing:" It seems like USB PHY is powered and working because I am able to bring the USB 0  in host mode".

Now, you are claiming that the right register description is the one that has only one usb_ctrl register located in 0x48140620, and that its description is as follows:

0x0: sleep mode

0x1: Normal operating mode

Which means that the usb phy is powered off.

Zinoviy tried to write 0x1 to the first bit in the register located in 0x48140620, in order to turn on the usb phy according to the "one usb_ctrl register".

I tried to write 0x1 to the first bit in the register located in 0x48140620, in order to turn off the usb phy according to the "usb_ctrl0/1 registers"

both of us always got 0x00000000 when reading its value after the writings(although its first bit is a r/w bit).

According to your reply to Zinoviy, the right usb register description includes two usb ctrl registers (usb_ctrl0 located in 0x48140620 and usb_ctrl1 located in 0x48140628) ,and 0x0 value in their first bit means that the USB PHY is powered on.

According to your reply to me, the right usb register description includes one usb ctrl register(located in 0x48140620), and 0x0 value in its first bit means that the USB PHY is powered off.

Could you please explain this contradiction.

Regards,

Asaf

Asaf,

Sorry for the confusion. I contacted our USB team with these questions. I will let you know their answer.

Regards,
Pavel

Asaf,

While waiting feedback from the USB team, I have checked the USB PHY init/deinit procedures in the linux kernel. The USB PHY is power on/off in the ti81xx_musb_phy_power() function from the linux-2.6.37-psp04.04.00.01/arch/arm/mach-omap2/usb-musb.c and the USB PHY related registers are described in the linux-2.6.37-psp04.04.00.01/arch/arm/plat-omap/include/plat/usb.h:

/* TI81XX specific definitions */
#define TI81XX_USBCTRL0                0x0620
#define TI81XX_USBSTAT0                0x0624
#define TI81XX_USBCTRL1                0x0628
#define TI81XX_USBSTAT1                0x062c

/* TI816X PHY controls bits */
#define    TI816X_USBPHY0_NORMAL_MODE        (1 << 0)
#define    TI816X_USBPHY1_NORMAL_MODE        (1 << 1)
#define    TI816X_USBPHY_REFCLK_OSC        (1 << 8)
#define TI816X_PHYCTRL0                0x0624
#define TI816X_PHYCTRL1                0x062c
#define TI816X_PHY_TXRISETUNE            1
#define TI816X_PHY_TXVREFTUNE            0xc
#define TI816X_PHY_TXPREEMTUNE            0x2

And USB PHY power off code is:

static void ti81xx_musb_phy_power(u8 id, u8 on)
{

u32 usbphycfg, ctrl_offs;

    ctrl_offs = id ? TI81XX_USBCTRL1 : TI81XX_USBCTRL0;
    usbphycfg = omap_ctrl_readl(ctrl_offs);

.............

else {
        if (cpu_is_ti816x())
            usbphycfg &= ~(TI816X_USBPHY0_NORMAL_MODE
                | TI816X_USBPHY1_NORMAL_MODE
                | TI816X_USBPHY_REFCLK_OSC);

omap_ctrl_writel(usbphycfg, ctrl_offs);

}

This code match with the description of the USB_CTRL register from section 24.9.8.2 USB_CTRL Register

USB_CTRL[0] PHYSLEEP0 - 0x0: sleep mode, 0x1: normal operating mode

USB_CTRL[1] PHYSLEEP1 - 0x0: sleep mode, 0x1: normal operating mode

USB_CTRL[8] PHYCLKSRC - 0x0: clock is gated, 0x1: clock is active

And this is in the 2.6.37 linux kernel. In the latest 3.16 linux kernel, we have

http://lxr.free-electrons.com/source/arch/arm/mach-omap2/omap_phy_internal.c#L154

http://lxr.free-electrons.com/source/arch/arm/mach-omap2/usb.h#L26

Based on all this, I think the DM816x datasheet is the correct source, we have single USB_CTRL register.

Regards,
Pavel         

Hi,

The 2.6.37 kernel code seems mixed up..

it seems like there are two usb ctrl registers(on 0x620 and 0x628), and ti81xx_musb_phy_power writes to one of them based on the id recieved as parameter.

But what it writes fits the description of the single usb_ctrl register(two first bits controls both usb phys, and 0 represents sleep, 1 represents normal mode), and not the description of the two usb_Ctrl registers.

on kernel 3.16 it seems OK, one register usb_ctrl0 placed in offset 0x620.

Can you please check why I can't change the value of the usb_Ctrl register?? even when writing 0x3(of course using the procedure 24.2.7 USB PHY Initialization) in order to put both phy in ON state according to the "single usb_ctrl" description, when reading its value back it is always zero.

Regards,

Asaf

Asaf,

I received confirmation from the DM816x Control Module team, that datasheet is correct, we have just one USB_CTRL register at offset 0x620, and reserved space in 0x628. The correct register description is from TRM, Table 24-211. USB_CTRL Register Field Descriptions.


Regards,
Pavel