mirror of
https://github.com/iNavFlight/inav.git
synced 2025-07-24 16:55:29 +03:00
Merge branch 'development' into jh_home-offset
This commit is contained in:
stronnag
GitHub
commit
d39c8e2867
179 changed files with 459458 additions and 828 deletions
|
|
@ -58,7 +58,7 @@ The following parameters can be used to enable and configure this in the related
|
|||
|
||||
```
|
||||
// Define your esc hardware
|
||||
#if defined(STM32F3DISCOVERY) && !(defined(CHEBUZZF3))
|
||||
#if defined(STM32F3DISCOVERY)
|
||||
const escHardware_t escHardware[ESC_COUNT] = {
|
||||
{ GPIOD, 12 },
|
||||
{ GPIOD, 13 },
|
||||
|
|
|
|||
|
|
@ -1,10 +1,3 @@
|
|||
# Board - ChebuzzF3
|
||||
|
||||
The ChebuzzF3 is a daugter board which connects to the bottom of an STM32F3Discovery board and provides pin headers and ports for various FC connections.
|
||||
|
||||
All connections were traced using a multimeter and then verified against the TauLabs source code using the revision linked.
|
||||
|
||||
https://github.com/TauLabs/TauLabs/blob/816760dec2a20db7fb9ec1a505add240e696c31f/flight/targets/flyingf3/board-info/board_hw_defs.c
|
||||
|
||||
## Connections
|
||||
|
||||
|
|
|
|||
28
docs/Board - MatekF765-Wing.md
Normal file
28
docs/Board - MatekF765-Wing.md
Normal file
|
|
@ -0,0 +1,28 @@
|
|||
# Board - [MATEKSYS F765-Wing](https://inavflight.com/shop/s/bg/1557661)
|
||||
|
||||
|
||||
|
||||
## Specification:
|
||||
|
||||
* STM32F765 216MHz CPU
|
||||
* 2-8S LiPo support
|
||||
* 132A current sensor
|
||||
* OSD
|
||||
* BMP280 barometer
|
||||
* SD slot
|
||||
* 7 UART serial ports
|
||||
* 2 I2C
|
||||
* PDB for 2 motors
|
||||
* 12 outputs (10 DSHOT)
|
||||
* 8A BEC for the servos
|
||||
* 9V supply for FPV gear
|
||||
* Dual camera switcher
|
||||
|
||||
## Details
|
||||
|
||||
* For Matek F765-WING use `MATEKF765` firmware.
|
||||
* No need for SBUS inversion
|
||||
|
||||
## Where to buy:
|
||||
|
||||
* [Banggood](https://inavflight.com/shop/s/bg/1557661)
|
||||
|
|
@ -1,20 +1,17 @@
|
|||
# Flight controller hardware
|
||||
|
||||
The current focus is geared towards flight controller hardware that use the STM32F3, STM32F4, STM32F7 series processors. The core logic is separated from the hardware drivers, porting to other processors is possible.
|
||||
### Sponsored and recommended boards
|
||||
|
||||
Current list of supported boards can be obtained using [INAV release page](https://github.com/iNavFlight/inav/releases)
|
||||
These boards come from companies that support INAV development. Buying one of these boards you make your small contribution for improving INAV as well.
|
||||
|
||||
### Boards based on F1 CPUs
|
||||
Also these boards are tested by INAV development team and usually flown on daily basis.
|
||||
|
||||
These boards are no longer supported including Naze32, CC3D and all derivatives.
|
||||
| Board name | CPU Family | Target name(s) | GPS | Compass | Barometer | Telemetry | RX | Blackbox |
|
||||
|---------------------------|:----------:|:-------------------------:|:----:|:-------:|:--------------:|:---------:|:------------------------------:|:--------------------:|
|
||||
| [Airbot OMNIBUS F4 PRO](https://inavflight.com/shop/p/OMNIBUSF4PRO)| F4 | OMNIBUSF4PRO | All | All | All | All | All | SERIAL, SD |
|
||||
| [Airbot OMNIBUS F4](https://inavflight.com/shop/s/bg/1319176)| F4 | OMNIBUSF4 | All | All | All | All | All | SERIAL, SD |
|
||||
|
||||
### Boards based on F3 CPUs
|
||||
|
||||
These boards are supported, but not recommeneded for modern setups.
|
||||
|
||||
### Boards based on F4/F7 CPUs
|
||||
|
||||
These boards are powerfull and in general support everything INAV is capable of. Limitations are quite rare and are usually caused by hardware design issues.
|
||||
Note: In the above and following tables, the sensor columns indicates firmware support for the sensor category; it does not necessarily mean there is an on-board sensor.
|
||||
|
||||
### Recommended boards
|
||||
|
||||
|
|
@ -22,7 +19,31 @@ These boards are well tested with INAV and are known to be of good quality and r
|
|||
|
||||
| Board name | CPU Family | Target name(s) | GPS | Compass | Barometer | Telemetry | RX | Blackbox |
|
||||
|---------------------------|:----------:|:-------------------------:|:----:|:-------:|:--------------:|:---------:|:------------------------------:|:--------------------:|
|
||||
| [PARIS Sirius™ AIR3](http://www.multiwiicopter.com/products/inav-air3-fixed-wing) | F3 | AIRHEROF3, AIRHEROF3_QUAD | All | All | All | All | All | SERIAL |
|
||||
| [Airbot OMNIBUS AIO F3](http://shop.myairbot.com/index.php/flight-control/cleanflight-baseflight/omnibusv11.html) | F3 | OMNIBUS | All | All | All | All | All | SERIAL, SD |
|
||||
| [Airbot OMNIBUS AIO F4](http://shop.myairbot.com/index.php/flight-control/cleanflight-baseflight/omnibusf4v2.html)| F4 | OMNIBUSF4, OMNIBUSF4PRO | All | All | All | All | All | SERIAL, SD, SPIFLASH |
|
||||
| [Airbot F4 / Flip F4](http://shop.myairbot.com/index.php/flight-control/apm/airbotf4v1.html) | F4 | AIRBOTF4 | All | All | All | All | All | SERIAL, SPIFLASH |
|
||||
| [Matek F405-CTR](https://inavflight.com/shop/p/MATEKF405CTR) | F4 | MATEKF405 | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F405-STD](https://inavflight.com/shop/p/MATEKF405STD) | F4 | MATEKF405 | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F405-WING](https://inavflight.com/shop/p/MATEKF405WING) | F4 | MATEKF405SE | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F722 WING](https://inavflight.com/shop/p/MATEKF722WING) | F7 | MATEKF722SE | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F722-SE](https://inavflight.com/shop/p/MATEKF722SE) | F7 | MATEKF722SE | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F722-STD](https://inavflight.com/shop/p/MATEKF722STD) | F7 | MATEKF722 | All | All | All | All | All | SERIAL, SD |
|
||||
| [Matek F722-MINI](https://inavflight.com/shop/p/MATEKF722MINI) | F7 | MATEKF722SE | All | All | All | All | All | SPIFLASH |
|
||||
|
||||
It's possible to find more supported and tested boards [here](https://github.com/iNavFlight/inav/wiki/Welcome-to-INAV,-useful-links-and-products)
|
||||
### Boards documentation
|
||||
|
||||
See the [docs](https://github.com/iNavFlight/inav/tree/master/docs) folder for additional information regards to many targets in INAV, to example help in finding pinout and features. _Feel free to help improve the docs._
|
||||
|
||||
### Boards based on F4/F7 CPUs
|
||||
|
||||
These boards are powerful and in general support everything INAV is capable of. Limitations are quite rare and are usually caused by hardware design issues.
|
||||
|
||||
### Boards based on F3 CPUs
|
||||
|
||||
Boards based on F3 boards will be supported for as long as practical, sometimes with reduced features due to lack of resources. No new features will be added so F3 boards are not recommended for new builds.
|
||||
|
||||
### Boards based on F1 CPUs
|
||||
|
||||
Boards based on STM32F1 CPUs are no longer supported by latest INAV version. Last release is 1.7.3
|
||||
|
||||
### Not recommended for new setups
|
||||
|
||||
F1 and F3 boards are no longer recommended. Users should choose a board from the supported F4 or F7 devices available in the latest release.
|
||||
|
|
@ -80,6 +80,7 @@ After restoring it's always a good idea to `dump` or `diff` the settings once ag
|
|||
| `led` | configure leds |
|
||||
| `map` | mapping of rc channel order |
|
||||
| `motor` | get/set motor output value |
|
||||
| `msc` | Enter USB Mass storage mode. See docs/USB_Mass_Storage_(MSC)_mode.md for usage information.|
|
||||
| `play_sound` | index, or none for next |
|
||||
| `profile` | index (0 to 2) |
|
||||
| `rxrange` | configure rx channel ranges (end-points) |
|
||||
|
|
@ -425,8 +426,8 @@ A shorter form is also supported to enable and disable functions using `serial <
|
|||
| dyn_notch_q | 120 | Q factor for dynamic notches |
|
||||
| dyn_notch_min_hz | 150 | Minimum frequency for dynamic notches. Default value of `150` works best with 5" multirors. Should be lowered with increased size of propellers. Values around `100` work fine on 7" drones. 10" can go down to `60` - `70` |
|
||||
| gyro_stage2_lowpass_hz | 0 | Software based second stage lowpass filter for gyro. Value is cutoff frequency (Hz). Currently experimental |
|
||||
| pidsum_limit | 500 | A limitation to overall amount of correction Flight PID can request on each axis (Roll/Pitch/Yaw). If when doing a hard maneuver on one axis machine looses orientation on other axis - reducing this parameter may help |
|
||||
| yaw_p_limit | 300 | |
|
||||
| pidsum_limit | 500 | A limitation to overall amount of correction Flight PID can request on each axis (Roll/Pitch). If when doing a hard maneuver on one axis machine looses orientation on other axis - reducing this parameter may help |
|
||||
| pidsum_limit_yaw | 400 | A limitation to overall amount of correction Flight PID can request on each axis (Yaw). If when doing a hard maneuver on one axis machine looses orientation on other axis - reducing this parameter may help |
|
||||
| iterm_windup | 50 | Used to prevent Iterm accumulation on during maneuvers. Iterm will be dampened when motors are reaching it's limit (when requested motor correction range is above percentage specified by this parameter) |
|
||||
| rate_accel_limit_roll_pitch | 0 | Limits acceleration of ROLL/PITCH rotation speed that can be requested by stick input. In degrees-per-second-squared. Small and powerful UAV flies great with high acceleration limit ( > 5000 dps^2 and even > 10000 dps^2). Big and heavy multirotors will benefit from low acceleration limit (~ 360 dps^2). When set correctly, it greatly improves stopping performance. Value of 0 disables limiting. |
|
||||
| rate_accel_limit_yaw | 10000 | Limits acceleration of YAW rotation speed that can be requested by stick input. In degrees-per-second-squared. Small and powerful UAV flies great with high acceleration limit ( > 10000 dps^2). Big and heavy multirotors will benefit from low acceleration limit (~ 180 dps^2). When set correctly, it greatly improves stopping performance and general stability during yaw turns. Value of 0 disables limiting. |
|
||||
|
|
|
|||
|
|
@ -50,7 +50,7 @@ from another BEC. Just ensure that the GROUND is the same for all BEC outputs a
|
|||
|
||||
| Target | Pin | LED Strip | Signal |
|
||||
| --------------------- | ---- | --------- | -------|
|
||||
| ChebuzzF3/F3Discovery | PB8 | Data In | PB8 |
|
||||
| F3Discovery | PB8 | Data In | PB8 |
|
||||
| Sparky | PWM5 | Data In | PA6 |
|
||||
|
||||
If you have LEDs that are intermittent, flicker or show the wrong colors then drop the VIN to less than 4.7v, e.g. by using an inline
|
||||
|
|
|
|||
93
docs/USB_Mass_Storage_(MSC)_mode.md
Normal file
93
docs/USB_Mass_Storage_(MSC)_mode.md
Normal file
|
|
@ -0,0 +1,93 @@
|
|||
## Overview
|
||||
|
||||
iNav (after 2.3.0) offers USB MSC (mass storage device class) SD card and internal flash access, meaning you can mount the FC (SD card / internal flash) as an OS file system via USB to read BB logs (and delete them from an SD card).
|
||||
|
||||
When MSC mode is used with **internal flash** there are a few differences compared to **SD card** as it's a virtual file system:
|
||||
|
||||
* The file system is read-only. In order to delete logs it is necessary to erase the flash as usual (configurator, CLI or other tool).
|
||||
* The logs are presented as a single, consolidated file (`inav_all.bbl`) as well as individual logs (`inav_001.bbl` etc.).
|
||||
* Other informative files (e.g. `readme.txt`) may also exist in the virtual file system.
|
||||
|
||||
|
||||
## Usage
|
||||
|
||||
To put the FC in MSC mode:
|
||||
|
||||
* Enter the CLI
|
||||
* Enter the CLI command `msc` ; the FC will reboot
|
||||
* Close the CLI tool (`cliterm`, configurator etc.)
|
||||
* Wait for the device to be recognised as USB storage device by the operating system (may take some time, 10-15 seconds perhaps).
|
||||
* Copy files off the MSC mounted FC (sd card) (`cp`, file manager)
|
||||
* Dismount / eject the FC (sd card) card using the standard OS method
|
||||
* Power-cycle the FC to exit MSC mode.
|
||||
|
||||
## Performance
|
||||
|
||||
Internal flash is quite fast.
|
||||
|
||||
For an SD card, reading is quite slow, typically c. 340kBs, for example:
|
||||
|
||||
```
|
||||
####################
|
||||
## Using MSC mode ##
|
||||
####################
|
||||
# FC is automounted to /run/media/jrh/BBOX-QUAD by the OS
|
||||
$ rsync -P /run/media/jrh/BBOX-QUAD/LOGS/LOG00035.TXT /tmp/msclogs/
|
||||
LOG00035.TXT
|
||||
55,856,827 100% 339.15kB/s 0:02:40 (xfr#1, to-chk=0/1)
|
||||
```
|
||||
|
||||
```
|
||||
#########################
|
||||
## Using a card-reader ##
|
||||
#########################
|
||||
# SD Card is automounted to /run/media/jrh/BBOX-QUAD by the OS
|
||||
$ rsync -P /run/media/jrh/BBOX-QUAD/LOGS/LOG00035.TXT /tmp/sdclogs/
|
||||
LOG00035.TXT
|
||||
55,856,827 100% 19.26MB/s 0:00:02 (xfr#1, to-chk=0/1)
|
||||
```
|
||||
i.e c. 2.5 seconds for the card reader, 2 minutes 40 seconds for MSC (60 times slower). However, if the card is relatively inaccessible, this is a reasonable trade-off
|
||||
|
||||
## Comparison and Integrity
|
||||
|
||||
The same file (`LOG00035.TXT`, c 55MB) is copied by MSC to `/tmp/msclogs` and directly (SD Card Reader) to `/tmp/sdclogs`.
|
||||
|
||||
```
|
||||
$ cmp /tmp/{msc,sdc}logs/LOG00035.TXT
|
||||
# no differences reported ...
|
||||
```
|
||||
|
||||
```
|
||||
$ md5sum /tmp/{msc,sdc}logs/LOG00035.TXT
|
||||
7cd259777ba4f29ecbde2f76882b1840 /tmp/msclogs/LOG00035.TXT
|
||||
7cd259777ba4f29ecbde2f76882b1840 /tmp/sdclogs/LOG00035.TXT
|
||||
```
|
||||
You should also be able to run blackbox utilities (e.g. the iNav specific `blackbox_decode`) without errors on the files, e.g.
|
||||
|
||||
```
|
||||
$ blackbox_decode --stdout --merge-gps > /dev/null /tmp/msclogs/LOG00035.TXT
|
||||
Log 1 of 1, start 36:00.888, end 62:00.851, duration 25:59.963
|
||||
|
||||
Statistics
|
||||
Looptime 1006 avg 9.2 std dev (0.9%)
|
||||
I frames 48405 104.6 bytes avg 5062215 bytes total
|
||||
P frames 726064 69.2 bytes avg 50246994 bytes total
|
||||
H frames 380 10.0 bytes avg 3800 bytes total
|
||||
G frames 15674 21.4 bytes avg 334701 bytes total
|
||||
S frames 6198 33.0 bytes avg 204534 bytes total
|
||||
Frames 774469 71.4 bytes avg 55309209 bytes total
|
||||
Data rate 496Hz 35806 bytes/s 358100 baud
|
||||
|
||||
3 frames failed to decode, rendering 4 loop iterations unreadable. 4 iterations are missing in total (4ms, 0.00%)
|
||||
774472 loop iterations weren't logged because of your blackbox_rate settings (779980ms, 50.00%)
|
||||
```
|
||||
## Developer Notes
|
||||
|
||||
Providing MSC for a target requires that the `.mk` file includes in `FEATURES` the key `MSC` and at least one of `ONBOARDFLASH` and /or `SDCARD`.
|
||||
|
||||
For F4 and F7 targets, `USE_USB_MSC` is set unconditionally in `common.h`; if your target does not support blackbox logging to either SD card or internal flash, you should over-ride this in `target.h`
|
||||
```
|
||||
#ifdef USE_USB_MSC
|
||||
# undef USE_USB_MSC
|
||||
#endif
|
||||
```
|
||||
|
|
@ -1,106 +1,160 @@
|
|||
# Hardware debugging
|
||||
# Hardware Debugging
|
||||
|
||||
The code can be compiled with debugging information, you can then upload a debug version to a board via a JLink/St-Link debug adapter and step through the code in your IDE.
|
||||
Hardware debugging allows debugging the firmware with GDB, including most of its
|
||||
features that you can find while debugging software for a computer like setting
|
||||
breakpoins or printing variables or stepping through the code.
|
||||
|
||||
More information about the necessary hardware and setting up the eclipse IDE can be found [here](Hardware Debugging in Eclipse.md)
|
||||
Additionally, firmware can also be flashed directly either from the IDE or from GDB,
|
||||
significanly reducing the time required for the compile/flash/test cycle.
|
||||
|
||||
A guide for visual studio can be found here:
|
||||
http://visualgdb.com/tutorials/arm/st-link/
|
||||
## Required Hardware
|
||||
|
||||
This video is also helpful in understanding the proces:
|
||||
https://www.youtube.com/watch?v=kjvqySyNw20
|
||||
Although more complex and expensive solutions exists, an STLink V2 clone will let you
|
||||
use all the features of hardware debugging. They can be purchased on any of the typical
|
||||
Chinese sites.
|
||||
|
||||
## Hardware
|
||||
[ST Link V2 Clone](https://inavflight.com/shop/s/bg/1177014)
|
||||
[Original ST Link V2](https://inavflight.com/shop/s/bg/1099119)
|
||||
|
||||
Various debugging hardware solutions exist, the Segger J-Link clones are cheap and are known to work on Windows.
|
||||
Additionally, most nucleo boards from ST come with a brekable part that contains an
|
||||
STLink V2.1 or V3. These can also be used to debug an FC, but can be more difficult to
|
||||
source.
|
||||
|
||||
### J-Link devices
|
||||
To connect it a flight controller, you need to locate the SWDIO and SWCLK pins from the
|
||||
MCU. These correspond to PA13 (SWDIO) and PA14 (SWCLK). Be aware that not all manufacturers
|
||||
break out these pins, but a lot of them put them in small pads available somewhere.
|
||||
Connect SWDIO, SWCLK and GND from the FC to pins with the FC
|
||||
|
||||
Segger make excellent debuggers and debug software.
|
||||
TODO: Add pictures of several FCs with SWDIO and SWCLK highlighted.
|
||||
|
||||
The Segger J-Link GDB server can be obtained from here.
|
||||
## Required software
|
||||
|
||||
http://www.segger.com/jlink-software.html
|
||||
Besides an ARM toolchain, [OpenOCD](http://openocd.org) is required. Note that at the
|
||||
time of this writing, OpenOCD hasn't had a release in almost 3 years, so you might
|
||||
need to look for unofficial releases or compile from source.
|
||||
|
||||
#### Segger J-Link EDU EDU version, for hobbyists and educational use.
|
||||
[stlink](https://github.com/texane/stlink), while not strictly required, can be handy
|
||||
for quickly testing the SWD connection or flashing or erasing. To avoid ambiguities
|
||||
between the hardware and the software, the former will be referred as `ST Link` while
|
||||
we'll use `stlink` for the latter.
|
||||
|
||||
|
||||
Please, follow the installation instructions for your operating system.
|
||||
|
||||
https://www.segger.com/j-link-edu.html
|
||||
### Windows
|
||||
|
||||
#### USB-MiniJTAG J-Link JTAG/SWD Debugger/Emulator
|
||||
Install the Windows Subsystem for Linux, then follow the Linux instructions.
|
||||
|
||||
http://www.hotmcu.com/usbminijtag-jlink-jtagswd-debuggeremula%E2%80%8Btor-p-29.html?cPath=3_25&zenid=fdefvpnod186umrhsek225dc10
|
||||
### macOS
|
||||
|
||||
|
||||
Install [Homebrew](https://brew.sh) (a package manager) first.
|
||||
|
||||
##### ARM-JTAG-20-10 adapter
|
||||
To install OpenOCD type `brew install open-ocd --HEAD` in a terminal. Note the `--HEAD`
|
||||
command line switch.
|
||||
|
||||
https://www.olimex.com/Products/ARM/JTAG/ARM-JTAG-20-10/
|
||||
http://uk.farnell.com/jsp/search/productdetail.jsp?sku=2144328
|
||||
For stlink, use `brew install stlink`.
|
||||
|
||||
|
||||
### Linux
|
||||
|
||||
#### CJMCU-STM32 Singlechip Development Board Jlink Downloader Jlink ARM Programmer
|
||||
Install [Homebrew for Linux](https://docs.brew.sh/Homebrew-on-Linux), since versions
|
||||
provided by your distro's package manager might be out of date. Homebrew can cohexist
|
||||
with your existing package manager without any problems.
|
||||
|
||||
|
||||
Then, follow the same instructions for installing OpenOCD and stlink for macOS.
|
||||
|
||||
|
||||
## Hardware setup
|
||||
|
||||
http://www.goodluckbuy.com/cjmcu-stm32-singlechip-development-board-jlink-downloader-jlink-arm-programmer.html
|
||||
Connect SWDIO and SWCLK from the FC to pins with the same label on the ST Link. You must
|
||||
also connect one of the GND from FC to any of the GND pins to the ST Link. Note the
|
||||
following caveats:
|
||||
|
||||
- There are several ST Link clone types with different pinouts. Pay attention to the pin
|
||||
labels.
|
||||
- In some ST Link clones, some GND pins are actually floating and not connected to
|
||||
- anything. Use a multimeter to check the GND pins and use any of the valid ones.
|
||||
- Even if you're powering everything from the same computer, make sure to directly connect
|
||||
the grounds from the FC to the ST Link. Some FC/stlink combinations have a 0.1-0.2V
|
||||
difference between their grounds and if you don't connect them, stlink won't work.
|
||||
|
||||
### STLink V2 devices
|
||||
The FC can be powered by any power source that it supports (battery, USB, etc...), just
|
||||
make sure to not connect power from the ST Link (the pins labelled as 3.3V and 5V) to the
|
||||
FC if something else is powering it.
|
||||
|
||||
STLink V2 devices can be used too, via OpenOCD.
|
||||
Once you're wired everything, test the connections with a DMM before applying power. Then
|
||||
power both the FC and the stlink (the order doesn't matter) and run `st-info --probe`
|
||||
You should see something like:
|
||||
|
||||
#### CEPark STLink V2
|
||||
|
||||
|
||||
|
||||
http://www.goodluckbuy.com/cepark-stlink-st-link-v2-emulator-programmer-stm8-stm32-downloader.html
|
||||
```
|
||||
Found 1 stlink programmers
|
||||
serial: 0d0d09002a12354d314b4e00
|
||||
openocd: "\x0d\x0d\x09\x00\x2a\x12\x35\x4d\x31\x4b\x4e\x00"
|
||||
flash: 524288 (pagesize: 16384)
|
||||
sram: 131072
|
||||
chipid: 0x0431
|
||||
descr: F4 device (low power) - stm32f411re
|
||||
```
|
||||
|
||||
## Compilation options
|
||||
|
||||
use `DEBUG=GDB` make argument.
|
||||
INAV is compiled with debug symbols by default, since they're only stored in the locally
|
||||
generated `.elf` file and they never use flash space in the target. However, some
|
||||
optimizations like inlining and LTO might rearrange some sections of the code enough
|
||||
to interfere with debugging. All compile time optimizations can be disabled by
|
||||
using `DEBUG=GDB` when calling `make`.
|
||||
|
||||
You may find that if you compile all the files with debug information on that the program is too big to fit on the target device. If this happens you have some options:
|
||||
You may find that if you compile all the files without optimizations the program might
|
||||
too big to fit on the target device. In that case, one of the possible solutions is
|
||||
compiling all files with optimization (`make clean`, `make ...`) first, then re-save
|
||||
or `touch` the files you want to be able to step though and then run `make DEBUG=GDB`.
|
||||
This will then re-compile the files you're interested in debugging with debugging symbols and you will get a smaller binary file which should then fit on the device.
|
||||
|
||||
* Compile all files without debug information (`make clean`, `make ...`), then re-save or `touch` the files you want to be able to step though and then run `make DEBUG=GDB`. This will then re-compile the files you're interested in debugging with debugging symbols and you will get a smaller binary file which should then fit on the device.
|
||||
* You could use a development board such as an EUSTM32F103RB, development boards often have more flash rom.
|
||||
## Debugging
|
||||
|
||||
## OSX
|
||||
To run a debug session, you will need two terminal windows. One will run OpenOCD, while
|
||||
the other one will run gdb.
|
||||
|
||||
### Install OpenOCD via Brew
|
||||
Although not strictly required, it is recommended to set the target you're working on
|
||||
in `make/local.mk` (create it if it doesn't exist), by adding a line like e.g.
|
||||
`TARGET ?= SOME_VALID_TARGET`. This way you won't need to specify the target name in
|
||||
all commands.
|
||||
|
||||
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
|
||||
From one of the terminals, type `make openocd-run`. This will start OpenOCD and connect
|
||||
to the MCU. Leave OpenOCD running in this terminal.
|
||||
|
||||
brew install openocd
|
||||
From another terminal, type `make gdb-openocd`. This will compile the `.elf` binary for
|
||||
the current target and start `gdb`. From there you will usually want to execute the gdb
|
||||
`load` command first, which will flash the binary to the target. Once it finishes, start
|
||||
running it by executing the `continue` command.
|
||||
|
||||
### GDB debug server
|
||||
For conveniency, you can invoke `make gdb-openocd` with the environment variable `$LOAD`
|
||||
set to a non-empty string (e.g. `LOAD=1 make gdb-openocd`), which will run the `load`
|
||||
command and flash the target as soon as gdb connects to it.
|
||||
|
||||
#### J-Link
|
||||
From there on, you can use any gdb commands like `b` for setting breakpoints, `p` for
|
||||
printing, etc... Check a gdb tutorial for more details if you're not already familiar
|
||||
with it.
|
||||
|
||||
##### Windows
|
||||
### Rebuilding and reflashing
|
||||
|
||||
Run the Launch the J-Link GDB Server program and configure using UI.
|
||||
To rebuild, flash and rerun the binary after doing any modifications, recompile it
|
||||
with `make`, then press `control+c` to interrupt gdb. Halt the target by entering the
|
||||
gdb command `monitor reset halt` and then type `load` to flash it. gdb will notice the
|
||||
binary has changed and re-read the debug symbols. Then you can restart the firmware with
|
||||
`continue`. This way, you can very quickly flash, upload and test since neither OpenOCD
|
||||
nor gdb need to be restarted.
|
||||
|
||||
#### OpenOCD
|
||||
### ST Link versions
|
||||
|
||||
##### Windows
|
||||
|
||||
STM32F103 targets
|
||||
|
||||
"C:\Program Files (x86)\UTILS\openocd-0.8.0\bin-x64\openocd-x64-0.8.0.exe" -f interface/stlink-v2.cfg -f target/stm32f1x_stlink.cfg
|
||||
|
||||
STM32F30x targets
|
||||
|
||||
"C:\Program Files (x86)\UTILS\openocd-0.8.0\bin-x64\openocd-x64-0.8.0.exe" -f scripts\board\stm32f3discovery.cfg
|
||||
|
||||
##### OSX/Linux
|
||||
|
||||
STM32F30x targets
|
||||
|
||||
openocd -f /usr/share/openocd/scripts/board/stm32vldiscovery.cfg
|
||||
By default, the Makefiles will assume an ST Link v2, which is the version found in the
|
||||
popular and cheap clones. However, other versions are also supported. Just set the
|
||||
`STLINK` environment variable (either via command line or either via `local.mk`) to
|
||||
`1` or `2` or `2.1`, according to your hardware.
|
||||
|
||||
### Semihosting
|
||||
|
||||
Semihosting is an ARM feature that allows printing messages via the SWD connection.
|
||||
The logging framework inside INAV can output its messages via semihosting. To enable
|
||||
it, make sure you've deleted all generated files (e.g. `make clean`) and set the
|
||||
environment variable `$SEMIHOSTING` to a non-empty string, either via command line
|
||||
or via `local.mk`. Once you start the target, log messages will appear on the openocd
|
||||
terminal. Note that even with semihosting enabled, logging has be explicitely enabled
|
||||
via settings.
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 4.8 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
Loading…
Add table
Add a link
Reference in a new issue