ChibiOS port of ArduPilot

yes, that board should work fine with either the F4Light HAL maintained by @night_ghost or with the ChibiOS HAL that Sid and I have done. So you can do either port or both :slight_smile:
If you’d like to do the ChibiOS port then please see the docs here:
http://ardupilot.org/dev/docs/porting.html
Cheers, Tridge

Thanks Tridge. I have read the porting guide. Nice work. Have you and Sid brought your Chibios system up on the Omnibus F4 V3? Or would I need to be the pioneer for that board? I can’t tell from this list if someone has already brought up the Omnibus F4 V3:

It’s one of the more common boards among those following night_ghost. And actually, my main question before going pioneer is have you guys had success with a digital airpspeed sensor on I2C to any of the STM32 flight controllers?

Kelly

@tridge I would like to know why for the revomini do you use PC6 for RCIN instead of PB14 as in F4Light HAL, this will let UART6 free for GPS and PB10,PB11 could be used as I2C (instead of UART3) for an external compass.

Andrea

@anbello, i think PB14/15 use timer12 and that isn’t referenced in chibios f405 dma table yet. this is quite a bit beyond my knowledge though.

basti

I think the f405 table was amended a couple of days ago when the omnibusf4v2 board was added to ChibiOS, so if someone wanted to change it, might be possible now.

1m
@james_pattison I think you are right, from what I see here should be possible to use PB14 or PB15 as RCIN.

My latest post contains wrong information, is not possible to use PB14 or PB15 as RCIN using DMA, but now @sh83 has added support for interrupt based RCIN parsing:

I tested this for target omnibusf4pro on a quad with Omnibus F4 Pro V2 and it is all OK. I did also a test flight in stabilize, althold, loiter, circle and land, all OK.

2 Likes

I set up an enviroment on a Raspberry Pi 2 for building the Arduplane Chibios firmware for STM32F flight controllers. All appears to have gone well except the final --upload. Any ideas what might be wrong? FC is Omnibus F4 V5 if that matters. Is airbotf4 the right board?

 pi@PiZeroW:~/ArduPlane/ArduPilot $ sudo ./waf plane --upload
Waf: Entering directory `/home/pi/ArduPlane/ArduPilot/build/airbotf4'
Checking for env.py
env added CHIBIOS_BUILD_FLAGS=USE_FATFS=no CHIBIOS_PLATFORM_MK=os/hal/ports/STM32/STM32F4xx/platform.mk CHIBIOS_STARTUP_MK=os/common/startup/ARMCMx/compilers/GCC/mk/startup_stm32f4xx.mk
[436/438] Linking build/airbotf4/bin/arduplane
[437/438] Generating bin/arduplane.apj
[438/438] Uploading build/airbotf4/bin/arduplane.apj
Loaded firmware for 46,0, size: 820464 bytes, waiting for the bootloader...
If the board does not respond within 1-2 seconds, unplug and re-plug the USB connector.
Found board 46,0 bootloader rev 5 on /dev/serial/by-id/usb-APM_REVO_405_0-if00
ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff ffffffff type: ÿÿÿÿ
idtype: =FF
vid: ffffffff
pid: ffffffff
coa: //////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////8=

sn: 004900363436510b35373636
chip: 10076413
family: STM32F40x
revision: 1
flash 983040

Erase  : [====================] 100.0%
Program: [====================] 100.0%
Verify : [                    ] 1.0%Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Attempting reboot on /dev/serial/by-id/usb-ArduPilot_revo-mini_360049000B51363436363735-if00 with baudrate=57600...
If the board does not respond, unplug and re-plug the USB connector.
Traceback (most recent call last):
  File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 736, in <module>
    main()
  File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 710, in main
    up.upload(fw, force=args.force, boot_delay=args.boot_delay)
  File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 559, in upload
    self.__verify_v3("Verify ", fw)
  File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 461, in __verify_v3
    report_crc = self.__recv_int()
  File "/home/pi/ArduPlane/ArduPilot/Tools/ardupilotwaf/px_uploader.py", line 254, in __recv_int
    val = struct.unpack("<I", raw)
struct.error: unpack requires a string argument of length 4

Waf: Leaving directory `/home/pi/ArduPlane/ArduPilot/build/airbotf4'
Traceback (most recent call last):
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 165, in waf_entry_point
    run_commands()
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 266, in run_commands
    ctx = run_command(cmd_name)
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 250, in run_command
    ctx.execute()
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Scripting.py", line 616, in execute
    return execute_method(self)
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 255, in execute
    self.execute_build()
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 275, in execute_build
    self.compile()
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Build.py", line 377, in compile
    raise Errors.BuildError(self.producer.error)
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Errors.py", line 45, in __init__
    WafError.__init__(self, self.format_error())
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Errors.py", line 51, in format_error
    txt = tsk.format_error()
  File "/home/pi/ArduPlane/ArduPilot/modules/waf/waflib/Task.py", line 415, in format_error
    txt = cmd
