The lack of DMA channel for TIM3_CH4 would have been the problem
Hello! Is there any progress on Blitz F7 AIO? My team just bought this FC for a new project and realized that there is no Ardupilot build for it, only for Beast F7 model.
yes I managed to have a working version but more testing is required
I have a forked branch here
bootloader binary is also uploaded
build and flash with standard doc procedure (i use waf)
let me know if I can help but keep in mind that I dont have time for this anymore
I’ll make a funding request to get one so that we can close this out.
@andyp1per I told you I can send you one no problem
how to achieve that?
Thanks for the offer! The funding team has approved the request ([APPROVED] IFlight Blitz F7 AIO for porting - #2 by james_pattison) but we’ll leave it to you and @andyp1per to work out the details/decide which way you want to do things.
Please can you push your changes as a PR so that you get the credit. I have the board so can finish the testing.
please have mercy on me, I’m not a software developer
I’m assuming that the porting is somewhat complete at this point.
However, as I can see, there is no way to test it without the bootloader.
I have the board, but i wouldn’t like to make it “Ardupilot only” (AFAIK flashing the bootloader makes it very hard to return the board to the initial state and flash e.g. Betaflight afterwards).
Can someone orient me about whether it is possible to somehow flash without a bootloader, or at least orient what should happen for this and how long to wait for this?
I tend to disagree. During the porting process I was switching back and forth to betaflight .hex using the STM32 gui very easy
remember to boot in dfu mode and that’s it, you can re flash betaflight at any point
maybe im wrong but this is my experience
Thanks for your reply. I have very little experience with ardupilot, so was just referring to what is written in Loading Firmware onto boards without existing ArduPilot firmware — Copter documentation
installing the ArduPilot bootloader is a one-way operation. You cannot restore the board to factory configuration or load betaflight after this step - you would have to return the board to Seriously Pro to be re-flashed with factory firmware, assuming that is possible
Further reading the documentation, I just realized that the section i was referring to is Seriously Pro specific. Therefore, there will be no problems with flashing bootloader on Blitz F7.
you are welcome to share your testing results, it will be beneficial for all the Ardupilot users : D
Totally. I will be using setup with multiple rangefinders and optic flow sensor, hope everything will work right out of the box. Will provide test results here and on Github.
However, there is a serious problem related to ELRS receiver.
When i power the copter, it forces the receiver to bootloader state.
Tried every available UART.
AFAIK, this somehow relates to the board circuitry and how it handles uart pins during setup. It can be somewhat easily solved by pulling the TX pin of the receiver to 3.3V with a resistor, but this FC doesn’t have any 3v3 outs!
Betaflight works OK btw. So this can be fixed with the software.
Right now the only viable solution I could come up with is assembling receiver with a connector, disconnecting it, powering the copter, connecting the receiver. It’s not how I would like it to be, but I need this to work ASAP for my project where I need ELRS + Ardupilot combo.
Hardware: IFlight Blitz F7 AIO, Happymodel EP2 TCXO on UART1, Rush Tank Tiny on UART7, LED strip.
In SERIALx_OPTIONS there is a TX_PullUp setting - can you try that?
Thanks for a quick response!
This sounded promising, but unfortunately didn’t work
Tried both RX and TX, both pullup and pulldown
I mentioned that I managed to get it to work by disconnecting receiver, powering up, then connecting again.
However while testing different UARTs, I noticed that if the receiver is connected to UART3, it doesn’t power up from USB (UART1 does power up when I connect FC to PC via USB). So, when the receiver is connected to UART1, it gets to bootloader state regardless of whether it was powered by USB or battery. But when it is connected to UART3 for example, the following sequence can also make it work normally:
- Connect USB
- Connect to Mission Planner
- Plug in the battery
Ofc this is not how it should be, just trying to provide maximum amount of info.
I have never heard of this problem before and I have never encountered it during my testing of ELRS, I think it must be a problem with your receiver. Many people are using ELRS with ardupilot without encountering this issue.
Can you please tell me the exact model of receiver you used?