Skip to content

Add target ASMABAK (STM32F446RET6 custom flight controller)#11540

Open
Petrograd1 wants to merge 2 commits intoiNavFlight:maintenance-9.xfrom
Petrograd1:add-asmabak-target
Open

Add target ASMABAK (STM32F446RET6 custom flight controller)#11540
Petrograd1 wants to merge 2 commits intoiNavFlight:maintenance-9.xfrom
Petrograd1:add-asmabak-target

Conversation

@Petrograd1
Copy link
Copy Markdown

@Petrograd1 Petrograd1 commented May 6, 2026

Add target ASMABAK (STM32F446RET6)

Adds support for custom flight controller AsMaBak based on STM32F446RET6.

Hardware features:

  • MCU: STM32F446RET6 (HSE 8 MHz)
  • IMU: MPU9255 (SPI1)
  • Barometer: BMP280 (I2C1)
  • OSD: MAX7456 (SPI2)
  • Receiver: SBUS/IBUS on UART1
  • GPS on UART3
  • MSP on UART4
  • SmartAudio/Tramp on UART5
  • 4x DShot motors on TIM3 (PC6–PC9)
  • LED on PC0, Buzzer on PC15
  • USB VCP (DFU bootloader)

Build command:

make ASMABAK

@github-actions
Copy link
Copy Markdown

github-actions Bot commented May 6, 2026

Branch Targeting Suggestion

You've targeted the master branch with this PR. Please consider if a version branch might be more appropriate:

  • maintenance-9.x - If your change is backward-compatible and won't create compatibility issues between INAV firmware and Configurator 9.x versions. This will allow your PR to be included in the next 9.x release.

  • maintenance-10.x - If your change introduces compatibility requirements between firmware and configurator that would break 9.x compatibility. This is for PRs which will be included in INAV 10.x

If master is the correct target for this change, no action is needed.


This is an automated suggestion to help route contributions to the appropriate branch.

@qodo-code-review
Copy link
Copy Markdown
Contributor

Review Summary by Qodo

Add ASMABAK flight controller target (STM32F446RET6)

✨ Enhancement

Grey Divider

Walkthroughs

Description
• Add new flight controller target ASMABAK based on STM32F446RET6
• Configure MPU9255 IMU, BMP280 barometer, MAX7456 OSD on SPI/I2C
• Define 4x DShot motor outputs on TIM3 and gimbal servo outputs
• Configure 5 UARTs for receiver, GPS, MSP, VTX, and telemetry
Diagram
flowchart LR
  STM32F446["STM32F446RET6<br/>HSE 8MHz"] --> IMU["MPU9255 IMU<br/>SPI1"]
  STM32F446 --> BARO["BMP280 Barometer<br/>I2C1"]
  STM32F446 --> OSD["MAX7456 OSD<br/>SPI2"]
  STM32F446 --> MOTORS["4x DShot Motors<br/>TIM3"]
  STM32F446 --> SERVOS["4x Gimbal Servos<br/>TIM1/TIM2"]
  STM32F446 --> UART["5x UARTs<br/>RX/GPS/MSP/VTX"]
  STM32F446 --> IO["LED/Buzzer<br/>GPIO"]
Loading

Grey Divider

File Changes

1. src/main/target/ASMABAK/target.h ⚙️ Configuration changes +107/-0

Complete hardware configuration for ASMABAK target

• Define target board identifier and PWM output ports (8 max)
• Configure MPU9255 IMU on SPI1 with interrupt pin and magnetometer
• Setup BMP280 barometer on I2C1 bus
• Configure MAX7456 OSD on SPI2 with chip select pin
• Define 5 UART interfaces for SBUS/IBUS, GPS, MSP, VTX, and motor serial
• Configure 4 gimbal servo outputs and 2 GPIO pins for accessories
• Enable DShot ESC protocol and default features (OSD, telemetry, GPS, blackbox)

src/main/target/ASMABAK/target.h


2. src/main/target/ASMABAK/target.c ⚙️ Configuration changes +20/-0

Timer and motor output hardware definitions

