[Matek F722-STD] Cannot connect without battery

[rapiertg]

Matek Systems F722-STD 1.9.1, 2.0.0 rc4

INAV/MATEKF722 2.0.0 Jul 14 2018 / 22:39:19 (f2cf315ad)

Behavior

Cannot connect configurator to matek fc without connected battery. After I connect USB only fc leds flashes and when I push connect it only says:

2018-08-01 @ 21:47:24 -- Serial port successfully opened with ID: 1 2018-08-01 @ 21:47:34 -- No configuration received within 10 seconds, communication failed

After connecting battery other equipment (beitan 880, xsr-e, hc-06) start to work and I can connect.

EDIT: Forgot to mention. In Betaflight 3.4.0 it is working fine without battery.

[BranyonRRNTU]

That seems to be common over the range of inav systems. If the system can't detect the required hardware (which it can't without something powering those external devices) then it doesn't boot.

[wilco1967]

probably your USB port / cable isn't supplying enough, and/or you have too many consumers on the Matek 5V rail...

On my F722, it DOES boot, and has GPS, and receiver, with only USB power....

[rapiertg]

@wilco1967 Yes, this is probably the case there is too much demand for current but I think It should not stop the boot process. On Betaflight I can communicate even not all hardware is up.

This issue makes very hard to calibrate esc. All my hardware is soldered on and It would be difficult to rewire every calibration. Not mentioning that I can configure only while not charging my battery.

[BranyonRRNTU]

@wilco1967 It depends entirely on your FC. Most FC's isolate all USB power from your peripherals due to the obvious risk of over drawing your usb power supply. You shouldn't rely on USB to power those peripherals when programming.

@rapiertg it would be a good idea to design/modify your system such that the 5v bus can be separately powered on occasions such as these.

[wilco1967]

In my setup, the (Matek FCHUB-VTX) is powering FC, the receiver and GPS....
The USB supply can easily handle this....

The ESC BEC is powering the Servo's.... (and nothing else....)

VTX is build in on the power distribution (Matek FCHUB-VTX) the rest (non-essentials like Camera, gimbal) are powered by yet another UBEC...

[rapiertg]

Made a lot of testing and have new info: I stripped down the whole quad. The problem is related only to gps. If It is connected then the problem occurs. If I disconnect It, it dont. Rest of equipment were randomly connected during test and have no impact.

It also occured that fc boots but it takes 53 seconds. I just wasn't patient enough to notice. After these 53 second fc is blinking and accepts serial connection from configurator.

[Tygrys-1]

BN-880 has a compass, do you also connect it? In that case: INav is trying to detect the I2C devices, and if the power supply is not enough the I2C line levels could be not in the good signal range, producing errors. Check I2C errors in the configurator. Check if compass is working after that 53s boot. Check the SCA SDL line levels on USB power. Maybe add pullups for SDA/SCL

[iturner6168]

I have the same issue with the Matek 722-std not booting on USB only. In my case the problem is certainly i2C related. If I detach the mag i2C lines from my GPS module it boots fine on USB. If I then attach the i2C lines it hangs the controller. How do I add pullups to the SDA/SCL connections?

[iturner6168]

I did try waiting about 5 minutes after turning on the USB and it remained hung. Also, my USB is a switched externally powered hub so I am confident that the 5V is 2A capable. It does seem most likely that this is an i2C bus issue.

[iturner6168]

I left it in a hung state for another 10 minutes or so and it did finally boot and connect. Time to figure out i2c pullups.

[Tygrys-1]

I have checked the Matek's board power scheme and on the USB power only the 4,5V pad and 3,3V devices are powered. 5V pads should have no power. If any device is connected to 5V pad it will be not powered, causing unstable states on it's output lines. It should do no harm on UARTS, but it will disrupt I2C bus communication. That way the detection process on I2C bus will take a long time due to the timeouts on devices or even on the bus access. BF may start quicker as it's boot process work's different, but the 5V devices should be unusable. This is "by design" on Matek's boards (F405 and F722) and we should be aware of it.

[iturner6168]

Thanks Tygrys-1 understand completely. Conveniently I have my mag on a two pin JR connector and can unplug it when I want to boot from USB and configure my quad, (less the mag function).

[KiwiDavid]

