[STM32H753] USB33RDY is not asserting

[vosahlov]

Dear all,

I'm coming to you with a very simple problem, after not being able to wrap my head around it. I'am trying to design a board using the STM32H753VIT6 (V revision) and a USB3320 ULPI interface. While writing firmware for the custom board, I noticed that sometimes, the USB33RDY flag does not get asserted. Thus I suspect the USB regulator does not run correctly. The thing is, it is very moody... It works one day, than stops the other. 

There is not much mentioned about this in the datasheet so after peeking into it today, I figured it probably has to be an power issue with my board and I went to try it on the NUCLEO-H753ZI. I uploaded a very simple test code that just enables the USB reguator and the voltage level detector, the code is as follows:

#include "main.hpp"
#include "stm32h753xx.h"
#include "core_cm7.h"
#include "cmsis_compiler.h"


extern "C" void SystemInit(void){
	
}

extern "C" int main(void){	
	//Enable the USB regulator and wait for it to be ready
	PWR->CR3 |= (PWR_CR3_USBREGEN | PWR_CR3_USB33DEN);
	while(!(PWR->CR3 & PWR_CR3_USB33RDY_Msk)){;}

	while(1){
		asm("nop");
	}
	
}

 And still, I cannot get it working. The code hangs at line 14 (in the while loop) and the ready flag is not set in the register view. I've attached the complete project with startup, linker, etc. bellow (without the CMSIS).

My question is: Am I doing something wrong with the powerup sequence? Do I need to enable something else first, before enabling the USB regulator? The weirdest thing to me is that this exact code sometimes works and sometimes does not... I'm powering the nucleo through the USB cable from a PC, so I guess it could still be some kind of noisy USB power issue...

Thanks for any kicks in the right direction! 

Debugger: BlackMagic Probe

Compiler: GCC 10.3.1.

IDE: VSCode

OS: Windows

[Saket_Om]

Hello @vosahlov  

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: 190830 (This is an internal tracking number and is not accessible or usable by customers).

[vosahlov]

Hey @Saket_Om,

have you got any news on the ticket? We're on quiet a tight schedule and this thing keeps us from progressing with the USB.

Thanks a lot!

[Saket_Om]

Hello @vosahlov 

We are actively working on the ticket and will provide you with an update as soon as possible. 

[Saket_Om · Accepted solution]

Hello @vosahlov 

On the NUCLEO-H753ZI board, which features a microcontroller in an LQFP144 package, it is expected for the USB33RDY flag to remain unset. it is mentioned in the MCU datasheet that when the VDD50USB is not available on the package, the pin will be tied internally to the VDD33USB. See the screenshot below from the datasheet DS12117 Rev 9

In this case, it is necessary to use an external USB supply as mentioned in the reference manual RM0433. Please see the screenshot below:

For the NUCLEO-H753ZI board, the VDD33USB pin is connected to 3.3V via solder bridge SB13. Please see the schematic below.

If your setup does not use the TFBGA240 +25 or UFBGA169 package, in your application, you should disable the USBREGEN bit then enable the USB33DEN bit. There is no need to check the USB33RDY bit, as it is not expected to be set.

[vosahlov]

Dear @Saket_Om ,

thank you very much for the response. Just to clarify...

---

If your setup does not use the TFBGA240 +25 or UFBGA169 package, in your application, you should disable the USBREGEN bit then enable the USB33DEN bit. There is no need to check the USB33RDY bit, as it is not expected to be set.

---

This last paragraph is also valid for the LQFP100 version (this is my specific case with the product)? Where are the USB pins than powered from? VDD directly? I do miss some note in the datasheet about this. Something like "In the LQFP100 package, the pins VDD50_USB and VDD33_USB are internally tied to VDD". 

Thanks!

[Saket_Om]

Hello @vosahlov 

The VDD33USB pin is not available for the LQFP100 package. For this package, the internal USB PHY is supplied through the VDD.

[vosahlov]

Perfect, thanks for clarification!