• Define timer hardware mappings for 4 DShot motor outputs on TIM3
• Map gimbal servo outputs to TIM1 and TIM2 channels
• Configure motor pins PC6-PC9 and servo pins PA8, PB2, PB10, PA15

src/main/target/ASMABAK/target.c


3. src/main/target/ASMABAK/config.c Miscellaneous +6/-0

Target configuration function stub

• Create target-specific configuration function placeholder
• Reserve space for future ASMABAK-specific initialization code

src/main/target/ASMABAK/config.c


View more (1)
4. src/main/target/ASMABAK/CMakeLists.txt ⚙️ Configuration changes +1/-0

CMake build configuration for ASMABAK

• Define build configuration for ASMABAK target
• Specify STM32F405XG MCU macro and 8 MHz HSE clock

src/main/target/ASMABAK/CMakeLists.txt


Grey Divider

ⓘ You are approaching your monthly quota for Qodo. Upgrade your plan

Qodo Logo

@qodo-code-review
Copy link
Copy Markdown
Contributor

qodo-code-review Bot commented May 6, 2026

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

Grey Divider


Action required

1. target.h missing required includes ✓ Resolved 📘 Rule violation ≡ Correctness
Description
src/main/target/ASMABAK/target.h defines TARGET_IO_PORTD using BIT(2) but does not include the
header that defines BIT, so compilation depends on include order/transitive includes. This
violates the requirement that headers be self-contained and independently compilable.
Code

src/main/target/ASMABAK/target.h[R101-106]

+// IO порты
+#define TARGET_IO_PORTA         0xffff
+#define TARGET_IO_PORTB         0xffff
+#define TARGET_IO_PORTC         0xffff
+#define TARGET_IO_PORTD         (BIT(2))
+
Evidence
PR Compliance ID 1 requires headers to include the defining headers for every macro/type they use.
The new target.h uses BIT(2) in a public macro definition, while the BIT macro is defined in
common/utils.h, which target.h does not include—creating include-order dependence.

src/main/target/ASMABAK/target.h[101-106]
src/main/common/utils.h[50-58]
Best Practice: Learned patterns

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`src/main/target/ASMABAK/target.h` uses the `BIT()` macro (e.g., `#define TARGET_IO_PORTD (BIT(2))`) without including the header that defines it (`common/utils.h`). This makes the header non-self-contained and sensitive to include order.
## Issue Context
Compliance requires headers to be independently compilable and not rely on transitive includes. `BIT()` is defined in `src/main/common/utils.h`.
## Fix Focus Areas
- src/main/target/ASMABAK/target.h[101-106]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


2. Wrong MCU build target 🐞 Bug ≡ Correctness
Description
ASMABAK is built with target_stm32f405xg(), which hardcodes STM32F405xx compile definitions,
MCU_FLASH_SIZE=1024, and the stm32_flash_f405xg linker script. If the actual board MCU differs (per
PR description: STM32F446), this produces a binary compiled/linked for the wrong device/flash layout
and can fail to boot or overflow flash expectations.
Code

src/main/target/ASMABAK/CMakeLists.txt[1]

+target_stm32f405xg(ASMABAK HSE_MHZ 8)
Evidence
The target’s CMake macro selection directly controls MCU preprocessor defines and the linker
script/flash size assumptions used for the whole firmware image.