Mag sensors draw very little current and I would think in a GPS module like the BN-880 the mag chip is powered off the GPS regulator. So the module expects 5V input and regulates this down to 3.3V on board to supply the GPS chip and the mag sensor. If there's no 5V source the GPS and the mag will be dead. Also remember that the I2C bus is active low only and the slave devices expect to see a pull-up resistor to allow the signal to swing high. This is usually located at the host (FC) so additional pull-ups should not be required unless total bus capacitance (i.e. multiple slaves over very long bus) has accumulated to the point where the passive high rise time has degraded sufficiently to cause timing errors. If you're hell-bent on adding resistors just make sure they go between the SDA-3.3v and SCL-3.3v. I know the SPF3 FC uses 1k pull-ups which should be fine for several slave devices on a 400kHz bus.

[iturner6168]

A couple of points, I have tried a couple of GPS/Mag units and they both do it. One is a BN-880 and the other is an MN8 unit from China. The symptoms are identical. Next I assume that when the units are unpowered they are pulling the SDA an SCL lines to a state, (low?), that prevents the i2C logic from swinging between appropriate levels. Given this I conclude that pulling them to another level will have no effect on the problem. I have pinged Matek and after the normal check to determine if I am an idiot are hopefully giving the issue some consideration. Given that they don't provide a 5V BEC on board and I am using their FChub PDB anyway one idea would be to use a separate i2C mag chip with 3v provided directly to the part from the f722 3V output.

[KiwiDavid]

I wouldn't like to speculate on what an unpowered I2C device may do when it has pull-up resistors on its SDA and SCL lines going to 3.3v. Usually chips have anti-static protection diodes (reverse biased) between outputs- ground and output-3.3v. If the chip is unpowered these diodes can then forward conduct and effectively rectify the clock and data signals producing a low voltage on the chip. It will be in an unknown state I would think.

[Tygrys-1]

As a workarround you may power the BN-880 from the 4,5V pad. It is done that way on the Omnibus boards and works ok. The Omnibus power circuit design is similar to Matek's, but all "5V" pins and pads on Omnibus are in fact equivalent to Matek's 4,5V pad. That way on Omnibus board the USB is powering all external devices, while on Matek boards only the radio or whatever is connected to the 4,5V pad has power.

[iturner6168]

I tried that this morning and it did not work! The GPS led came on so I know it had the 4,5V power but the controller hung just as before. The 4,5 pad works fine because it was powering the RX. Thanks for the suggestion anyway. The problem is not much of an inconvenience because I have a 30A 12v supply with battery connectors and a big switch built in to my work station so I can switch to "Battery" when required. I suggested to Matek that they add a note to their docs as I am sure that many inav users of Matek boards will run into this issue. Thanks for everyone's help.

[Tygrys-1]

Do yo have I2C errors in configurator status line? If so, it might be the bus termination problem. Is the baro working? It is also on the same I2C bus.

[iturner6168]

Quite by accident here is some news! After I had been using it under battery power for a while I switched off the power but left it plugged into USB with the configurator running. In this situation I have observed that the red LED remains on but the configurator is hung reporting "waiting for data". I came back to the bench a few hours later and found the configurator and inav were now active and the i2c error count was 205. I just started to duplicate this situation and although the configurator is hung I can see the i2C error count which appears to incrementing about 20 i2c errors every 20 minutes. The count increments in chunks of about 20 when it changes. The CPU load is reporting 1366%! MSP load is reporting 4750. Drop ratio 99% Packet errors 0. It has not reconnected yet with an i2c error count of 122. I assume it will reconnect before 205

[iturner6168]

I stopped the experiment at 1 hour and an i2c error count of 554 without it reconnecting. I switched on the battery power and it connected ok. The i2c error count is 588. I question the validity of my previous observation that it had booted while under USB only power and now believe that I must have switched on battery power without making changes to the USB connection and it connected leaving the i2c error count intact as it did after this 1 hour experiment. The conclusion remains that with an i2c device attached but unpowered prevents the controller from connecting.

[iturner6168]

Yes, the internal baro is i2c and works whenever I can connect.

[Tygrys-1]

I'll check the voltage levels on SDA/SCL on baterry power and without it.

[KiwiDavid]

You would need a 'scope to do that - do you have access to one?

[iturner6168]

