[Control Zero F7] [Urgent] Board does not boot up with new firmware + PM reading not shown

[matthewoots]

[Control Zero F7] [Urgent] Board does not boot up with new firmware

Hi there,

2 issues :

1. FC PM voltage reading and current reading from PR boards: mro ctrl zero f7 fix default power module calibration #16542 is not solved
2. FC unable to boot up

FC PM was checked with previous commit and does not work. I've used the previous commit with the firmware that actually managed to boot up the FC (746b312) this is quite a long time ago. This was running on GCC 7-2017-q4 which is found on the install page https://dev.px4.io/v1.9.0/en/setup/dev_env_linux_centos.html#gcc-toolchain-installation. Because the current GCC is running on GCC 9-2020-g2 as per arm-none-eabi-gcc --version.

UPDATE : Tried branch 1.11.2 and the board boots up well, but I've applied PR #16542 and the PM reading does not work.

UPDATE2 : It could be a GPIO input for the ADC under board_config.h

#define ADC_BATTERY_VOLTAGE_CHANNEL /* PA2 */ ADC_CH(2)
#define ADC_BATTERY_CURRENT_CHANNEL /* PA3 */ ADC_CH(3)

The PR #16542 does not solve the issue.
Summary :

/* Define Battery 1 Voltage Divider and A per V */
#define BOARD_BATTERY1_V_DIV         (18.1f)     /* measured with the provided PM board */
#define BOARD_BATTERY1_A_PER_V       (36.367515152f)

The FC being unable to boot up. (Symptoms are in bold) no startup tune is heard and the FC goes into a continuous periodic flashing red light as shown in the video.

To Reproduce

git clone https://github.com/PX4/PX4-Autopilot
cd PX4-Autopilot/
git submodule update --init --recursive
make mro_ctrl-zero-f7_default
make mro_ctrl-zero-f7_default upload

Expected behavior

1. PM voltage reading and current reading
2. FC unable to boot up with blue light

IMG_9493.MOV

[ryanjAA]

Try changing in board_config.h:

#define ADC_BATTERY_VOLTAGE_CHANNEL /* PA2 */ ADC_CH(2) to
#define ADC_BATTERY1_VOLTAGE_CHANNEL /* PA2 */ ADC_CH(2)

and

#define ADC_BATTERY_CURRENT_CHANNEL /* PA3 */ ADC_CH(3) to
#define ADC_BATTERY1_CURRENT_CHANNEL /* PA3 */ ADC_CH(3)

It likely needs to point to battery 1 now.

I'll try on a Zero F7 when back in the office

[matthewoots]

Thank you for your suggestion @ryanjAA . But it didn't work. But I found the fix!

In board_config.h

#define BOARD_ADC_USB_CONNECTED	       (px4_arch_gpioread(GPIO_OTGFS_VBUS))
#define BOARD_ADC_USB_VALID            BOARD_ADC_USB_CONNECTED
#define BOARD_ADC_SERVO_VALID          (1)	/* never powers off the Servo rail */
/*this line is the issue #define BOARD_ADC_BRICK_VALID (!px4_arch_gpioread(GPIO_nVDD_BRICK1_VALID)) with the ! */
/*change it to the one below */
#define BOARD_ADC_BRICK_VALID          (px4_arch_gpioread(GPIO_nVDD_BRICK1_VALID))

Anyone with Control Zero F7 hope this helps. See whether this can help with the ESC calibration issue.

[ryanjAA]

Awesome! I haven't had time to try it today but I will. I assume it was just an error.

Is there an ESC calibration issue related to this board as well?

[matthewoots]

Hi @ryanjAA, yup so the error arises from no battery detected, hence the timeout for the ESC calibration is triggered. But I'm not too sure why no one has reported this issue, small bug.

[ryanjAA]

Interesting, ok. I'll try as well and see if your fix does the job. It's a newer board so likely not as many users yet. Good find. Let's see if it does the trick.

You should open a new issues about it though.

[ryanjAA]

Tested and confirming works (on 1.11.3). Battery Voltage and Current.

On 1.11.3 with #16542 I didn't have an issue booting up though. Or were you saying the issue was on Master?

Submit a PR with your change so it can get pulled in.

[ryanjAA]

See #16569 for Control Zero F7 tracking

[mrpollo]

@ryanjAA @matthewoots did we ever get to the bottom of this issue? it seems like it was just failing for @matthewoots, was anyone else able to reproduce his error?

@dagar can you comment on the suggested change above? #16545 (comment)

[ryanjAA]

I never saw the above issue occur on hardware I have - #16590 fixed it. Not #16545 (comment)

[mrpollo]

Weird, I also have a comment on issue #16548 that claims to fix this

[matthewoots]

@ryanjAA Has committed the changes in #16590 that is to fix the PM detection. For #16548, somehow both Control Zero F7 and X2.1-777 exhibits the same error for the new firmware, they do not boot up correctly and hangs like in the above video. After flashing it with @taileron fix, it boots up perfectly.

[mrpollo]

@matthewoots can you point me to the fix from @taileron, please?

[ryanjAA]

This is strange since I dont have this issue, even running 1.11.3 stable on the Control F7.

I'll make a PR with lazy fpu on for the board as it seems to fix thins for others.

[ryanjAA]

@mrpollo #17009 for the Lazy FPU.

[ryanjAA]

