Takes 2 minutes to enter DFU mode?

Brad Holland · ‎2017-03-09

Posted on March 09, 2017 at 22:58

We're having problems at the moment getting our device (STM32F405ZGT6) to enter DFU mode, or rather, we can enter it, but it always takes a little over 2 minutes to appear.

We have a push button switch to on the board to enter into DFU if you let go of the switch at any point before the 2 minutes it will boot into application memory.

When it finally enters DFU mode it behaves as expected.

Interestingly, this will only work on the mac.

Attempting the same on Windows, holding the button in while cycling power, windows will straight away detect an 'unknown device' even after installing the drivers included in the Dfuse demo application folder. Trying to manually install the driver against this 'unknown device' then returns 'the device cannot start'

We have also implemented a 'jump to bootloader' routine within our main application, which shuts down various things before jumping to the internal bootloader.

Using this method on windows will bring the 'unknown device connected' message in windows. Using this method on Mac, nothing is ever detected.

Thanks for reading. Any pointers?

waclawek.jan · ‎2017-03-11

Posted on March 11, 2017 at 11:40

Try to enter DFU on a 'known good' board, e.g. a DISCO or NUCLEO.

If it works differently, seek for the differences in the circuitry.

JW

richard239955_stm1_st · ‎2017-05-11

Posted on May 11, 2017 at 17:10

Hi Brad,

Did you get any further tracking this down? I believe I am seeing exactly the same issue with our custom board and I'm also struggling to find a good explanation.

To outline what we're seeing:

When connected to a Linux host and with BOOT pins set for bootloader we don't see the USB device appear for a couple of minutes. Occasionally we might see a USB error in the system log. Once the device appears it works well.
If we set up a user application that branches to the bootloader then we see similar behaviour, but we see a lot more USB errors and we can see that the code is repeatably resetting up until the 'good run' when it suddenly works.
Using a USB bus analyser we can see the device bouncing up and down and occasionally the start of the USB addressing and configuration stage which then stops as the device resets.

I think that sounds similar to what you've seen? Any pointers gratefully received!

Richard

Tuttle.Darrell · ‎2017-05-18

Posted on May 18, 2017 at 13:42

I saw similar behavior. I was working on test firmware for a new batch of boards and was using the built-in system memory bootloader to program the boards using DFU. I was experiencing this delay for every new board. After the board finally was recognized in DFU mode, it no longer had the problem. It appeared that Windows (WIndows 7 Professional in my case) was reloading a driver for each new board.

My solution: Instead of using DFU, I programmed the boards using my programmer/debugger. I re-wrote the test code to use the USB as a VCP and tested the USB using that setup. I initially still had an issue with a delay for each new board, but then I changed the test code to report the same USB serial number for each board. Windows then saw each board as being the same board and skipped the driver loading. Each new board was then quickly recognized and usable via USB and could be tested immediately.

This worked well because this was only test code, but would have been unacceptable for many applications which would require a unique USB serial number. For example, with a unique serial number in a VCP application, each unique board would always get it's own unique COM port number every time it was attached to a given computer. It also does not help firmware upgrades in the field where we are relying on system memory boot mode.

I don't know the ultimate solution and I don't know if the other cases in this thread are the same problem or not. In my case, it seemed more a problem with Windows.

richard239955_stm1_st · ‎2017-05-18

Posted on May 18, 2017 at 12:56

We have done some further testing, and connecting VBUS makes no difference and putting a 1.5k pull-up on D+ breaks USB entirely.

Anyone have any ideas?

richard239955_stm1_st · ‎2017-05-18

Posted on May 18, 2017 at 14:35

Thanks Tut, that's interesting. As you say it does sound a bit more Windows related, but the initial behaviour sounds similar, so I it's probably worth testing the behaviour of our board on a Windows machine.

Tuttle.Darrell · ‎2017-05-18

Posted on May 18, 2017 at 15:22

Good luck! Based on my experience you are likely to see similar behavior with Windows. I assume that with a unique USB serial number, Windows is installing the unique device into the directory (or wherever ... I'm not a Windows expert). Why it takes so long (more like 5 minutes or so in my experience) is beyond my knowledge. I am guessing that Linux does something similar, but I am not a Linux user. The time delay is frustrating for any user, but totally unacceptable when testing lots of boards.

richard239955_stm1_st · ‎2017-05-19

Posted on May 19, 2017 at 09:57

I have done a trawl through the forum, and found this thread:

https://community.st.com/0D50X00009Xki0NSAR

which I'm pretty sure is the same thing, as I've also come to the conclusion the issue is caused by problems with the start-up of the HSE. I also suspect this one is related:

https://community.st.com/0D50X00009XkeNlSAJ

I was hoping I could fix the issue by starting the crystal (by setting HSEON in RCC_CR) on boot, waiting for ~200ms before branching to the bootloader. However, I'm still seeing the same reset behaviour :(