2017-03-09 01:58 PM
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?
2017-03-11 02:40 AM
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
2017-05-11 08:10 AM
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:
I think that sounds similar to what you've seen? Any pointers gratefully received!
Richard
2017-05-18 04:42 AM
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.
2017-05-18 05:56 AM
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?
2017-05-18 07:35 AM
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.
2017-05-18 08:22 AM
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.
2017-05-19 02:57 AM
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 :(