STM32F205RBT - USB error - Page 1
Forum section: electronics / projects

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 03:01:25 pm
content: 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

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2017, 03:18:29 pm
content: On most STM32 chips, you run the ST-provided bootloader from the so called "system memory" by grounding the BOOT0 pin, then applying power, but I see no switch / jumper / whatever on your schematic to do that.EDIT: Sorry, got it the wrong way. Your pull-up should do the trick.Never used the USB bootloader myself, though.

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 04:13:04 pm
content: Ok, so I added the MIC2025 chip (see attached schematic) and the 1.5K pull-up resistor. I'm still getting the same error.

author: tszaboo
author_rank: Super Contributor
timestamp: October 06, 2017, 04:18:49 pm
content: I believe X2 is either 16Mhz or 12Mhz for USB for these chips.

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 04:25:55 pm
content: I just tried the 16Mhz & 12Mhz for X2. Still the same ol' error.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2017, 05:44:41 pm
content: If I remember correctly (hopefully this time), Vdda must be powered, even if the ADC is not used.Have you tested the UART bootloader? Does it respond? This would help narrow down if the CPU is running the bootloaderat all, or is the problem USB related only.

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 06:39:55 pm
content: VDDA is getting 3.3V. I haven't tried a UART bootloader and I don't have a RS232 transceiver or a serial port on this pc. I have a ton of other pc's here I can try if I absolutely need to get hardware for it

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 06:50:34 pm
content: Revised Schematic attached

author: RipTek
author_rank: Contributor
timestamp: October 06, 2017, 06:56:07 pm
content: Info I found on the USART/UART and DFU mode to get bootloader. DFU is the only process in which I have attempted and have been unsuccessful.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 06, 2017, 08:32:23 pm
content: Get yourself a $1 "TTL" 5V/3.3V USB serial dongle such ashttp://www.ebay.com/itm/USB-To-RS232-TTL-USB-To-COM-Serial-Adapter-Cable-Module-PL2303HX-M56-/291549727170. The dongle is easy to test with a loopback. I have never had problems with these $1 "TTL" dongles; the RS232 signal level versions for $2 typically do not work as well.The USART bootloader has fewer things to go wrong, and it's very easy to debug with a 'scope. And as you found out, it should work directly from three different set of USART pins. If one fails to work, just try the next one.You should be able to send the required bytes to get an acknowledgement that the CPU is running the bootloader.

author: capt bullshot
author_rank: Super Contributor
timestamp: October 09, 2017, 08:45:03 am
content: Why would you want to use the bootloader for developing such a device?Get a STM32Fxxx Nucleo64 board (any CPU flavour will do), they are quite cheap (~10 EUR), remove the ST-Link part from the rest and use this ST-Link as the debugger for your circuit. You just have to connect 4 wires to your target (GND, VCC, SWDIO and SWCLK), can be used with all of the usual suspects of IDE / compiler / debuggers. It also provides a simple stand-alone flasher tool.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 09, 2017, 10:53:34 am
content: Quote from: capt bullshot on October 09, 2017, 08:45:03 amBecause, um, why not?It's very simple, robust, easy, requires no specialized software and/or hardware.The "only 4 wires" reduce to 3, and uses the UART serial signaling everybody's familiar with. I don't know what is an "usual suspect IDE/compiler/debugger", but none that I'm familiar with in no way directly support ST-LINK.Every operating system supports UART, and the programming interface is super simple.I bought an ST-LINK a long time ago but have never used it. Tried to make OpenOCD work for an hour, gave up. I like simple solutions to difficult problems - always used the bootloader after that. I find the internal bootloader a great selling point in the STM32 microcontrollers - you can use a standard UART as the programming hardware! Or many of the other interfaces, as well.In real-world complex projects, you almost always develop your own "bootloader"/programming interface/debug structures anyway - in this case, having the simple bootloader that you can use to do the intial development with, and later, production programming, is a great thing.Never used a debugger nor IDE in arealcomplex MCU project. They were "fun" when making leds blink in school. (I know most people think differently, but there's no one general truth here)

author: capt bullshot
author_rank: Super Contributor
timestamp: October 09, 2017, 11:10:46 am
content: I've done a lot of embedded FW development over the years, and to some extent, I agree with your point "fun to blink a LED using an IDE / debugger".In fact, I don't use IDEs, but especially with the STM32 family I've switched to using the ST-LINK instead of the bootloader, just because it is simpler. Yes, this thing wasn't supported well in the past, but today it's working out of the box with many popular IDEs (like IAR / Keil) and of course OpenOCD (which is my choice, together with gnu make).No need to program your own bootloader host and it works fine on Linux (also on Windows, but I don't care). No need to manually invoke the bootloader or to take provisions to invoke the bootloader from your user program on demand.

author: andyturk
author_rank: Frequent Contributor
timestamp: October 10, 2017, 03:24:39 am
content: Quote from: Siwastaja on October 09, 2017, 10:53:34 amBecause code often doesn't work correctly the first time, and if the code you've screwed up is clock config or pin config, you'll probably brick the board.Sure, you can code with one hand tied behind your back, but for a $25 ST-Link and a tiny TC-2030 footprint on the board, you can use a full debugger. You don't have to go the full IDE route. Just single stepping machine code and looking at registers is pretty helpful when you're chasing a hard fault.+1 on gmake (and emacs!)I switched from openocd a few years ago to luxury of a J-Trace Pro. I like the Segger stuff because it's scriptable and I can embed those scripts in Makefiles. The trace version is big $$$, but their EDU debugger is only slightly more than the ST-Link with a lot more functionality.

author: Siwastaja
author_rank: Super Contributor
timestamp: October 11, 2017, 05:42:07 pm
content: Quote from: andyturk on October 10, 2017, 03:24:39 amYou have no idea what you are talking about.These STM32 microcontrollers do not have any "fuses" you are clearly thinking about.The STM32 bootloader cannot be overwritten AFAIK.There is no way to "brick the board" by using the STM32 bootloader instead of the SWD interface.Debugger is a valid point. Some people prefer using one. I have never needed one, and have done very complex projects in short time, including chasing hardfaults. I can count situations where singlestepping instructions would have been really helpful using one hand.Does having a debugger prevent you from accidentally configuring a pin as an output to cause a short circuit? IMO, writing careless code because "you can always singlestep it in debugger to see what happens" only increases these kind of incidents. Probably not much, though.(I use gcc-arm-none-eabi + make.)