NameError: global name 'cmd' is not defined
pi@PiZeroW:~/ArduPlane/ArduPilot $

It looks like --upload has actually done two out of three steps, being the ‘erase’ and ‘program’ steps, and that the ‘verify’ didnt work because the automatic reboot failed. … it does actually tell you to unplug and replug the usb cable at that stage… did u try it?

Hopefully this thread is still live. I’m running a Chibi build of Rover and am also having problems with rebooting - PREFLIGHT_REBOOT_SHUTDOWN seems to crash the Cube requiring a power cycle.

Is that with the latest build from firmware.ardupilot.org? Does it happen every time, or just sometimes? Can you post your parameters?

Currently it’s every time with Rover 3.3. I’ll try with the latest and upload the params.

OK, now that I’ve been able to upload a 3.4-based version, the reboot is fine. Apparently you modified the reboot code on May 26th which fixed it.

1 Like

Guys, Posted this on RCG without any respinse so far. Figured the forums here a better place for advice on this so here goes:

Looking for advice to load the ChibiOS Bootloader and then Arduplane onto the Omnibus F4 Pro v2 board.

This is what I did so far and the problems encountered:

  1. Downloaded the F4Pro bootloader.bin from here: https://github.com/ArduPilot/ardupil...usf4pro_bl.bin
  2. Wrote the above bootloader to the board using: dfu-util -a 0 --dfuse-address 0x08000000 -D /my_local_path/omnibusf4pro_bl.bin -R -S “376635653036” (the latter being the serial for my board). This wrote successfully.
  3. Booted my Mac into windows, loaded device manager, plugged in USB cable to board and - no port appears for the board in Device Manager! The board’s green LED is the only one which lights (solid). No flashing blue LED as I usually see.

So unable to use mission planner to write the firmware file downloaded from http://firmware.ardupilot.org/Plane/latest/omnibusf4pro/arduplane.hex

On the other hand, I can successfully use dfu-util to write the F4Light version of ardupilot from N-G’s github repo and the board works fine. I tested that now and looking to move forward, so any advice for loading ChibiOS version of arduplane to this board would be gratefully received. Cheers, Paul

Easiest way is to grab the _with_bl.hex from here: http://firmware.ardupilot.org/Copter/latest/omnibusf4pro/
And use BetaFlight configurator to flash.
Once the bootloader is on you can use the .apj firmware and whatever gcs.

@james_pattison,
Thanks ever so much. This worked fine. Put board in DFU mode, and using Betaflight enebled ‘No reboot sequence’ and ‘full chip erase’, loaded in arduplane_with_bl.hex and worked a treat. It would be great if this was written in the wiki somewhere.

Thanks again, Paul

edit: James, after applying the firmware (and bootloader) with BF Config, I still can not apply the ‘latest’ firmware update using mission planner (with current beta updates applied). If I try to load the apj file I immediately get an error: ‘System.IO.FileLoadException…’ If I try the firmware.hex, then re-power the board when prompted, It doesn’t appear to load into the boot loader, but boots normally, the MP reports ‘Can’t detect your board version. Please check your cabling’. So looks like a driver issue, but I can connect MP perfectly with the board booted, so the regular PX4 driver working ok.
To be honest, I can stick with the BetaFlight updater for now so not a biggie, but would be nice to be able to use MP for updates.

Any advice as to which specific windows Driver I should have installed to allow Mission Planner firmware loader to be able to interrupt the board on boot to get it into boot loader? I Currently have the PX4fmu.inf one installed from Mission Planner Drivers folder. Thanks, Paul

I don’t recall installing anything other than the default drivers, but that doesn’t mean that something else wasn’t already on there.
Ping @Michael_Oborne

Actually, this might be caused by the new board IDs that have rolled out with the new bootloader. Will check tonight.

You may need to install the ST USB serial drivers for older versions of windows. I’ve asked Michael if he can add those USB VIDs/PIDs to MissionPlanner

Windows10 here Tridge. Initially got some generic USB serial driver detected, wouldn’t connect in MP, so updated driver replacing with PX4fmu driver, this works for MP generally, but not for FW updates. Cheers.

Edit: Found MP issues were resolved by removing .NET from Windows 10, so not a driver issue after all, instead related to DLL versions/coexistance. Able to flash successfully now.