and for the Control Zero F7 OEM
#17010

[fettywapssecondeye]

Hey, is this issue fixed in the beta/master? I've had this issue some time ago (still have it) on 1.11.3 where the battery voltage/status didnt show at all in qgc but showed up in the logs:

https://discuss.px4.io/t/qgroundcontrol-not-showing-voltage-or-detecting-power-module/20850

Currently on 1.12.0 beta 1, it still points to battery 0 instead of battery 1:

and

And when I try the developer build the mRoControlZeroF7 gets stuck in a boot loop.

I will be trying to implement the same fix on the stable firmware soon because i'm not sure if the changes made are actually reflected in the 1.12.0 beta 1 build:

Appreciate any help, thanks.

[mrpollo]

@ryanjAA can you confirm this has been fixed?

[ryanjAA]

Confirmed. This is fixed and I’ve flown with it quite a bit so I’m not sure why there’d be a boot loop or an issue with power. Let me pull in master and take a look.

[ryanjAA]

@mrpollo I just checked an H7 and all was fine (after I changed the board ID - PR #17140). Will be able to check an F7 tomorrow.

[fettywapssecondeye]

Thanks for checking @ryanjAA . Just to be sure, i'm getting my firmware downloads/installs directly from QGC. These are the same builds you'd be using right?

Procedures wise, i install master and the exact same behavior as the above video happens. For the power modules, i install stable or beta and the problems in my above comment happens.

This is also what it says the firmware version is after installing 1.12.0 beta 1. Not sure if it's notable or not.

[fettywapssecondeye]

Fixed.

I implemented @matthewoots fix onto a v1.11.3 build.

Trying to flash v1.12.0 beta 1 from the pre release leads to the same boot loop issue for me.

Procedure:

download firmware from -> (https://github.com/PX4/PX4-Autopilot/releases/tag/v1.12.0-beta1)
Install with QGC custom firmware option
Same issue as observed in the first video.

Fix for the power brick issue:

git clone https://github.com/PX4/PX4-Autopilot
cd PX4-Autopilot/
git checkout v1.11.3

From here, I went to PX4-Autopilot/boards/mro/ctrl-zero-f7/src.
I was using the windows build environment, so I used nano board-config.h in that directory, scrolled down until i saw
#define BOARD_ADC_BRICK_VALID (!px4_arch_gpioread(GPIO_nVDD_BRICK1_VALID))
and removed the "!" so it then looked like:
#define BOARD_ADC_BRICK_VALID (px4_arch_gpioread(GPIO_nVDD_BRICK1_VALID))
From here, i just went back to the /PX4-Autopilot directory, and built the file again

make mro_ctrl-zero-f7_default
make mro_ctrl-zero-f7_default upload

This fixed the issue for me. Thanks @matthewoots and everybody else.

Note: using just the cloned git repository (I believe this gave me version 1.11.0?) lead me to the same red light flashing bootloop issue. I had to use git checkout v1.11.3.

[ryanjAA]

No boot loop on the F7 (on 1.12 beta 1) but the battery indeed doesn't work. I'll take a look and fix that shortly - not sure why as that was fixed long ago and the PR has been in place for awhile. Will just double check it got pulled into beta1.

Boot loop on Master (as of today) when pulled in from QGC.

@fettywapssecondeye yes, we are getting the firmwares from the same place. I was also checking the MRO Control Zero H7 board which needed the board ID changed so I had to recompile but did so at the same git commit to keep things even.

[mrpollo]

@ryanjAA keep me posted on the battery issue, we need to make sure it makes it into the release

[ryanjAA]

@fettywapssecondeye that technically will work but the fix implemented is slightly different due to changed naming conventions. A working PR has been pushed awhile back but this needs to be looked at as to why beta1 doesn’t have it pulled in.

[fettywapssecondeye]

@ryanjAA Gotcha. i'll only use this as a bandaid for a personal 1.11.3 fix then. I see the nVDD's changed to VDDs and whatnot, that's probably it.

Can you share your procedure as far as installing beta1 goes? I'd love to try 1.12.0-beta1 out and am lost as it's not working with both of the boards i have with me. I've even tried building it myself, no luck.

[ryanjAA]

Ya, I changed the naming at the request of one of the devs but it should work fine as you did it for now.

I have beta1 working on the f7 with no changes (battery numbers don’t work though) but it overall works fine. No recompile needed, just pull in via qgc by selecting beta. Master is currently broken so you’re probably pulling in master when uploading after compiling and so you’re uploading a version that has the boot loop issue. You can pick and arbitrary commit from a week ago and see if that works then do a git bisect to find the issue.

[ryanjAA]

I don't know how but 1.12 Beta1 isn't working now on the F7. Reverting the LAZY FPU commit fixes it. Reverting that commit also makes master work as well (bc8d9af)

I will open a PR with it but it needs a review on why first.

Also, the power settings work fine, the reason it looks like it doesn't work is if battery settings aren't set they show up as 0 and nothing is reported. A default set of settings for battery cells, amps per volt and voltage divider will fix this.

@mrpollo

[mrpollo]

Thanks for the report.

cc @dagar

[fettywapssecondeye]

Confirmed, commenting out line 38 of defconfig (lazy fpu) works for me as well. v1.12.0beta1 battery indicator also works.

[taileron]

all issues concerning to this have been solved and as the lazy fpu line was removed this particular issue can be closed as well