src/main/target/ASMABAK/CMakeLists.txt[1-1]
cmake/stm32f4.cmake[103-120]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ASMABAK` is built with `target_stm32f405xg(...)`, which sets `STM32F405xx`, `MCU_FLASH_SIZE=1024`, and uses the `stm32_flash_f405xg` linker script. For an STM32F446-based board this is the wrong MCU configuration and can generate an invalid binary.
### Issue Context
The MCU selection is centralized in `cmake/stm32f4.cmake`. `ASMABAK` currently reuses the F405 macro.
### Fix Focus Areas
- src/main/target/ASMABAK/CMakeLists.txt[1-1]
- cmake/stm32f4.cmake[103-140]
### What to change
- Add a new CMake function for STM32F446 (e.g. `target_stm32f446xe(...)` or similar) that:
- Defines the correct MCU macro (e.g. `STM32F446xx`) and correct `MCU_FLASH_SIZE` for the intended part.
- Uses an appropriate startup file and linker script for F446.
- Uses the correct SVD (`STM32F446` exists under `dev/svd`).
- Update `ASMABAK/CMakeLists.txt` to call the new STM32F446 function instead of `target_stm32f405xg(...)`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


3. Magnetometer disabled ✓ Resolved 🐞 Bug ≡ Correctness
Description
src/main/target/ASMABAK/target.h defines USE_MAG_MPU9250 but does not define USE_MAG, so the entire
compass subsystem is compiled out and the onboard AK8963 (via MPU925x) will not be usable. This
breaks MAG/heading features for this target.
Code

src/main/target/ASMABAK/target.h[R18-26]

+#define MPU9250_CS_PIN          PC5
+#define MPU9250_SPI_BUS         BUS_SPI1
+#define USE_IMU_MPU9250
+#define IMU_MPU9250_ALIGN       CW0_DEG        // подберите по ориентации платы (CW0/CW90/CW180/CW270)
+
+#define USE_MAG_MPU9250
+#define MAG_MPU9250_ALIGN       CW0_DEG
+
+#define GYRO_INT_EXTI_PIN       PC4            // прерывание от гироскопа (EXTI4)
Evidence
The compass implementation is guarded by USE_MAG, and reference MPU9250 targets define USE_MAG in
addition to USE_MAG_MPU9250.

src/main/target/ASMABAK/target.h[18-26]
src/main/sensors/compass.c[64-68]
src/main/target/CLRACINGF4AIR/target.h[47-55]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ASMABAK/target.h` enables the MPU925x magnetometer driver via `USE_MAG_MPU9250`, but does not define `USE_MAG`. The compass subsystem is wrapped in `#ifdef USE_MAG`, so magnetometer support is effectively disabled.
### Issue Context
Other MPU9250-based targets define `USE_MAG` (and sometimes `USE_MAG_MPU9250` explicitly).
### Fix Focus Areas
- src/main/target/ASMABAK/target.h[18-26]
- src/main/sensors/compass.c[64-68]
### What to change
- Add `#define USE_MAG` in `ASMABAK/target.h`.
- Optionally remove redundant `USE_MAG_MPU9250` (since `common_post.h` can define it when `USE_MAG_ALL` is used), but only if you also define `USE_MAG_ALL` and you want auto-selection.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


View more (1)
4. ADC channels not mapped ✓ Resolved 🐞 Bug ≡ Correctness
Description
ASMABAK defines RSSI_ADC_PIN/ADC_INSTANCE but does not define
RSSI_ADC_CHANNEL/VBAT_ADC_CHANNEL/CURRENT_METER_ADC_CHANNEL or ADC_CHANNEL_n_PIN mappings expected
by the ADC subsystem. With DEFAULT_FEATURES enabling FEATURE_VBAT and FEATURE_CURRENT_METER,
battery/current/RSSI ADC functions will default to ADC_CHN_NONE and not work.
Code

src/main/target/ASMABAK/target.h[R81-107]

+// ============== ADC (RSSI) ==============
+#define USE_ADC
+#define ADC_INSTANCE            ADC1
+#define RSSI_ADC_PIN            PC3                 // ADC123_IN13
+
+// ============== Дополнительно (опционально по ТЗ) ==============
+#define USE_LED_STRIP
+#define WS2811_PIN              PA15                // если есть LED-стрип (можно изменить)
+
+// Gimbal (подвес камеры) — PWM
+#define USE_SERVOS
+#define GIMBAL_PITCH_PIN        PA8                 // TIM1_CH1
+#define GIMBAL_ROLL_PIN         PB2                 // TIM2_CH4
+#define GIMBAL_YAW_PIN          PB10                // TIM2_CH3
+#define GIMBAL_ZOOM_PIN         PA15                // TIM2_CH1 (если нужно)
+
+// GPIO (навесные устройства)
+#define PINIO1_PIN              PC13
+#define PINIO2_PIN              PC14
+
+// IO порты
+#define TARGET_IO_PORTA         0xffff
+#define TARGET_IO_PORTB         0xffff
+#define TARGET_IO_PORTC         0xffff
+#define TARGET_IO_PORTD         (BIT(2))
+
+#define DEFAULT_FEATURES        (FEATURE_OSD | FEATURE_CURRENT_METER | FEATURE_VBAT | FEATURE_TELEMETRY | FEATURE_BLACKBOX | FEATURE_GPS)
Evidence
Core config maps ADC functions exclusively via *_ADC_CHANNEL macros (defaulting to ADC_CHN_NONE when
missing). Existing targets demonstrate the expected pattern using ADC_CHANNEL_n_PIN plus
VBAT/CURRENT/RSSI channel assignments.

