USB bootloaser does not work

[DmtryVovk]

Posted on July 17, 2016 at 12:48

So, hello everyone. I have a problem with starting bootloader using USB cable.

I think i did all conditions to provide this mode. NUCLEO F070RB. Win10, Win7HSE(crystall) 12 MHz works fine in Led-blink project. BOOT0=1, nBOOT1=1(Checked).Windows have no any reaction after connecting USB (D+, D-, GND)!If i add pull-up resistor on D+ or D-, windows can see ''Unknown device'' with wrong descriptor. Please halp me! #dfu #usb #bootloader

[DmtryVovk]

Posted on July 18, 2016 at 22:47

1.
/* Wait till HSE is ready and if timeout is reached exit */
<br> 
do
<br> {<br> HSEStatus = RCC_GetFlagStatus(RCC_FLAG_HSERDY);<br> StartUpCounter++; <br> } <br>
while
((StartUpCounter != HSE_STARTUP_TIMEOUT) && (HSEStatus == RESET));

(Sorry for wrong code formatting ) In this standard func StartUpCounter counts untill HSE starting. Debugger shows that it counts up to 7, no more, looks like very fast. Of course i am sure in my cable integrity. I did small USB application (USB-Virtual COM) it works fine. Oscilloscope shows no action on pins D+ D- while connecting to PC. I've tried different HSE, 12MHz, 12MHz, 8MHz, all works normaly in my program.

[Walid FTITI_O]

Posted on July 19, 2016 at 11:27

Hi vovk.dmitriy,

If you are using windows 10, Try to change the descriptors in the usbd_desc.c file as follow:

/* USB Standard Device Descriptor */

const uint8_t hUSBDDeviceDesc[USB_LEN_DEV_DESC]= {

  0x12,                       /* bLength */

  USB_DESC_TYPE_DEVICE,       /* bDescriptorType */

  0x00,                       /* bcdUSB */

0x02,

  0x02,                       /* bDeviceClass */

  0x02,                       /* bDeviceSubClass */

0x00,                       /* bDeviceProtocol */

[DmtryVovk]

Posted on July 19, 2016 at 16:48

Hannibal, hi, thanks for post, but i no have this file or any program for DFU Bootloader. Read my posts carefully.

[Walid FTITI_O]

Posted on July 19, 2016 at 17:28

Hi vovk.dmitriy,

As a start, I recommend to check the

http://www.st.com/content/ccc/resource/technical/document/user_manual/3f/61/72/ff/c5/5a/4a/7b/CD00155676.pdf/files/CD00155676.pdf/jcr:content/translations/en.CD00155676.pdf

'' Getting started with DfuSe USB device firmware upgrade STMicroelectronics extension'' and download

http://www.st.com/content/st_com/en/products/development-tools/software-development-tools/stm32-software-development-tools/stm32-programmers/stsw-stm32080.html

-Hannibal-

[Tesla DeLorean]

Posted on July 19, 2016 at 18:47

The OP has an issue with the ROM based System Loader not presenting as a DFU device when booted in that mode.

Either the ROM does not support such connectivity, or there is some other issue.

[DmtryVovk]

Posted on July 20, 2016 at 12:16

Hannibal, to work with the DfuSe USB firmware upgrade i need to connect my MCU to PC, install the driver, right?

There is my problem... windows does not see MCU. 

[DmtryVovk]

Posted on July 20, 2016 at 12:18

, sorry... i do not understend your message =(

What is ''OP''?

[Tesla DeLorean]

Posted on July 20, 2016 at 15:48

Forum speak for

https://www.google.com/#q=Original+Poster

[Mon2]

Posted on December 13, 2016 at 19:41

This post is to confirm that we too are observing the same issue with a fresh sourced STM32F070RBT6 based Nucleo board (received today from Digikey). Also purchased the Adafruit USB mini USB connector breakout board -> mated the D+ to PA12; D- to PA11 and common ground. BOOT0 to Vdd on the male jumper pins (short pins 3 & 4 down on the left side of the male header pins). First connected the ST-LINK USB connector to power the board -> then connected the external Adafruit breakout board. Nothing other than COM17 (for our ST-LINK) enumerated in the Device Manager.

No boot of the ROM USB DFU using this configuration.

Find it strange that the pushbutton RESET does not force the COM17 to disappear and then be re-enumerated upon release.Next, removed the jumper on BOOT0 and uploaded a CubeMX created DFU project (takes a few seconds to generate with Keil 5) -> uploaded to the same Nucleo board. Power cycled and our external USB connector and this project allow for our uploaded DFU loader to be enumerated just fine.This procedure confirms that our external USB cable is operational.In test # 1 the 8 Mhz is being sourced from the STM32F103 ST-LINK CPU.

In test # 2 - removed the MCO 0 ohm shorting resistor, applied the 2 zero ohm resistors @ R35, R37; applied 27 pf caps onto C33, C34 and a 8 mhz crystal @ X3.

ROM DFU bootloader fails to boot with either clock source. Both clock sources work fine if we upload the user version of the DFU boot loader.

No external 1k5 resistors were applied onto the D+ line for any of these tests. Assorted USB 2.0 & USB 3.0 ports on the Windows 7 64 bit box were tested with the same results.

There is something very quirky about the STM32F070xx CPU devices. This is now confirmed with our assorted testing of the STM32F072RBT6 package - different age of Nucleo boards with this CPU have been tested by 2 different engineers. However, there is a public posting on the use of the TSSOP 20 pin package of the STM32F070F6P6. Perhaps that package works where the STM32F070RBT6 fails ? Will know more on that testing tomorrow when we receive our STM32F070F6P6 devices from Mouser.

Will place this STM32F070RBT6 Nucleo on the USB analyzer to see if anything is being sent by this firmware.STM32F072RBT6 Nucleo boots fine from the ROM DFU if BOOT0 and VDD pins are shorted / closed.As of yesterday, have an open tech support ticket with ST on this issue and there is now dialog on how to test. They are escalating to R&D group. Will post the feedback and results of this ongoing review.

[shingadaddy]

Posted on December 13, 2016 at 20:28

Make sure, during your play-time, that you don't have any other playtime bootload path operations still active OUTSIDE the device you are trying to USB bootload. During play-time I have shot myself in the foot with this before.  :\