USB dead without obvious reason

[Stanislav Husár]

Hello,

I have problems with custom designed board. After soldering everything(w/o IC1,IC3) I flashed my firmware. USB device completely unrecognized.

I have soldered 1k5 resistor on 3V3 and D+. After connecting to computer I was able to see serial output on terminal program.

Then I have shorted pins 1-6 on IC1 to connect positive analog reference. After connecting, USB peripheral apparently died.

No matter what I flash, I get device descriptor request failed. I have also tried USB VCP project template, same result.

Any idea what did I do wrong? Is there any chance to get it working, besides soldering a new mcu?

Thanks in advance,

Stanislav

[Stanislav Husár]

I have checked ESD protection IC with diode test. Voltage drop on all clamping diodes in both directions.

Am I measuring MCU's internals, or does this mean that the IC is dead?

Yesterday I have tried to probe data lines on oscilloscope during device descriptor request phase. No changes on data line....however that may be due to incorrect use of scope(theoretically).

[Uwe Bonnes]

You mean "no obviuos reason". Electronic only dies in vary rare case for no reason.

[Stanislav Husár]

OK, usb dead without obvious reason.

I mean when the fault appeared, I did not change anything near USB connector or MCU.

I have replaced ESD protection, did no resolve.

So the USB peripheral is definitely damaged? Or what can I try?

[TDK]

If you want to see if the chip is dead or not, try to blink an LED.

1.5k pullup is not required. There is an internal pullup. Look at demo board schematics.

[Stanislav Husár]

Hello,

MCU itself is working, I can debug it via SWD.

Problem is related to usb peripheral.

Pullup, from what I have found, my exact part STM32F103TBU6 does not have it. I can also confirm that without external pullup OS didn’t even know there is a new device on bus.

Unfortunately, MCU is soldered on board dedicated for a specific purpose, there is no chance to connect anything that is not related to design/purpose.

[Stanislav Husár]

Another weirdness.

I wrote a simple program that toggles PA11/PA12 - the pins used for D+/D- signals. I can measure resulting signal on oscilloscope.

So, MCU itself is working, SWD is working, GPIO is working....and USB looks like dead. How?

If USB was damaged from external event, I'd expect GPIO to be dead too.

If USB was damaged from internal fault, I'd expect internal buses to be dead too.

If I had a software fault, I'd expect VCP sample project to work.

None of above is true.

[waclawek.jan]

Surely, the USB has other hardware dependencies than just the DP/DM pins, for example crystal/oscillator, and to a certain extent, power supply too.

I can also imagine the "VCP sample project" - of which I know nothing - may have some idiosyncracies, e.g. hanging upon seeing a certain level on a certain pin.

JW

[Stanislav Husár]

Thanks for reply.

I am using HSE with PLL as usb clk. Program is able to run, so I certainly have some clock. I will check out tomorrow what it is.

VCP sample project - I am refering to one of templates in VisualGDB. Basically, It’s virtual com port, that sends back anything it receives.

[Stanislav Husár]

That's interesting. I've checked my clock tree with a simple program. I can switch sysclk to HSE, I can turn on PLL. But my program hangs on clock switch to pll.

#include <stm32f1xx.h>
 
int main()
{
	RCC->CR |= RCC_CR_HSEON;
	while (!(RCC->CR & RCC_CR_HSERDY));
	
	RCC->CFGR |= RCC_CFGR_SW_HSE;
	while (!((RCC->CFGR & RCC_CFGR_SWS_Msk) == RCC_CFGR_SWS_HSE)) ;
	
	RCC->CFGR |= RCC_CFGR_PLLSRC_Msk;
	RCC->CFGR |= RCC_CFGR_PLLMULL9;
	
	RCC->CR |= RCC_CR_PLLON;
	while(!(RCC->CR & RCC_CR_PLLRDY));
	
	RCC->CFGR |= RCC_CFGR_PPRE1_DIV2;
	
	RCC->CFGR |= RCC_CFGR_MCO_HSE;
	
	RCC->CFGR |= RCC_CFGR_SW_PLL;
	while (!((RCC->CFGR & RCC_CFGR_SWS_Msk) == RCC_CFGR_SWS_PLL)) ;
	
	
	
	while (1) ;
}

So, if PLL is not operational, USB may not have 48MHz. However, PLLRDY is 1. How does this detection work?

[Stanislav Husár]

Okay, I got tricked by RMW again. SW_HSE | SW_PLL is not a valid clock.

But if I comment lines 8-9, nothing changes. Funny thing is, debugger says that RCC->CFGR is 0x001D000A. That is SW_PLL and SWS_PLL.