STM32F205RBT - USB error

[RipTek]

So I bought this chip, STM32F205RBT.  I have followed the schematic (https://www.waveshare.com/w/upload/0/05/CorexxxR-Schematic.pdf).  I've read pretty much every manual that ST provides for this chip and for some reason I still can not get it to work.  This is a build I've started from scratch.  Attached is the schematic that I've made.  This is being connected to my pc via USB.  The only thing on the original CorexxxR schematic that I haven't put onto my breadboard is the 32.768K Crystal (not required, I believe, to boot and the switches.)

Every time I connect the breadboard it says "USB device not recognized" (the last usb device you connected to this computer malfunctioned. Windows does not recognize it.)

I believe my problem is with the DFU bootloader.  For some reason I'm not able to invoke the Bootloader on the chip so PC recognizes the chip. 

Any tips or suggestions would very much be appreciated.

-Kevin

[funkathustra]

I believe my problem is with the DFU bootloader.  For some reason I'm not able to invoke the Bootloader on the chip so PC recognizes the chip. 

To enter DFU mode, Boot0 must be "1", and Boot1 must be "0" --- the datasheet lists Boot1 is on PB2, but your PB2 is disconnected (probably pulled high internally). Pull PB2 down to ground, plug in your device, and repeat your test.

Also, you could try uploading some USB code onto the device just to verify your setup.

....well, at least, you could if you had remembered to put an SWD connection on your board. Why would you ever make a PCB without a debug header on it?

[RipTek]

I apologize.  I thought I had my schematic fully updated.  Attached is the updated schematic. Also I am fairly new to this, as I am about to finish college with my A.S. EET degree. 

• Added PB2 with 10K resistor to GND.
• Added MIC2025 chip.
• Removed Transistor at USB and added 1.5K pull-up resistor.
• Added 100nF resistor & GND to NRST.

[andyturk]

• Always break out the SWD/JTAG pins. Always!
• Make sure BOOT0 and BOOT1 are set the way you want (seems like you've got this already)
• Is the 3.3V rail at the right voltage when it's running?
• Is the oscillator oscillating? It won't be right away, and putting a scope probe on there will probably mess it up, but you should be able to see a signal there eventually.
• The STM32 bootloader tries a variety of serial interfaces in order. You want it to use USB, but if hears something on one of the other serial interfaces, it'll stop there. So make sure (with pull up/down resistors) that the other interfaces are quiet. See AN2606
• I think the core will drag NRST low if it resets internally. So, if you see any activity on NRST after the initial rising edge, the ROM bootloader is probably resetting itself.

[funkathustra]

I apologize.  I thought I had my schematic fully updated.  Attached is the updated schematic. Also I am fairly new to this, as I am about to finish college with my A.S. EET degree. 

• Added PB2 with 10K resistor to GND.
• Added MIC2025 chip.
• Removed Transistor at USB and added 1.5K pull-up resistor.
• Added 100nF resistor & GND to NRST.

That's all fine (well, minus the 1.5K pull-up --- I don't think you need that), but you need the SWD interface broken out so you can upload code to your microcontroller and test it. Seriously. Lots of things need to go right for DFU USB to work --- so start by programming it directly over SWD.

A big red flag that I see is that you seem to be missing almost all your power pins. Pins 18, 19, 32, 48, 63, and 64 are all VDD/VSS pins, and they're completely absent from your schematic. How do you expect your microcontroller to do anything without powering it? 

Also, please learn how to use net labels in whichever EDA software you use. Your schematics are very difficult to read, especially this gibberish power routing.

As for the proper power connections, read the datasheet of your microcontroller --- there is an entire section on minimum power supply scheme, in chapter 4:

[RipTek]

My 3.3V rail is showing 3.298V so thats fine.
BOOT0 and BOOT1 are set correctly.
The oscillator is showing on the scope probe.

All of my VDD/VSS pins are connected correctly.  For some reason the EDA software (EasyEDA) I'm using doesn't show those pins.  The only other software I've used is MultiSim and the database doesn't have the STM32F205 family in it.  On the bottom right of my schematic is shows what goes to those pins even though they don't show on the STM32F2 chip.  I've read the datasheet (as mentioned before) and everything in the Power Supply Overview such as VBAT, VDD, VSS (no VREF on this chip), and VCAP's are connected as followed from AN3320 ( http://www.st.com/resource/en/application_note/cd00292095.pdf )

A co-worker spoke to ST and they mentioned that there has to be two resistors of 0 Ohm value (as close as possible to the chip) that is connected to the crystal oscillator.  If these aren't there then it will not work.  So we might have to develop dev boards and work from there.

[wraper]

Why on the first schematic you are pulling up D+ but on second D-, on top of that to 5V? NUCLEO-F207ZG apparently uses no external resistor, so there should be built it pull up to D+. Didn't check the datasheet for  STM32F205, though.

[wraper]

A co-worker spoke to ST and they mentioned that there has to be two resistors of 0 Ohm value (as close as possible to the chip) that is connected to the crystal oscillator.  If these aren't there then it will not work.  So we might have to develop dev boards and work from there.

LOL what? How they are supposed to make any difference?

[RipTek]

At first I thought I had to pull up D+, but then my senior engineer said it should be on D-. 

I also have no idea of how a 0 ohm resistor makes any difference.  We bought the CorexxxR board from Waveshare and they do put those resistors on there.  What we want to do is make a more simplified version of it.  So we can connect it to our phones for programming. 

[wraper]

but then my senior engineer said it should be on D-.

D+ is for full speed mode, D- for low speed, and it must be pulled up to 3.3V. Microcontroller must be configured accordingly. Your microcontroller apparently has internal pull-up and there should't be additional one connected.

[funkathustra]

My 3.3V rail is showing 3.298V so thats fine.
BOOT0 and BOOT1 are set correctly.
The oscillator is showing on the scope probe.
All of my VDD/VSS pins are connected correctly.

OK, so the next step is to obviously load some test USB code using SWD and see what's not working? Once you get into a debugging session, you'll see where things are getting tripped up. My assumption is the oscillator, which you haven't seemed to verify yet.

[dgtl]

The F205 (and others with OTG controller, ie 405) have internal pullups, no external ones needed.
The series termination resistors on data lines should afaik be 0-ohm. On some microcontrollers, the impedance of the internal drivers are too low and external resistors are needed. Even if it is not the case, the 0-ohm resistors are still drawn in to be able to replace them with another value in case certification fails (they cost almost nothing, but the re-design would cost a lot).
There is an application note about the internal bootloader, AN2606. The appnote says that the F2xx has two bootloader versions, the earlier one does not support DFU. Check that the chips you got are not from some old leftover stock somewhere and do not have revision B marked on them.
That appnote specifies the exact requirements for the DFU bootloader. First, check the activation sequence to be sure that no other bootloader would activate first (as only one can be active). Then make sure that the DFU bootloader does activate. The USB bootloader does not need much from the controller. Use a scope to verify that the oscillator is running (AN states it must be multiple of 1 MHz between 4-26). Measure voltages and reset line.

Although it would be possible to develop without a debugger, you should get one and use that for your daily development. The ST-Link is cheap and works well, software is free. Do your daily work with the debugger and use the DFU only for factory programming or limited field update functionality if it fits for you.
Also, beware that the DFU ST has implemented, is actually not DFU-compatible. They implemented a custom DFUSE protocol on top of DFU and standard DFU tools do not work.