otg_core_reset: wrong operation sequence? Topic is solved

Report here problems in any of ChibiOS components. This forum is NOT for support.
tsichevski
Posts: 35
Joined: Fri Feb 09, 2018 12:44 am
Has thanked: 2 times
Been thanked: 5 times

otg_core_reset: wrong operation sequence?  Topic is solved

Postby tsichevski » Tue Dec 04, 2018 5:56 pm

Hi,
My MCU is stmf405.

From time to time, my program gets stuck inside the otg_core_reset() in the following endless loop:

Code: Select all

  /* Core reset and delay of at least 3 PHY cycles.*/
  otgp->GRSTCTL = GRSTCTL_CSRST;
  while ((otgp->GRSTCTL & GRSTCTL_CSRST) != 0)
    ;

According to the MCU RM:

Code: Select all

The application can flush the entire RxFIFO using this bit, but must first ensure that the core
is not in the middle of a transaction.
The application must only write to this bit after checking that the core is neither reading from
the RxFIFO nor writing to the RxFIFO.


The way to check this condition is to test the AHBIDL bit. The otg_core_reset() does this, but by some unknown reasons AFTER writing the GRSTCTL_CSRST bit, not before :(

Regards,
Vladimir
PS: the "official" ST HAL library tests the AHBIDL before writing the GRSTCTL_CSRST.

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: otg_core_reset: wrong operation sequence?

Postby Giovanni » Tue Dec 04, 2018 6:37 pm

Moved in "bug reports".

Giovanni

User avatar
sabdulqadir
Posts: 49
Joined: Fri Mar 23, 2018 7:29 pm
Has thanked: 13 times
Been thanked: 4 times

Re: otg_core_reset: wrong operation sequence?

Postby sabdulqadir » Mon Dec 10, 2018 9:21 pm

I noted the same in STM32cubemx code. They test AHBIDL bit before the reset.

Thanks,
AQ

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: otg_core_reset: wrong operation sequence?

Postby Giovanni » Sun Dec 16, 2018 8:47 am

Hi,

The AHBIDL bit is checked after setting the CSRST bit because the following description of CSRST bit:

The application can write to this bit any time it wants to reset the core. This is a self-clearing
bit and the core clears this bit after all the necessary logic is reset in the core, which can take
several clocks, depending on the current state of the core. Once this bit has been cleared,
the software must wait at least 3 PHY clocks before accessing the PHY domain
(synchronization delay). The software must also check that bit 31 in this register is set to 1
(AHB Master is Idle) before starting any operation
.


This explains why we have that delay and check on AHBIDL after reset.

I modified the function as follow, does it make any difference for you?

Code: Select all

static void otg_core_reset(USBDriver *usbp) {
  stm32_otg_t *otgp = usbp->otg;

  /* Wait AHB idle condition.*/
  while ((otgp->GRSTCTL & GRSTCTL_AHBIDL) == 0)
    ;

  /* Core reset and delay of at least 3 PHY cycles.*/
  otgp->GRSTCTL = GRSTCTL_CSRST;
  while ((otgp->GRSTCTL & GRSTCTL_CSRST) != 0)
    ;

  osalSysPolledDelayX(18);

  /* Wait AHB idle condition again.*/
  while ((otgp->GRSTCTL & GRSTCTL_AHBIDL) == 0)
    ;
}


Giovanni

tsichevski
Posts: 35
Joined: Fri Feb 09, 2018 12:44 am
Has thanked: 2 times
Been thanked: 5 times

Re: otg_core_reset: wrong operation sequence?

Postby tsichevski » Fri Dec 21, 2018 2:18 pm

My program got stuck in the same loop again. I fixed it (I hope) by inserting a delay between setting the reset bit and reading it back:

Code: Select all

  /* Core reset and delay of at least 3 PHY cycles.*/
  otgp->GRSTCTL = GRSTCTL_CSRST;
  osalSysPolledDelayX(3);
  while ((otgp->GRSTCTL & GRSTCTL_CSRST) != 0)
    ;

User avatar
Giovanni
Site Admin
Posts: 14444
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 1074 times
Been thanked: 921 times
Contact:

Re: otg_core_reset: wrong operation sequence?

Postby Giovanni » Mon Dec 31, 2018 9:49 am

I added a (greater) delay, I have not experienced the problem but better be safe than sorry.

Giovanni


Return to “Bug Reports”

Who is online

Users browsing this forum: No registered users and 15 guests