src/main/target/ASMABAK/target.h[81-107]
src/main/fc/config.c[87-95]
src/main/fc/config.c[134-142]
src/main/target/AIRBOTF4/target.h[101-107]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`ASMABAK/target.h` defines `RSSI_ADC_PIN` and `ADC_INSTANCE`, but the firmware expects `ADC_CHANNEL_n_PIN` plus `VBAT_ADC_CHANNEL`, `CURRENT_METER_ADC_CHANNEL`, and `RSSI_ADC_CHANNEL` to route ADC functions. As-is, ADC functions will map to `ADC_CHN_NONE`.
### Issue Context
`fc/config.c` defaults `VBAT_ADC_CHANNEL`, `RSSI_ADC_CHANNEL`, and `CURRENT_METER_ADC_CHANNEL` to `ADC_CHN_NONE` when not defined.
### Fix Focus Areas
- src/main/target/ASMABAK/target.h[81-107]
- src/main/fc/config.c[87-95]
- src/main/fc/config.c[134-142]
### What to change
- Replace/augment the current ADC defines with the standard pattern:
- `ADC_CHANNEL_1_PIN`, `ADC_CHANNEL_2_PIN`, ... as needed.
- Set `VBAT_ADC_CHANNEL`, `CURRENT_METER_ADC_CHANNEL`, `RSSI_ADC_CHANNEL` to the correct `ADC_CHN_x` values.
- If the board does not have VBAT/current sensing wired, remove `FEATURE_VBAT` / `FEATURE_CURRENT_METER` from `DEFAULT_FEATURES` for this target.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Remediation recommended

5. WS2811 pin conflicts servo 🐞 Bug ≡ Correctness
Description
ASMABAK enables USE_LED_STRIP with WS2811_PIN=PA15 while also defining/using PA15 as a servo output
(GIMBAL_ZOOM on TIM2_CH1). Additionally, the target provides no timerHardware entry with
TIM_USE_LED, so WS2811 init can’t bind a valid LED timer and will not initialize the LED strip.
Code

src/main/target/ASMABAK/target.h[R87-96]

+#define USE_LED_STRIP
+#define WS2811_PIN              PA15                // если есть LED-стрип (можно изменить)
+
+// Gimbal (подвес камеры) — PWM
+#define USE_SERVOS
+#define GIMBAL_PITCH_PIN        PA8                 // TIM1_CH1
+#define GIMBAL_ROLL_PIN         PB2                 // TIM2_CH4
+#define GIMBAL_YAW_PIN          PB10                // TIM2_CH3
+#define GIMBAL_ZOOM_PIN         PA15                // TIM2_CH1 (если нужно)
+
Evidence
WS2811 initialization requires a timerHardware entry with TIM_USE_LED; ASMABAK’s timer table
contains only motor/servo usages. PA15 is declared for both WS2811 and servo, creating an
unresolvable resource conflict if both are intended to work.