I would have gone to a scope in my working days but I will have to wait for my birthday in November when my wife has promised to buy me a cheapo one. Still it was fun trying to solve this riddle by inference. Tygrys-1, I am looking forward to hearing the result. Does anyone know how the mag chip is powered when it is integrated into a GPS unit? The reason I ask is that I have an Arduino GY-271 mag module on hand so I wonder if I disconnect the i2c lines to the GPS unit and connect this mag unit to 4.5V, SDA and SDL that it should work.

[Tygrys-1]

I checked the SCL/SDA connection on the Matek F405 board, F722 should be the same. The SCL and SDA are connected to 3,3V line through 4k7 pullups. On battery power and on USB power they have perfect 3,3V and it can be checked by the multimeter for that purpose. The BN-880 seem to have some resistance between the SDA/SCL and the ground. When powered, it has 3,7V on it's SCL/SDA, so it has internal pullups. I tried powering the BN-880 with 4,5V and 6V and it worked on both, got the lock etc. I see no reason for it to disrupt I2C transmission if it is powered on from 4,5V pad.

On one of GPS units I disassembled the HM compass was powered from 3.3V regulator on the GPS board. The whole GPS uniit has the 5V rated power. To make this GPS work with the Omnibus F4 I had to add pullup resistors, about 4k7. Without that it had long boot time, unstable readouts from sensor and many I2C errors. On BF 3.2 AFAIR.

But the I2C bus on MATEK has pullups - so I don't know why it is not working for you.

[KiwiDavid]

If the Matek has other on-board chips that are I2C (eg Baro, Gyro) then it must have pull-ups as you say. I would also expect most GPS/mag combos would have an internal regulator at 3.3V for both the GPS chip and the mag sensor. The actual voltage on the mag sensor is not too critical as it only pulls the SDA and SCL lines low - it can't pull them high and this is why the pull-up resistors are there - usually at the host end. It still suggests the GPS module is not powering up (with USB only) and passing 3.3V to the mag chip. I have the same situation with a SPF3 and I either need to use the flight battery or feed the battery connector via a current limited supply so I can leave props on. Something still doesn't add up here but perhaps we need to recap on all your findings.

[iturner6168]

Let me list the observations I have made so far:

1. My board is a Matek f722-std Tygrys-1 has used an F405 for physical tests. Is the F722 really the same? is there a way that I can check i2C voltages/bias on my F722 using my Fluke multimeter?
2. If USB booting with no i2c mag lines attached, boots ok, attach i2c mag and no boot.
3. I connected the 4.5V, (USB V) to the GPS unit. GPS LED flashed but no boot. This is different than test results reported on the Matek 405? I will repeat this test with the following modes. a. 4.5V to GPS with mag lines connected - try USB boot and check that battery boot connects all devices b. 4.5V to GPS with mag lines disconnected - try USB boot and check that battery boot connects all devices.
4. I tried lowering the i2c bus rate to 100K - same results
5. Very early in chasing this problem I built a quick pinboard experiment to try different pullup resistors, (5K and 2K). I did this to avoid soldering and de-soldering, (drone will be used in a public Airfest display so reliability is a priority). Did not change the boot issue but it was very quickly done!
6. I have tested everything possible short of a maiden flight and it all seems to be working great. I may maiden it today.

[Tygrys-1]

Matek F405 and F722 share a lot of the design. The board layout, used components, pins and pads are mostly the same. There are few CPU lines used diferently on both boards - ie PB0 add PB1 ports and no inverter for SBUS on F722 where it is not needed. The main difference is the CPU chip, but both are pin compatible.

To check the voltage just connect the black probe to the ground and the red to the measured pad. The voltage about 3V means that the bus is proper terminated and in it's high state. Using the ossciloscope there should be visible spikes of low voltage during I2C communication, but overall the bus should stay high.

The MATEK' I2C is properly terminated, so no reason for external pullups, - at least when not using many devices on I2C.

[iturner6168]

Understood. OK, I will try the USB 4,5V route again. Last time I simply moved the Beitian 880 5V line to the 4,5v pad and did the test. I will report again shortly. Tygrys-1 and KiwiDavid, (NZ?) what time zones are you in and when are you active on this thread? I am in USA EST and may be able to tailor the timing of my activities to make this thread more productive.

[KiwiDavid]

NZ is currently 12 hours ahead of GMT. I can check in regularly over the next 12-14 hours ok.

[iturner6168]

Thanks that means that I can catch you RTish from about 6pm EST onwards. Do you work?

[Tygrys-1]

I'm CET, currently GMT+2.

