PX4-Autopilot
PX4-Autopilot copied to clipboard
PX4
KakuteH7 firmware very slow on startup
When flashing the KakuteH7 with the latest master build, the FC boots very very slowly (taking up to 20 seconds). The default Betaflight firmware does not have this issue. I've also tested removing a lot of the modules to see if that would change things, but it didn't. Because of this, the ESCs do not get the proper commands on time and thus never finish the startup sequence. Only way now to use it is to power the FC first by usb cable, wait until it has completely booted and only then power the ESCs.
To Reproduce
- Build the KakuteH7 bootloader (latest master) and flash it using
dfu-util. - Flash the custom master build using QGroundControl
- Now the FC takes about 20 seconds to boot, which if using the batteries results in only the first three beeps of the ESCs, but not the two last ones.
Drone:
- Custom drone with the KakuteH7 FC and Tekko32.
Yes I noticed that as well (https://github.com/PX4/PX4-Autopilot/pull/19019). Seems to be something lower-level, and I don't have a jtag setup for the board.
Ah I see, I missed that line in that commit. Is there any way I can help looking into this? Or do you have a clue why the ESCs do not start up after this extremely long boot time? Do they go into some kind of standby mode or something when they don't receive the throttle low/high values fast enough? Is there any way to get around that?
Hi, I see that in the latest stable release, this is still an issue. Could that be correct @bkueng? So still the ESC's are not initializing after starting up and it takes around +-20 seconds for startup. Let me know if there exists a fix.
@bkueng, are there any plans for fixing this in the near future? Is there any way in which I could be of help?
I probably don't have the time, but you're very welcome to look into this. I'd hook up a debugger to check where in the bootup it hangs.
Okay I have attached a black magic probe to the SWD pins of the KakuteH7 and am able to debug using VS Code @bkueng. One issue I have now is that, although I can manually pause, the software does not seem to stop at breakpoint that I set. Do you have any clue why that might be the case? This is making it more difficult for me to find out where it is hanging in the bootup.
Is this on latest main? In the NuttX source code? Does it work if you set one in a PX4 source file?
Yes on latest main and in the NuttX source code. It also doesn't work in a PX4 source file. I have been able to set a breakpoint when I specifically set a hardware breakpoint when I use gdb in the console however, so it seems like it is an issue with how I define the breakpoint in VS Code, maybe I am missing something there?
@sstroobants in vscode did you select the kakuteh7 variant (for cmake configuration)? I use vscode debugging fairly often on various boards, but with a jlink. It could be the blackmagic config within vscode that's not configured properly.
Yes I did use the kakuteh7 variant (it was not in the cmake-variants.yaml file, but I added it myself:
holybro_kakuteh7_default:
short: holybro_kakuteh7
buildType: MinSizeRel
settings:
CONFIG: holybro_kakuteh7_default
I can have another look at the blackmagic config but I am not sure what I could change there to specifically set the hardware breakpoints.
@sstroobants Did you figure out how to solve this problem? I met the same problem
@julianoes @bkueng Any idea why there is such a delay? Doesn't happen in betaflight.
https://github.com/PX4/PX4-Autopilot/assets/46874772/580fcc1c-0c21-410f-9d96-45e96ec0e37b
Is this more than just the 5s of the bootloader? I believe the bootloader USB connected check doesn't work correctly leading to a 5s delay.
Is this more than just the 5s of the bootloader? I believe the bootloader USB connected check doesn't work correctly leading to a 5s delay.
It seems to take around 20 seconds
I'll try to reproduce. Best would be to get the output of dmesg after this happens.