USB going into suspended state after 5 seconds and wont exit

[MCG]

I am doing a USB HID project and have followed a lot of the setting up of this YouTube video. 

I have set it up to send a string when I press a button. Using Device Monitoring Studio, I can see that when the device is plugged in, it reads the descriptor, checks the PID and VID and responds to the button press and receives the string.

If I leave it for roughly 5 seconds (DMS measured 5.0087 & 5.0013 seconds) then it goes into a suspended state. Once this has happened, any button presses are ignored, and I am unable to get the USB to respond to anything, unless I unplug it and plug it in again. If I do this, it works fine until it is left for another 5 seconds. I have even removed the code inside the HAL_PCD_SuspendCallback in usbd_conf.c to try and stop it getting suspended but it still goes unresponsive. 

I'm at a bit of a loss as to what to do now!

[FBL]

Hello @MCG 

Did you check resume callback? It seems like you are missing to clear some flag.

void HAL_PCD_ResumeCallback(PCD_HandleTypeDef *hpcd)
{
  /* USER CODE BEGIN 3 */

  /* USER CODE END 3 */
  USBD_LL_Resume((USBD_HandleTypeDef*)hpcd->pData);
}

[MCG]

Yes I did. It never reaches the resume callback function

[FBL]

Which product are you using? @MCG 

Could you screenshot OTG_GINTSTS, OTG_DSTS and OTG_DCTL before and after it gets suspended?

[MCG]

I am using the STM32L073RZT6.

When searching the terms OTG_GINTSTS, OTG_DSTS and OTG_DCTL, the search returns 0 matches

[FBL]

Hello @MCG 

Using STM32L073, USB_CNTR_FSUSP and USB_CNTR_LPMODE bits in the CNTR register are used to force the USB peripheral into suspend mode. Then, you can check status register in ISTR.

Check RM0367 for more details! You can enable USE_HAL_PCD_REGISTER_CALLBACKS, it would be helpful to debug the issue as well. Would you share your code ?

[MCG]

Hi @FBL yes, both of those bits are set to 1, but the SUSP bit in the ISTR register is 0.

The code I used for this is a copy of the setup in this YouTube video:

https://www.youtube.com/watch?v=3JGRt3BFYrM&list=PLnMKNibPkDnFFRBVD206EfnnHhQZI4Hxa&index=16

and the only other code I had was on a button press, send a string that said "ConnectTest" which just looked like this:

if (USB_Ready) 
{
    Display_USB();  // Presumably, function to handle USB display/update
    if(StartButton == 1) 
    	{
			StartButton = 0;
			memcpy(&TestData[1], TestString, strlen(TestString)); // Copy string into the report
			// Send the report via USB, length is Report ID + string length
			if (USBD_CUSTOM_HID_SendReport(&hUsbDeviceFS, TestData, 1 + strlen(TestString)) != USBD_OK) 
				{
					__NOP();
				}
    	}
}

So there wasn't anything too special about it

[FBL]

Hi again @MCG 

The code you mentioned is specific to F446 which does not implement the same IP USB. Here is the procedure to follow to enter suspend mode using L0x3.

Note that when in low power mode, debug cannot be used (IAR and Keil doesn't support it)

[MCG]

Hi @FBL, the issue isn't trying to go into suspend mode. It was that I couldn't get it out of suspend mode unless it is interrogated by the host. My button would not send the string when pressing it once it had been suspended. 

Is this a problem, or is this just how USB works as this is my first time doing a USB project. It now works fine since changing the code to sending a string when being asked by the host.

[FBL · Accepted solution]

Hi @MCG 

The host can signal a resume by applying a resume signaling on the data lines. But also, the resume sequence can be started by setting the RESUME bit in the USB_CNTR register to 1 and resetting it to 0 after an interval between 1ms and 15ms (this interval can be timed using ESOF interrupts, occurring with a 1ms period when the system
clock is running at nominal frequency).

Typically, when the device triggers a remote wakeup (e.g., by a button press) to complete the resume signaling. This WKUP event resets as well LP_MODE bit.

So, this behavior is not necessarily a problem. By definition, this is how it works.

One more thing to consider in your software, when using wakeup interrupt routine, to have the shorter latency before re-activating the nominal clock it is suggested to put the resume procedure just after the end of the suspend, so its code is immediately executed as soon as the system clock restarts.