I have BF 3.2.2 on F405. My mag sensor is not detected in BF, but this does not matter here. (BF problem) 1) I have connected BN-880 to F405, 5V pad. I started the board on USB power. The BN has no power. The board boot fast, but no Baro detected. 2) I disconnected the BN and started the board on USB power. The board boot ok, the baro is working ok. Then I connected the BN (with no power). Sensor reading stopped. I disconnected BN and connected again. this time got many I2C errors and baro goes to 10 000m readout. Repeating this process make one of these effects - everything stops, or readouts are strange with many I2C errors. 3) I connected BN to 4,5V pad. The board boot ok, the baro is working ok.

Conclusions: Unpowered BN-880 is making bad things to I2C lines and dissrupts the I2C communication. Other devices on I2C are not detected or are working in the strange way. (1), (2) BN-880 powered from the 4,5V pad is workinig and is not disrupting I2C or devices on it. (3)

I flashed the last BF and the Mag showed up :-)

[KiwiDavid]

Your conclusions are what I would expect. You can't have an unpowered I2C deice connected to the same bus that is being used by active devices. Substrate and protection diodes will start to conduct and disrupt normal bus activity.

[iturner6168]

I tried powering the BN-880 from 4,5V and it boots just fine without battery power! I have no idea why my previous attempt did not work but I'm pleased with this outcome. Thanks to all for the analysis and experiments. It is always great when there is a solution but is much better when it comes with a complete understanding of the cause. Since the Matek F722 is likely to be very popular with inav users who need baro and mag to function and also load up their craft with higher current draw telemetry, wifi etc it would be good to spread the word as this will not be an isolated situation. Just running the GPS module from the USB power line is so simple.

[KiwiDavid]

Great outcome. At least at my age I can always claim "senior moments" for situations like yours.......

[ghost]

We have been using 2xF722's powering everything off the 4.5v supply (including 20+ LEDs) for the last six months without any issues. (The 4.5v is derived from either the USB or 5v input via schottky diodes, can't remember the type but they are rated up to 1 amp.) One unrelated problem you might encounter. Because the F7 processors can be flashed via the UART1 and UART3 ports, connecting devices that stream lots of data to these ports on power up can prevent the inav configurator getting into DFU mode.

[iturner6168]

Flyfisher. I will watch for that too. What sort of devices can do this? KiwiDavid, I declare senior moments every chance I get. See you on RcGroups.

[ghost]

GPS is the main culprit, presumably because it is continuously streaming large amounts of data. I've tested with Bluetooth and SPORT and they seem to be OK but given the large number of UART's available on the F722, it is probably best to avoid using these ports if you can.

[KiwiDavid]

I'm not sure I'm following things here. The GPS must have it's own hardware UART and not share one with the USB/UART bridge chip or UART flashing port. I'm only familiar with the SPF3 but that uses UART1 for USB/UART input for flashing but it can become the MSP port after flashing. GPS is usually on UART2. Maybe I've misunderstood you.

[iturner6168]

Kingfisher thanks for the heads up. As luck would have it I attached my GPS unit to UART4 purely because I put the RX on UART3 per the Matek diagram! It boots just fine. I am now ready to maiden so will not stop and research this right now but will make a note of it. Also the notion of running ALL UART devices from 4,5v sounds dangerous to me as folks would be tempted to add Wifi and other potentially high current draw devices. Your comment about the large number of UARTs on an F722 is precisely why am using it! I am sure others will have the intention of using most if not all of the UARTs and could be tempted to run them all from 4,5v. I will be using 5 devices when I attach the VTX TRAMP control line.

[ghost]

We pull about 300mA from the 4.5v for the Rx, GPS, external baro and BT, that's enough. I was unlucky enough to choose U3 for GPS on my first attempt.

[iturner6168]

Glad you found it out. Now the question is how to prevent other people from a. using BN-880s powered from the 5v rail, and b. not to use USB port 3 on a Matek F722 for a GPS unit. What next?

[ghost]

@KiwiDavid AFAIK F3 processors only scan for activity on UART1 at startup whereas F7 (and I think F4) processors also look at UART3 and that is the potential problem.

[KiwiDavid]

Wow - you do have an in-depth knowledge of the beast. That would make sense now - and all the difference to the outcome. I think you have it cornered now.......

[DzikuVx]

OK, I think it's time to close this. Bottom line: I2C devices needs to be powered if connected since they will screw I2C bus otherwise. Thanks