-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Matek F722-SE board not connecting and/or boot looping on 2.1.0 RC1 #4205
Comments
On my bench I have quad with F722SE and it works with 2.1 RC1 without any problems. |
Hi... I was booting VERY successfully with the Dec 26 version of 2.1 (from the Matek web site) from just the USB power. My GPS/Compass is a M8N (flipped 270) and is indeed powered from the 4V5 pads. What's annoying is everything worked perfectly until I flashed the recent RC1 and got caught in the boot loop as my OP states. I can't get into DFU mode to flash another firmware (like BF) to get out of the bootloop without disconnecting power to GPS/MAG and SBUS receiver... Any other thoughts on what I can do/try or to get you more info for other suggestions? Thanks... |
If you have anything that transmits data to the FC connected to UART1, DFU will hang. That's how built-in bootloader operates and this behavior can't be changed. To get it working - disconnect or power down any external hardware connected to UART1. |
My MATEKF722-SE boots fine. As @DzikuVx mentioned you need to have all your peripherals powered (especially those connected to I2C). |
Well... looks like the problem was my GPS connected to UART1 and MAG on I2C (one unit). I reconnected it to UART3 and everything works fine now... especially getting into DFU. Thanks for your help. I think this can be closed but I must say that the Matek Instructions specify UART1 at http://www.mateksys.com/?portfolio=f722-se#tab-id-4 Anyway... looks good, now to tackle 3DR coms... (for another thread...) |
when it happens if you deactivate all the ports or in the cli execute defaults you can enter the bootloader, flash and then restore the settings of the diff |
Current Behavior
I think this problem in Issue #4076 still persists. I very recently completed a 250mm Quad build with a Matek F722-SE board and Betaflight 3.5 installed flawlessly. I installed the iNAV firmware from the Matek website (after the versions in the configurator failed with Boot Loops) which offered TWO variants of 2.1.0 at the time... a Dec26 version and a Nov 20 version. The Nov 20 version resulted in Boot Looping and each time it happened it would be necessary to fix windows with Zadig and then the ImpulseRC tool. It seems that by fluke only, the Dec 26 version installed and Boot Looping stopped. I fully configured my quad with compass and mag. I could not get the Sik radio to communicate with the FC on UART3... so... after much frustration, the RC1 version was released so I hoped this communication would be fixed and installed the RC1 firmware and the Boot Looping started again and it happened with EVERY iNAV 2.1 firmware attempted.
Also, the ONLY WAY to get the FC recognized by Windows 10 with Zadig and ImpulseRC was to unsolder the 5V power to the GPS and R9-SBUS otherwise ImpulseRC would report and error of: "Unexpected number of devices detected" and FC would NEVER get into DFU and be recognized by windows.
Once a successful DFU is connected, the FC can be installed with iNAV but only to have it Boot Loop before any CLI settings can be examined to troubleshoot OR it can be installed with Betaflight and all of the problems go away. Betaflight on the board also functions properly for DFU mode with GPS and SBUS and all other Serial devices connected whereas iNAV firmwares required them to be disconnected.
Like @amusinov in Issue #4076, I'm keeping this F722-SE on Betaflight until hoping the bugs can be resolved. I'm happy to put iNAV on to help with the troubleshooting if asked. I also have a DIFF dump from the functioning iNAV 2.1 variant from Dec 26 if that helps... link below
Thanks.
Steps to Reproduce
Additional context
This version was working fine. Boot loop starts before I can write these values to CLI in case they have anything to do with stopping the Boot Loop
Diff CLI dump
version
INAV/MATEKF722SE 2.1.0 Dec 26 2018 / 18:49:07 (a5a92b5)
GCC-7.3.1 20180622 (release) [ARM/embedded-7-branch revision 261907]
The text was updated successfully, but these errors were encountered: