No DFU detected, usb device not recognized code 43

[HaYa6174]

I am trying to create a custom keyboard, and I was trying to flash my board with stm32f070c6t6 MCU in DFU mode using cube programmer, but I keep getting "no DFU detected" (of course while pulling BOOT0 pin high).

Also, every time I plug my device into my PC, the error message says, "Windows has stopped this device because it has reported problems (Code43). A request for the USB device descriptor failed."

I am new to this field, so I am running out of ideas.

I put 16MHz crystal and set up 48MHz for USB, I configured the device description based on this website; https://controllerstech.com/how-to-use-stm32-as-a-keyboard/

I pulled up D+ with a 1k5 resistor, I pulled down both CC1 and CC2 with 5k1 resistors. 

  

I checked the voltage on the regulator and found it was totally fine (both 3v3 and 5v). I also checked the soldering and made sure that no pins were bridging.

I managed to flash the chip using STlink recently, but since this board is designed to be a keyboard, I expect the USB to work fine.

I am feeling so stuck, I have already spent like a total of 10 hours trying to figure it out, so it will be really helpful if someone tells me where I made a mistake.

Thanks.

[AScha.3]

First check, what track width and distance gives good result on 2 layer, then on 4 .

try also:

https://www.digikey.de/en/resources/conversion-calculators/conversion-calculator-pcb-trace-impedance

[HaYa6174]

Thank you. So I calculated using the website you suggested, and got 140.4440... This means that I need to probably redesign my board, right?

I figured out that by decreasing the height, we can decrease impedance dramatically, but I also found that 0.8mm is not enough to be in a range of 70-110 orm, because the trace width should be smaller than the USB typeC receptacle pins. Since, on JLCPCB, it apparently cost more if you choose less than 0.8mm... I think I will try designing 4 layer board this time.

[AScha.3]

First check with your actual board - it should work (although the impedance is not perfect matched).

Remove this U5 thing , bridge with thin wires , and check . With boot0 hi you have to see a connection...

if not, exchange wires at U5 with cross-connect wires...maybe D+/- puzzled.

[HaYa6174]

I removed U5, but it did not work, no dfu detected + USB error not recognized error.

I checked the connection between the receptacle pin and MCU pin directly using multimeter, and made sure that they are properly connected. So I think it is safe to say that there was no soldering mistake in type-c receptacle pins and MCU.

And I once again checked the datasheet, but it seems like I correctly assigned each pin.

Unfortunetly, when I tried to cross wire those pins, I accidentally ripped off the pad and traces from the board, so I could not see if it works when it is swapped... but honestly, as I mentioned above, pins were properly connected (at least in my eyes) so I don't think D+/- is puzzled...?

[AScha.3]

Hey - this was just an idea , to cross wire ... because sometimes we are 100% sure, we made no funny mistake - until we prove it.

(At work, a workmate made an usb-plug on a board; didnt work, i just said: cross wire it, cannot be less working. Surprise...it was working then.  > Murphy's Law is especially quoted in engineering and as most of you would well know says: “If anything can go wrong, it will”. )

>when I tried to cross wire those pins, I accidentally ripped off the pad and traces 

You still can use thin wires to connect, just for a test. I use wire-wrap or 0.2mm enameled wire for this.

Just try to keep it short, similar to the traces, put them to the board with a little bit glue.

Depends on your mechanical skills ...

Some can connect a BGA this way :

[HaYa6174]

Yeah, I see. I think that's really good advice, and I have made such mistakes before. So I agree that I should ensure everything is actually ok.

It might take some time because I have no experience doing it, but I will try.

[mansut]

I had a similar problem with our device, a STM32F7. DFU was correctly detected under Mac and Linux, but not under Windows.

The solution we found was to replace the libusb driver with libusbK, using Zadig to perform the trick. It worked.