Because of the Thanksgiving holiday in the U.S., TI E2E™ design support forum responses may be delayed from November 25 through December 2. Thank you for your patience.

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM335x USBSS.SYSCONFIG[0] soft_reset: reading during soft_reset crashes

Other Parts Discussed in Thread: SYSCONFIG

I want to set the USBSS.SYSCONFIG soft_reset bit and then poll that same register waiting for the reset to complete. However, this appears to be causing a crash.

It looks like the problem occurs when i try to read back the USBSS.SYSCONFIG register while the soft_reset is still active.

  • AM335x
  • USBSS.REVREG = 0x4ea2080d
  • USBSS.SYSCONFIG register is address 0x4740_0010
  • soft_reset is bit[0] of this USBSS.SYSCONFIG register

TRM (spruh73f.pdf section 16.5.1.2 ) states USBSS.SYSCONFIG[0] is Soft_reset

Software reset of USBSS, USB0, and USB1 modules
Write 0 = no action
Write 1 = Initiate software reset
Read 0 = Reset done, no action
Read 1 = Reset ongoing USBSS SIGCONFIG Register
 
I do something like
  • reg = HWREG(0x47400010);  //returns default/reset value of 0x28
  • reg |= 1;                                       //OR in the soft_reset bit
  • HWREG(0x47400010) = reg;
  • reg = HWREG(0x47400010); //this will cause a crash

however, if i add some delay between the write to USBSS.SYSCONFIG and the readback, it passes

  • reg = HWREG(0x47400010);  //returns default/reset value of 0x28
  • reg |= 1;                                       //OR in the soft_reset bit
  • HWREG(0x47400010) = reg;
  • delay();
  • reg = HWREG(0x47400010); //this will NOT crash, instead it returns 0x28 (reset not active)

I suspect the crash is caused by trying to read the USBSS while the soft_reset is still actively resetting the block.

However, the TRM implies i can poll this bit to determine when the reset is complete.

 

  • Rader, ensure that the USBx_OCP_EN_N bits in the same register are 0 (enable).  This should allow access to these registers even in the reset state.  Let me know if this works or not.

    Regards,

    James

  • I have tried various combinations of values for the USB_SS.SYSCONFIG register value and nothing seems to help

    here is psuedo code of what i am doing

    reg = init_value;
    HWREG(0x47400010) = reg; //get to know state
    reg = reg | 0x1; //OR in the reset bit
    HWREG(0x47400010) = reg; //activate reset
    reg2 = HWREG(0x474000010); //poll for reset done -- THIS will crash
     

    I have tried several different initial register values to see if any did not lead to a crash, they all led to a crash when i polled the SYS_CONFIG register

    • 0x0    - defalut/reset state (USB0/PHy1/USB1/PHY1 clocks enabled, forec-standby mode, force-idle mode)
    • 0x14  -                                   (USB0/PHy1/USB1/PHY1 clocks enabled, no-standby mode, no-idle mode)
    • 0x16
    • 0x02
    • 0x28  - our usecase (i think this is what starteware sets)

    the only way i can prevent a crash is to delay that polling read until after reset is done (thus defeating the purpose of polling)

    while this defeats the polling purpose, it does suggest that the issue is related to reading the SYSCONFIG register during an active reset.

     

  • I did find a note in the spec that you should delay 200ns after a soft reset before trying to access the subsystem.  If that is the case, i think the TRM description is misleading and will change in the next revision. 

    Regards,

    James

  • does the note indicate that reset itself might take longer than 200ns, or will it be done after 200ns

    I guess I am trying to see if i can remove the polling all together and simply wait 200ns

    or do i still need to poll because some other part of the module takes longer to reset ?

     

  • I think you need the delay and poll.  The delay is just to get around the reset pulse that needs to be applied.  The poll will ensure the controller and subsystem is ready for interaction.

    Regards,

    James