SDK upgrade guide
Zephyr 3.6 to Zephyr 3.7: what needs attention
Migratorisk's knowledge base lists 14 documented changes between Zephyr 3.6 and Zephyr 3.7. 10 of them are rated likely to break code, configuration or builds that use them. Below is each change, what a scan also reviews on this path, and how to see which ones apply to your project.
Find which of these affect your firmware
Migratorisk scans your project on your own computer and reports only the changes your code, configuration and build actually touch. Your source code is not uploaded.
python -m pip install migratorisk migratorisk scan --project ./your-firmware --from zephyr-3.6.0 --to zephyr-3.7.0 --out report.html
Requires Python 3.12 or newer. Results are free and complete without sign-up; sharing a report with us is optional.
Set up the local scanOr answer a few questions insteadWhere the changes are
What changes between Zephyr 3.6 and Zephyr 3.7
Ordered by impact. Each item names the release that introduced it and links to the official source. A change only matters if your project uses what changed; the scan checks that.
Kconfig options CONFIG_MBEDTLS_MAC_MD4_ENABLED and 2 more were removed
The Kconfig options CONFIG_MBEDTLS_MAC_MD4_ENABLED, CONFIG_MBEDTLS_CIPHER_ARC4_ENABLED and CONFIG_MBEDTLS_CIPHER_BLOWFISH_ENABLED were removed because they are no more supported in Mbed TLS. Covers 3 names.
Kconfig options CONFIG_ESPI_SLAVE and 1 more were renamed
The macros ESPI_SLAVE_TO_MASTER and ESPI_MASTER_TO_SLAVE were renamed to ESPI_TARGET_TO_CONTROLLER and ESPI_CONTROLLER_TO_TARGET respectively to reflect the new terminology in eSPI 1.5 specification. Covers 2 names.
API ESPI_MASTER_TO_SLAVE was renamed
The macros ESPI_SLAVE_TO_MASTER and ESPI_MASTER_TO_SLAVE were renamed to ESPI_TARGET_TO_CONTROLLER and ESPI_CONTROLLER_TO_TARGET respectively to reflect the new terminology in eSPI 1.5 specification.
API uart_rpi_pico was removed
The Raspberry Pi UART driver uart_rpi_pico has been removed. Use uart_pl011 (arm,pl011) instead.
Custom board uses hardware model v1
Zephyr 3.7 introduces the overhauled hardware model v2 (board.yml, Kconfig.<board>, new board and SoC naming). Boards with a Kconfig.board file use the old model and must be ported.
Kconfig option CONFIG_CAN_AUTO_BUS_OFF_RECOVERY was renamed
The Kconfig CONFIG_CAN_AUTO_BUS_OFF_RECOVERY was renamed (and inverted) to CONFIG_CAN_MANUAL_RECOVERY_MODE, which is disabled by default. This Kconfig option enables support for the can_recover API function and a new manual recovery mode (see the next bullet).
Kconfig option CONFIG_MBEDTLS_MAC_ALL_ENABLED was removed
The CONFIG_MBEDTLS_MAC_ALL_ENABLED Kconfig option has been removed. Its equivalent is the combination of CONFIG_MBEDTLS_HASH_ALL_ENABLED and CONFIG_MBEDTLS_CMAC.
Kconfig option CONFIG_MODEM_CHAT_LOG_BUFFER was renamed
The CONFIG_MODEM_CHAT_LOG_BUFFER Kconfig option was renamed to CONFIG_MODEM_CHAT_LOG_BUFFER_SIZE.
Kconfig option CONFIG_SOC_IT82202_AX was renamed
ITE: Rename all SoC variant Kconfig options, e.g., CONFIG_SOC_IT82202_AX is renamed to CONFIG_SOC_IT82202AX. All symbols are renamed as follows: SOC_IT81202BX, SOC_IT81202CX, SOC_IT81302BX, SOC_IT81302CX, SOC_IT82002AW, SOC_IT82202AX, SOC_IT82302AX. And, rename the SOC_SERIES_ITE_IT8XXX2 to SOC_SERIES_IT8XXX2.
Kconfig option CONFIG_WS2812_STRIP_DRIVER was removed
The CONFIG_WS2812_STRIP_DRIVER kconfig option has been removed. Previously, when using CONFIG_WS2812_STRIP_SPI, CONFIG_WS2812_STRIP_I2S, CONFIG_WS2812_STRIP_GPIO, or CONFIG_WS2812_STRIP_RPI_PICO_PIO, one of them had to be selected with CONFIG_WS2812_STRIP_DRIVER, but this is no longer necessary. Please set each option directly.
Kconfig options CONFIG_DISABLE_SSBD and 1 more are deprecated
Kconfigs CONFIG_DISABLE_SSBD and CONFIG_ENABLE_EXTENDED_IBRS are deprecated. Use CONFIG_X86_DISABLE_SSBD and CONFIG_X86_ENABLE_EXTENDED_IBRS instead. Covers 2 names.
API z_arch_esf_t is deprecated
The named struct z_arch_esf_t is now deprecated. Use struct arch_esf instead.
Devicetree compatible zephyr,bt-hci is deprecated
A new HCI driver API was introduced and the old one deprecated. The new API follows the normal Zephyr driver model, with devicetree nodes, etc. The host now selects which driver instance to use as the controller by looking for a zephyr,bt-hci chosen property. The devicetree bindings for all HCI drivers derive from a common bt-hci.yaml base binding.
Kconfig option CONFIG_ARM64_ENABLE_FRAME_POINTER is deprecated
CONFIG_ARM64_ENABLE_FRAME_POINTER is deprecated. Use CONFIG_FRAME_POINTER instead.
What a scan of this path also reviews
Beyond the documented changes, Migratorisk reviews these upgrade risks for Zephyr projects on this path. Each one is reported only when the project shows the trigger.
Zephyr build logs need first-error triage after version changes
When it applies: Build logs often contain the highest-confidence migration breakage evidence.
Why it matters: First errors identify missing headers, renamed APIs, devicetree binding errors, and Kconfig failures.
What to do: Fix the first build error before chasing downstream compile or linker failures.
Zephyr devicetree and board files need target-version review
When it applies: Custom board and overlay files may depend on bindings or hardware model conventions from the source release.
Why it matters: Devicetree binding and board model changes commonly block Zephyr upgrades.
What to do: Validate custom board files, overlays, chosen nodes, and bindings against the target Zephyr release.
Zephyr Kconfig symbols need target-version review
When it applies: Project Kconfig files may contain symbols renamed, removed, or moved across Zephyr releases.
Why it matters: Zephyr version jumps often expose configuration drift before source changes compile.
What to do: Compare project Kconfig symbols against the target Zephyr release notes and build output.
Devicetree binding error in build log
When it applies: The build log reports a devicetree binding error.
Why it matters: Compatibles and bindings are renamed or split between releases; overlay and board errors must be fixed before source errors are meaningful.
What to do: Update overlays and board files to the target release bindings before addressing source errors.
Undefined Kconfig symbol in build log
When it applies: The build log reports an assignment to an undefined Kconfig symbol.
Why it matters: Zephyr renames and removes Kconfig options between releases, and Kconfig warnings abort the build before later errors appear.
What to do: Look up each undefined symbol in the migration guide of every release on the path and replace or remove it.
Zephyr source APIs need migration review
When it applies: Application source may use APIs whose signatures or headers changed between Zephyr releases.
Why it matters: Source API drift is common across major and multi-minor jumps.
What to do: Review source includes, driver APIs, Bluetooth APIs, kernel APIs, and subsystem-specific migration notes.
Zephyr west manifest revisions need target-version review
When it applies: Project manifests may pin modules that are incompatible with the target Zephyr release.
Why it matters: Module revisions, imports, and remotes can silently keep old APIs in the workspace.
What to do: Align manifest remotes, imports, and module revisions to the target Zephyr baseline.
Custom board needs the target Zephyr release devicetree and Kconfig review
When it applies: The project contains a custom board definition.
Why it matters: Board files track SoC devicetree, pinctrl, Kconfig and hardware model changes between releases.
What to do: Compare the custom board with a similar in-tree board in the target release (board.yml, chosen nodes, pinctrl, partitions, SoC Kconfig).
Verify OTA from the current field firmware
When it applies: The project uses MCUboot, so devices in the field keep their current bootloader after the upgrade.
Why it matters: The upgraded image must still be accepted by the existing bootloader (signature type, key, slot layout and image header).
What to do: Keep the signing key, signature type and slot layout unchanged, and test an OTA update from the current production image on hardware.
West manifest pins an older Zephyr revision
When it applies: west.yml pins a Zephyr or module revision.
Why it matters: The manifest must point at the target release, and pinned modules (HALs, MCUboot, Mbed TLS) must match it.
What to do: Update the zephyr revision in west.yml to the target tag, re-check pinned modules, then run west update.
Fix the first build error first
When it applies: The build log contains errors.
Why it matters: Later errors in an SDK upgrade are often caused by the first configuration or devicetree failure.
What to do: Resolve the first reported error, rebuild, and re-run the scan with the new build log.
VelocityCreate
Want us to handle the upgrade?
VelocityCreate can review your assessment, agree on the migration scope, and carry out the firmware changes and agreed verification. Discuss your deadline, hardware, and requirements with an embedded engineer.
Discuss my migrationBook a technical callThe initial discussion is free. Implementation is quoted separately.
Related upgrade paths
Generated from the rule catalog of Migratorisk 0.3.0. This is an automated summary of published SDK changes, not a review of your project, and it does not replace builds and device tests. How the scanner is validated.