src/main/target/ASMABAK/target.h[87-96]
src/main/target/ASMABAK/target.c[7-18]
src/main/drivers/light_ws2811strip.c[123-133]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`WS2811_PIN` is set to `PA15`, but `PA15` is also used as a servo output (`TIM2_CH1`) in `timerHardware[]`. The target also lacks any `timerHardware[]` entry flagged with `TIM_USE_LED`, which WS2811 needs to initialize.
### Issue Context
`ws2811LedStripInit()` looks up the timer by `WS2811_PIN` and requires a `TIM_USE_LED`-capable timer entry; otherwise it falls back to `timerGetByUsageFlag(TIM_USE_LED)` and returns early when none exist.
### Fix Focus Areas
- src/main/target/ASMABAK/target.h[87-96]
- src/main/target/ASMABAK/target.c[7-18]
- src/main/drivers/light_ws2811strip.c[123-133]
### What to change
- Pick one of:
- Move `WS2811_PIN` to a free timer-capable pin and add a corresponding `DEF_TIM(..., TIM_USE_LED, ...)` entry.
- Or keep WS2811 on `PA15` and change the gimbal zoom output to a different pin/timer.
- Or if LED strip is not present on the board, remove `USE_LED_STRIP` and `WS2811_PIN` from the target.
- Ensure there is exactly one viable timerHardware entry flagged `TIM_USE_LED` for WS2811.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools



Advisory comments

6. Missing EOF newlines 🐞 Bug ⚙ Maintainability
Description
All newly added ASMABAK files are missing a trailing newline, which can cause noisy diffs and
tooling issues (formatters/linters/patch applications).
Code

src/main/target/ASMABAK/target.h[107]

+#define DEFAULT_FEATURES        (FEATURE_OSD | FEATURE_CURRENT_METER | FEATURE_VBAT | FEATURE_TELEMETRY | FEATURE_BLACKBOX | FEATURE_GPS)
Evidence
The PR diff explicitly marks “\ No newline at end of file” on each added ASMABAK file.

src/main/target/ASMABAK/target.h[1-107]

Agent prompt
The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
New files under `src/main/target/ASMABAK/` are missing a trailing newline.
### Issue Context
The git diff marks `\ No newline at end of file` for these additions.
### Fix Focus Areas
- src/main/target/ASMABAK/CMakeLists.txt[1-1]
- src/main/target/ASMABAK/config.c[1-6]
- src/main/target/ASMABAK/target.c[1-20]
- src/main/target/ASMABAK/target.h[1-107]
### What to change
- Ensure each file ends with a single newline character.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools


Grey Divider

Qodo Logo

@Petrograd1 Petrograd1 changed the base branch from master to maintenance-9.x May 6, 2026 21:22
Comment thread src/main/target/ASMABAK/target.h
Comment thread src/main/target/ASMABAK/CMakeLists.txt Outdated
@@ -0,0 +1 @@
target_stm32f405xg(ASMABAK HSE_MHZ 8) No newline at end of file
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Action required

2. Wrong mcu build target 🐞 Bug ≡ Correctness

ASMABAK is built with target_stm32f405xg(), which hardcodes STM32F405xx compile definitions,
MCU_FLASH_SIZE=1024, and the stm32_flash_f405xg linker script. If the actual board MCU differs (per
PR description: STM32F446), this produces a binary compiled/linked for the wrong device/flash layout
and can fail to boot or overflow flash expectations.
Agent Prompt
### Issue description
`ASMABAK` is built with `target_stm32f405xg(...)`, which sets `STM32F405xx`, `MCU_FLASH_SIZE=1024`, and uses the `stm32_flash_f405xg` linker script. For an STM32F446-based board this is the wrong MCU configuration and can generate an invalid binary.

### Issue Context
The MCU selection is centralized in `cmake/stm32f4.cmake`. `ASMABAK` currently reuses the F405 macro.

### Fix Focus Areas
- src/main/target/ASMABAK/CMakeLists.txt[1-1]
- cmake/stm32f4.cmake[103-140]

### What to change
- Add a new CMake function for STM32F446 (e.g. `target_stm32f446xe(...)` or similar) that:
  - Defines the correct MCU macro (e.g. `STM32F446xx`) and correct `MCU_FLASH_SIZE` for the intended part.
  - Uses an appropriate startup file and linker script for F446.
  - Uses the correct SVD (`STM32F446` exists under `dev/svd`).
- Update `ASMABAK/CMakeLists.txt` to call the new STM32F446 function instead of `target_stm32f405xg(...)`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

Comment thread src/main/target/ASMABAK/target.h
Comment thread src/main/target/ASMABAK/target.h
@sensei-hacker
Copy link
Copy Markdown
Member

Hello. Are you a representative of the manufacturer?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants