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

Matek F722-SE board not connecting and/or boot looping on 2.1.0 RC1 #4205

Closed
MartyFufkin opened this issue Jan 14, 2019 · 6 comments
Closed

Comments

@MartyFufkin
Copy link

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

  1. Seems Intermittent... I had success with the Dec 26 2.1.0 firmware and also failure with it and others.

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]

  • FC Board name and vendor: MATEK F722-SE
@MartyFufkin MartyFufkin changed the title Matek F722-SE board no connecting and/or boot looping Matek F722-SE board not connecting and/or boot looping on 2.1.0 RC1 Jan 14, 2019
@DzikuVx
Copy link
Member

DzikuVx commented Jan 14, 2019

On my bench I have quad with F722SE and it works with 2.1 RC1 without any problems.
Is your MAG powered during boot? If MAG is not powered then board will fail to boot. It's a good practice to power the MAG using 4V5 pads that have voltage also when USB powered

@MartyFufkin
Copy link
Author

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...

@digitalentity
Copy link
Member

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.

@digitalentity
Copy link
Member

My MATEKF722-SE boots fine. As @DzikuVx mentioned you need to have all your peripherals powered (especially those connected to I2C).

@MartyFufkin
Copy link
Author

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...)

@tiriad
Copy link
Contributor

tiriad commented Jan 14, 2019

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

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

4 participants