Hei all!
I plan to port ardupilot to this board
what would be a new place to start?
I have some experience with the iFlight Beast F7
Should I create a new hwdef or can I just flash the Beast F7 firmware?
Thank you
1 Like
Checkout the source tree and then use this on the betaflight config to get you started:
oooh very nice! thank you
I tried copy-patch from the BeastF7 model (libraries/AP_HAL_ChibiOS/hwdef ) but there might be some bootloader issues, I am not able to read data either on qgc nor via mp
iâll work on it this week
@andyp1per
ok so iâm pushing here my progress: add new board BlitzF7 ¡ tiralonghipol/ardupilot@0f35997 ¡ GitHub
so far I was able to build the bootloader and a firmware version that âmatchâ and do not give errors
But I am not able to read any data either on MP or QGC
any hint?
I confirm that both bl and firmware are written with a simple dmesg -w command:
[10135.151737] usb 1-2: new full-speed USB device number 36 using xhci_hcd
[10135.301219] usb 1-2: New USB device found, idVendor=1209, idProduct=5741, bcdDevice= 2.00
[10135.301247] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10135.301259] usb 1-2: Product: BlitzF7-BL
[10135.301268] usb 1-2: Manufacturer: ArduPilot
[10135.301276] usb 1-2: SerialNumber: 29002F000450485434373920
[10135.303766] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
[10139.927787] usb 1-2: USB disconnect, device number 36
[10140.239625] usb 1-2: new full-speed USB device number 37 using xhci_hcd
[10140.389274] usb 1-2: New USB device found, idVendor=1209, idProduct=5741, bcdDevice= 2.00
[10140.389301] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[10140.389314] usb 1-2: Product: BlitzF7
[10140.389323] usb 1-2: Manufacturer: ArduPilot
[10140.389331] usb 1-2: SerialNumber: 29002F000450485434373920
[10140.392228] cdc_acm 1-2:1.0: ttyACM0: USB ACM device
maybe this can be useful also, to verify that the bootloader I generated makes sense:
pol@pol-P15:~$ dfu-util --list
dfu-util 0.9
Copyright 2005-2009 Weston Schmidt, Harald Welte and OpenMoko Inc.
Copyright 2010-2016 Tormod Volden and Stefan Schmidt
This program is Free Software and has ABSOLUTELY NO WARRANTY
Please report bugs to http://sourceforge.net/p/dfu-util/tickets/
Found DFU: [0483:df11] ver=2200, devnum=38, cfg=1, intf=0, path="1-3", alt=3, name="@Device Feature/0xFFFF0000/01*004 e", serial="00000008FFFF"
Found DFU: [0483:df11] ver=2200, devnum=38, cfg=1, intf=0, path="1-3", alt=2, name="@OTP Memory /0x1FF0F000/01*001Ke,01*032 e", serial="00000008FFFF"
Found DFU: [0483:df11] ver=2200, devnum=38, cfg=1, intf=0, path="1-3", alt=1, name="@Option Bytes /0x1FFF0000/01*032 e", serial="00000008FFFF"
Found DFU: [0483:df11] ver=2200, devnum=38, cfg=1, intf=0, path="1-3", alt=0, name="@Internal Flash /0x08000000/04*032Kg,01*128Kg,03*256Kg", serial="00000008FFFF"
Try connecting with mavproxy - it will show debug information, itâs probably not initializing a device properly which means it not getting any further.
awesome! apparently the barometer is not initialized properly
pol@pol-P15:~$ mavproxy.py --master=/dev/ttyACM0
Connect /dev/ttyACM0 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from /dev/ttyACM0
MAV> AP: Config Error: fix problem then reboot
AP: Config Error: Baro: unable to initialise driver
Detected vehicle 1:1 on link 0
online system 1
STABILIZE> Mode STABILIZE
AP: Config Error: fix problem then reboot
Config Error: Baro: unable to initialise driver
AP: Config Error: Baro: unable to initialise driver
AP: ArduCopter V4.4.0-dev (0f35997d)
AP: ChibiOS: 046f5872
AP: BlitzF7 002F0029 54485004 20393734
AP: RCOut: Initialising
AP: motors not allocated
Received 979 parameters (ftp)
Saved 979 parameters to mav.parm
Flight battery warning
then, after adding
define HAL_BARO_ALLOW_INIT_NO_BARO 1
in hwdef.dat, I rebuilt (I know, itâs bad, but just for now I exclude it)
and the baro error is gone as expected
still dont get any data:
pol@pol-P15:~$ mavproxy.py --master=/dev/ttyACM1
Connect /dev/ttyACM1 source_system=255
Log Directory:
Telemetry log: mav.tlog
Waiting for heartbeat from /dev/ttyACM1
MAV> Detected vehicle 1:1 on link 0
online system 1
STABILIZE> Mode STABILIZE
fence present
AP: ArduCopter V4.4.0-dev (0f35997d)
AP: ChibiOS: 046f5872
AP: BlitzF7 002F0029 54485004 20393734
AP: RCOut: PWM:1-4 PWM:9
AP: Frame: QUAD/BF_X
Received 1092 parameters (ftp)
Saved 1092 parameters to mav.parm
Flight battery 100 percent
AP: PreArm: RC not found
AP: PreArm: 3D Accel calibration needed
AP: PreArm: EKF attitude is bad
AP: PreArm: Battery 1 below minimum arming voltage
Dataflash: erase done (34526 ms)
AP: Chip erase complete
MAV>
EDIT: I can visual feedback of acc and gyro on MP but not on QGC!
why is that?!
I donât do QGC. Does it actually have a baro? You can probe for the actual device using devop in mavproxy
it does, according to the specs: https://shop.iflight-rc.com/BLITZ-Whoop-F7-AIO-Pro1927
apart from that the command you suggested doesnt seem to work on my machine 
another note: have you ever seen a behavior where the groundspeed showed on MP is ~500 m/s and the imu is just nosense? board is still on the desk and the roll/pitch/yaw just keep slowing diverging to nonsense
Yeah I see this on boards with no baro. I think its some EKF weirdness.
1 Like
@andyp1per I managed to get basic sensors running yu-uu!
To open a PR I guess some hardware test is required?
Are you interested in helping testing? I can send you a board in case
Thank you for your precious help
Great! If you have the board and can test the various functions that should be enough - but happy to also test if you want to send me one. I wonât have time to flight test - that requires a lot more time.
hei @andyp1per
I built a quick quad to test the board and after several pathes I cannot figure out why the âmotors are not spinningâ. My first guess was âwrong pins assignmentâ in the hwdef. But I triple checked and it should be correct.
I am sure that the RC is read correclty on uart3 and I built so many quads now that I doubt it is a soldering issue
This is the unified target I got via betaflight
and this is the corresponding hwdef I am flashing on the board
do you see any issue? or do you have any idea on how to debug this?
Looks correct. Worth checking that you actually get DMA channels allocated. Maybe trying setting DMA_NOSHARE on TIM3_UP
1 Like
ok. dumb question, how can I make sure DMA channels are actually allocated?
You have to look in the generated hwdef.h at the DMA map
not sure I am able to read it properly
with this hwdef file the generated .h is this
copy_of_hwdef.h (54.6 KB)
I am afraid I lack some knowledge here to spot any issue
is this ok?
another test I did (meanwhile I was crashing my head on DMA) was checking that the problem is not on the ESCs, but that also should be ok. I can correctly use https://esc-configurator.com/ and read/write settings using fc pass-through.
EDIT
I figured it out!
I noticed in the generated file this line:
// Note: The following peripherals canât be resolved for DMA: [âTIM3_CH4â, âUSART1_RXâ]
So I commented these lines:
#DMA_NOSHARE SPI3* TIM3_UP
#NODMA I2C*
#define STM32_I2C_USE_DMA FALSE
and now it works
Not entirely sure why, but now it is working.
The lack of DMA channel for TIM3_CH4 would have been the problem
1 Like
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.