Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Entering DFU mode problem #34

Closed
JoeScotty opened this issue Aug 14, 2020 · 2 comments
Closed

Entering DFU mode problem #34

JoeScotty opened this issue Aug 14, 2020 · 2 comments

Comments

@JoeScotty
Copy link

Purchased a Aus3D Rumba32 V1.03e and suddenly having a problem entering the DFU mode.
The way it worked up to now:
plug in USB, press and hold BOOT, press and release RESET, finally release BOOT. The LED1 flashes once.
I can follow the process on Win10 device manager, COMx is dropped and STM32 Bootloader came up.

Without an obvious change, the LED1 does not flash any more and the changes in the device manager did not happen any more.

Tried to find solutions. There was one hint with the quartz frequency being out of tolerance, which could cause such a problem.
Would be happy getting some hints (others than dropping the board ;-).
Thanks!

@chrissbarr
Copy link
Contributor

Hi @JoeScotty. Sorry to hear you've run into a bit of trouble. Happy to help troubleshoot if I can!

To confirm, is it V1.0E that you have?

I'm not familiar with any issues impacting the ceramic resonator on the board - it might be possible, but it's not something I've seen before. Importantly, I believe the resonator isn't used for the DFU bootloader's USB communication (as the bootloader runs before the clock inputs are initialised in the firmware). My understanding is that the USB DFU comms use the internal clock source, and does some trimming of that based on the USB timing frames. I am not very familiar with the process - but I believe it is fairly resilient to issues with the resonator on the board.

There is a recently-noticed flaw in the design that can impact the bootloader correctly starting. There is a pull-down resistor required on pin PB2 that is not included on boards prior to V1.1B. This can result in intermittent bootloader behaviour in some cases - if PB2 floats high, that can prevent the bootloader from running in the correct mode.

PB2 is broken out to the EXP2 header, and so can be affected by things attached to that header (commonly displays etc.). It is possible that an issue with this pin is causing your trouble.

If you are handy with a soldering iron, the easiest fix is to add in a 100K resistor between PB2 and GND. There is no downside in the regular use of the board in adding this resistor - this is what is being done on V1.1B forward. This can be done on the back of the board like so:

PB2-pulldown

Otherwise, there are some soldering-free ways we can check if this is the problem. If you have any female jumper wires you can temporarily connect PB2 directly to GND. The only downside to this is that it prevents using any peripheral attached to the EXP2 header. However, it might be an easy way to check if this is the problem you're seeing.

It's possible that it is a different issue that you're seeing. At the moment, this is the only issue I'm aware of surrounding the bootloader - so I'd suggest checking if the above solves the issue, and if not we can explore other options.

Let me know what you think, happy to explain anything more or do anything else I can to help.

@JoeScotty
Copy link
Author

Hi Chris,
thanks for your quick reply!
I tested adding the 100k with clips and entering the DFU mode worked in all tests!
So I'm very sure this was the solution.
I'm going to solder the resitor like you suggested.

May I suggest to add this mod to the SLI mod already published for the V1.0E.

Now I'm happy that I can proceed with firmware configuration!
Thanks again, Regards
JoeScotty

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants