YunTu Forum

6b0d1462-ed44-453f-b874-90fe74660d0e-image.png

上图是我每隔2s调用SDK中的LIN_DRV_SendWakeupSignal()在Canoe界面上显示，为什么canoe显示不是“wakeup Signal”而是"RcvError"，我需要再调用什么SDK函数吗？

使用的SDK名称：YTM32B1MC0_1_4_1

1. Overview

YUNTU MCAL(Microcontroller Abstract Layer) software package is designed by YTMicro AE team to support customers on AUTOSAR compliant application software development. The YUNTU MCAL is developed according to the AUTOSAR CP Release v4.4.0 standard.

1.1 Release Type

Major Release — This is a major version upgrade, representing a significant milestone in the YUNTU MCAL product lifecycle.
Status: Internal Released  |  Release Date: 2026-08-04

1.2 Release Highlights

The 3.0.0 release is the result of a comprehensive software architecture refactoring and quality upgrade program with the following goals:

ASPICE Process Compliance — Full software lifecycle activities conducted in accordance with ASPICE CL2 processes, covering SWE.1 through SWE.6, MAN.3, SUP.1,SUP.8, SUP.9 and SUP.10.

ASIL-D Functional Safety Qualification — The MCAL software package has been re-engineered to meet ISO 26262 ASIL-D functional safety requirements, including enhanced safety mechanisms and systematic capability.

Code Refactoring — A comprehensive code refactoring has been performed across all MCAL modules, with refinements to module architecture and detailed design. While the overall structure remains aligned with the AUTOSAR CP specification, customers should expect minor variations in module interfaces, internal design patterns, and configuration parameters compared to the 2.3.0 release.

Overall Quality Enhancement — Strengthened static analysis compliance (MISRA C:2012),HIS metrics improved test coverage to ASIL-D required levels, and systematic configuration and change management baselining.

Ned added-CddFmu — Supported FMU MCAL driver as complex driver.

1.3 Version Evolution Item Previous Release Current Release (3.0.0) Version 2.3.0 3.0.0 AUTOSAR CP v4.4.0 v4.4.0 ASPICE Capability N.A Level 2 ASIL Qualification QM ASIL-D

Important — Not a drop-in replacement: This release is the result of an extensive code refactoring across the MCAL stack to achieve ASIL-D qualification from a QM baseline. Due to the scale of architectural changes — including redesigned safety mechanisms, restructured module interfaces, updated configuration parameters, and new ASIL-D-specific requirements on integration .
Customers must perform a thorough impact analysis and managed upgrade before migrating:

Review all Breaking Changes listed in Section 6.1 and assess impact on the existing integration. Regenerate and re-validate MCAL configuration using YCT v3.2.0 or higher; configuration from 2.3.0 is not directly portable. Re-integrate and re-test all affected software components at unit, integration, and qualification levels. Conduct a project-specific safety impact analysis per ISO 26262 to confirm that the ASIL-D MCAL assumptions are valid and consistent with the system-level safety requirement.

2. Support Toolchains

YUNTU MCAL software package has been tested and validated with the following toolchains / IDEs:

2.1 Recommended Configuration Tool YCT (Yuntu Config Tool) v3.2.0 or higher version

Tip: YCT can be downloaded from YTMicro Account or updated from an installed older version.

2.2 Recommended IDE / Compilers IDE / Compiler Minimum Version Notes IAR v9.50 VSCode (Ninja + CMake + GCC/IAR) VSCode v1.80 Cross-platform build system GCC for ARM v10.3 Green Hills v2022.1.4 2.3 Recommended Debugger SEGGER J-LINK v9.2 or higher hardware + v6.96 or higher software/driver Required: YTM32BHA0x patch installed 3.Release List

The following list summarizes all functional changes, fixes, and new features introduced in this release compared to the previous release:

[Opt]-[CddUart]-[0] Optimize redundant YCT channel-count parameters and incorrect DMA channel validation rules for CddUart [New]-[CddI2c]-[2] Add CddI2c Pin Low Timeout event detection support [Fix]-[Icu]-[1] Fix missing ACMP1 option in HA0 Icu resource so interrupt control macros can be generated [Fix]-[Gpt]-[2] Fix Gpt not truly using the MCU clock source mapped by GptClockReferencePoint [Fix]-[Lin]-[2] Fix LinFlexD output-compare anomaly after bus ground recovery that may keep generating OC events [Fix]-[Pwm]-[2] Fix HA0 LQFP-144 Pwm MPWM channel support mismatch with actual package bonding pins [Fix]-[Fee]-[2] Add Fee cluster sector continuity validation in configuration [Opt]-[Port]-[1] Add XTAL/EXTAL pins into UnTouchedPortPin defaults to avoid crystal misconfiguration [Fix]-[Dio]-[2] Fix incorrect Dio Pin Mask for YTM32B1HA0 100-pin package [Fix]-[Platform]-[3] Fix GCC/GHS linker templates where section name equals memory region name causing wrong startup init size [Fix]-[Can]-[1] Fix incorrect default value of Can SSP [New]-[Mcu]-[2] Add Mcu module Errata Check items [Opt]-[Can]-[1] Add Full type support for Can HoH [Fix]-[Fls]-[2] Fix QSPI unable to access addresses above 64 Mbyte [Fix]-[Crypto]-[1] Fix Crypto Random async API that actually runs synchronously [Fix]-[Fls]-[2] Fix Fls ECC fault handling [Fix]-[Fls]-[1] Fix incorrect MemIf include between Fee and Fls [Fix]-[Can]-[1] Fix Can module code generation bug 4.Known Issues/Limitation

N.A

Annex Release list naming rule

Each release list item shall contain the following elements:

[Type] - [Sub-Type/Module] - [Effect_Level] [Brief/Overview Description][Reference/Details Link]

[Type]

Fix: Bug fixes / issue resolution Opt: Code performance optimization New: New feature implementation Demo: Example / demonstration project Doc: Documentation updates

[Sub-Type/Module]

MCAL: Mcu/Dio/Port/Can/Lin/Spi/Gpt/Pwm/Adc/Icu/Ocu/Fls/Fee/Platform/CddUart/CddSai/CddPpu/CddI2c/CddDma/CddTrg SafLib: CorTst/RamTst/FlsTst/IntTst/WdgTst/CrcTst/DmaTst/PpuTst/EfmTst/StkTst/EccTst/FmuTst GUI: the YCT XDM config GUI update for the MCAL/SafLib SW package, the YCT Vue config GUI update for the SDK/Middleware SW package(no code change/modification)

[Effect_Level]

0: No effect to the old version SW/project 1: Recommend but optional to update, for example the performance optimization 2: Must update for a specified SW module/components if the customer application used the related feature/functionality 3: Must update for a specified SW module/components if it is used 4: Must update if the SDK/MCAL/SafLib package is used

[Brief/Overview Description]

[Type] = Fix: Fixed the xxx issue/bug of the yyy HW/SW functionality/feature caused by condition [Type] = Opt: Optimized the performance of the yyy HW/SW functionality/feature [Type] = New: Added the new feature/functionality support of xxx [Type] = Demo: added/updated the demo project: brief description

[Reference/Details Link]

Errata: give out the detailed Errata number others: the link to the bug/issue analysis, it can be: Link to a YUNTU form post [if it is derived from a FAE/customer feedback] Link to a YUNTU form blog [if it is derived from a YUNTU form blog discussion] Link to a Feishu/Meegle project issue detail page Disclaimer

Copyright and Contact Information

img

YTMicro and its subsidiaries reserve the right to change, correct, enhance, modify and improve YTMicro products or this document at any time without notice. Before placing an order, purchasers should obtain and understand the latest relevant information about the products. YUNTU's products are sold according to YUNTU team and sales conditions at the time of order confirmation. Purchasers have the sole responsibility for selecting, choosing and using YUNTU products, and YUNTU has no responsibility for assisting purchasers in product design and application. YUNTU does not grant any express or implied license to any intellectual property herein. Resale of YUNTU products with information different from that described herein will make any warranty of YUNTU for such product void. YTMicro and YTMicro logo are trademarks of YTMicro. All other product or service names are the property of their respective owners. The information in this document replaces and supersedes any previously provided information in any prior version of this document. © 2020 - 2026 YUNTU Microelectronics co.,ltd. All rights reserved.

Contact us: Website: www.ytmicro.com.

1. 问题背景 1.1 问题描述 将 HA01 sMCAL3_0_0 Demo 编译后的 Hex 下载到 EVB 板中可以正常 Debug 调试，将 EVB 板断点再上电后代码无法运行，Attach 发现 PC 指针停在 0x0100_0000 - 0x0100_FFFF 的 ROM 段。

6c7c786d-a79c-4923-a07c-ade67d1fa143-image.png

1.2 解决方案 Platform -> SecureBootConfig 中勾选 Name，Name 变成绿色表示使能 SecureBootConfig

83a82238-8d91-47d8-985b-fc2b17d3a40a-image.png

Platform -> SecureBootConfig -> BvtConfiguration 中勾选 BvtYtlLinkRef，BvtYtlLinkRef 变成绿色表示使能，BvtYtlLinkRef 的值选择 “ytlink/P_FLASH/children/BVT/children/BVT/children/BVT/children/bvt_header”

b19f195d-df41-4723-92cc-8379c7adc18c-image.png

Platform -> SecureBootConfig -> BvtConfiguration -> BvtCoreConfig 中点击 Add，会生成 BvtCoreConfig_0

506bcc91-74dd-4779-ba02-4406e7fee97c-image.png

Platform -> SecureBootConfig -> BvtConfiguration -> BvtCoreConfig -> BvtCoreConfig_0 中勾选 CoreEnable；CoreAppEntrySource 的值选择 YT_LINK_REF；勾选 CoreAppEntryYtLinkRef 变成绿色表示使能；CoreAppEntryYtLinkRef 的值选择 “ytlink/P_FLASH/children/IVT”

887e4420-b3fa-4e4f-baab-2982fe41a90c-image.png

Platform -> SecureBootConfig -> SbGroupConfiguration 中勾选 SbGroupYtLinkRef 变成绿色表示使能；SbGroupYtLinkRef 的值选择 “ytlink/P_FLASH/children/BVT/children/BVT/children/BVT/children/sb_config_group”；勾选 SbSectionCfgYtLinkRef 变成绿色表示使能；SbSectionCfgYtLinkRef 的值选择 “ytlink/P_FLASH/children/BVT/children/BVT/children/BVT/children/sb_config_section”

925017c9-ea90-43d4-92bd-a7b9f0b4567a-image.png

修改后保存 YCT 工程，点击 Ctrl+S -> Generate 重新生成 MCAL 配置后，使用对应 IDE 重新编译下载后，掉电再上电后可以正常运行

db01fc55-6bfd-472e-969b-0add227b9c2a-image.png

1.3 背景说明 软件：HA01 sMCAL3_0_0 所有 Demo 硬件：EVB 板和客户 PCBA 2. 根因说明 HA01 sMCAL3_0_0 的 Platform 新增 SecureBootConfig 配置，Demo 默认是关闭的，SecureBootConfig 配置会影响 IDE 编译后生成的 BVT 段，若 SecureBootConfig 不配置，IDE 编译后是不生成 BVT 段的。

74d05a52-2b94-424c-8455-12af063a7294-image.png

没有 BVT 段 ROM 里的安全启动过不了，现象就是断电后在上电，代码不运行，attach 后 PC 指针停在 0x0100_0000 - 0x0100_FFFF 的 ROM 段，芯片卡在安全启动流程里无法正常运行

HA0 MCAL 2_3_0版本的ICU MPWM输入捕获不进中断bug

替换如下Icu_Lld_Mpwm.c中127行的for循环即可
code replacement.txt

1、例程将PFlash0作为A面，PFlash1作为B面，实现A/B Swap功能
SDK Demo例程：MD2x_Swap.zip

2、Demo功能介绍
FLASH_DRV_BootSwap(0)：通过内部闪存命令（0x30）执行Swap操作。
677e37d0-fd03-4438-831a-8adea93e76a0-image.png
Get_SwapInfo(&swapInfo)：读取EFM->STS寄存器，获取BOOT_INFO标志
e8f845e3-7c13-4b77-8106-b426b3047caf-image.png
89db2b5f-6f31-4605-83a5-0c151388941a-image.png
测试主逻辑：上电后读取BOOT_INFO标志，通过BOOT_INFO标志判断当前代码运行在哪个PFflash中，程序运行在PFlash0时点亮LED_A，运行在PFlash1时点亮LED_B。
9f5f5e3f-c9b8-4d5d-b25e-10531dd5805f-image.png

3、测试验证
使用J-Flash擦除芯片。
1b5d7f68-641e-4877-a9b8-35451b7aad88-image.png
将工程程序编译的文件加载到J-Flash中。
dfc46ef6-e9c6-4ef6-8127-eee0beb4d38e-image.png
对PFlash0进行烧录。
4cf326b5-5412-4681-8b03-e433d15be88c-image.png
在Edit->Relocate界面将烧录地址偏移到PFlash1中进行烧录。
8dc92d23-5327-4cd7-98b9-f5f541d8160f-image.png

4、重新上电运行程序
程序会在蓝灯和绿灯之间来回切换，绿灯代表程序在PFlash0中运行，蓝灯代表程序在PFlash1中运行。
affa5ffe-4192-4249-8473-ddf69c81cfd2-image.png
fa4e2037-9cbb-4806-bbdd-6d44814b68c7-image.png 、

用此SKILL, 方便AI操作yct_cli，对工程进行校验，测试，代码生成。

--- name: yct-cli description: >- Operate yct_cli to check, test, and generate code for YTMicro .yct projects (SDK, MCAL, MCAL_EB / EB Tresos). Use when the user mentions yct_cli, a .yct file, SDK, MCAL, MCAL_EB, EB Tresos, tresos_cmd, TRESOS_BASE, 校验, 测试, or 代码生成. --- # yct_cli 用此SKILL, 方便AI操作yct_cli，对工程进行校验，测试，代码生成。 `yct_cli` reads an existing `.yct` and the installed SDK or MCAL package. It does not create the `.yct`. Prefer `yct_cli` on PATH. From this repo, after `npm run cli:build`, use `node cli/cli.min.js`. ## Pick a command Read `project.type` from the `.yct`, then run that command. | Project type | Command | |---|---| | sdk | `yct_cli sdk` | | mcal | `yct_cli mcal` | | mcal_eb | `yct_cli mcal_eb` (alias of `mcal`) | Check with `-c`. Generate code with `-g`. Write the IDE project with `-P` (needs `-g` for MCAL and MCAL_EB). Compile a CMake project only after generate succeeds. ## Package root Resolution order: 1. `-p` install root 2. YT Config Tool settings file: Windows `%APPDATA%/yt_config_tool/config.json`, macOS `~/Library/Application Support/yt_config_tool/config.json`, Linux `~/.config/yt_config_tool/config.json`. Keys: `sdkPath`, `mcalPath`, `mcalEbPath` 3. `userDataPath` plus the project type directory Family folder under that root: - `sdkVersion` is `dev`, or settings `withoutVer` is true: `root/family` - otherwise: `root/family_sdkVersion` `--sdkVer` or `--mcalVer` overwrites the version in the `.yct` before that lookup. The family folder must contain `sdk.json`, `mcal.json`, or `mcal_eb.json`. CLI copies `env` entries from that config, including `TRESOS_BASE`, into the process environment when the variable is not already set. ## SDK Check: yct_cli sdk -i app.yct -c Generate the IDE project: yct_cli sdk -i app.yct -P --ide CMakeGCC `-c` validates the project. `-P` writes IDE files. `--ide` is one of `EWARM`, `KEIL`, `CMakeGCC`, `CMakeEWARM`, `CMakeKEIL`, `CMakeGHS`. | Flag | Required | Meaning | |---|---|---| | `-i, --input` | yes | `.yct` path | | `--verbose` | no | Verbose log | | `-c, --check` | no | Validate the `.yct` | | `-p, --path` | no | SDK install root | | `--ide` | no | IDE name, list above | | `-O, --optimization` | no | CMake optimization. Must be legal for the toolchain | | `--link` | no | Overwrite link file | | `--sdkVer` | no | Overwrite `sdkVersion`, for example `1_0_3` | | `-o, --output` | no | Output path. Default is the `.yct` directory | | `-n, --name` | no | Overwrite project name | | `-P, --project` | no | Also generate IDE files | ## MCAL Check, including stub modules: yct_cli mcal -i app.yct -c -S Generate code, copy MCAL sources, and write the IDE project: yct_cli mcal -i app.yct -g -P --copyMcal --ide CMakeGCC `-c` validates loaded modules. Stub modules such as `EcuM` and `CanIf` are skipped unless `-S`. `-g` generates config code, including `Mcal.h`. `-gm Mcu Dio` limits generation to those modules. `--copyMcal` copies MCAL sources. `-P` needs `-g`. ## MCAL_EB An MCAL_EB `.yct` has `type` `mcal_eb`. Module configuration lives in the EB Tresos project. `.yct` data is usually only `ytlink`. Tresos project directory: - `project.eb.projectPath` when set (absolute, or relative to the `.yct` directory) - otherwise the `.yct` directory That directory must contain `.prefs/pref_general.xdm`. Enabled modules and `GenerationPath` (often `output`) come from that file. `project.eb.stubModules` lists extra stub modules to pull in. Generate, then the IDE project is ready to compile: yct_cli mcal_eb -i Dio_Demo.yct -g -P --copyMcal --ide CMakeGCC - `-g` writes `board/Mcal.h`, or `project.generate.folder` - `--copyMcal` copies driver sources from `plugin.json` move entries. Required before a link. Without it the build only has Tresos `output` and `Mcal.h` - `-P` writes the IDE project. CMake toolchains also write `cmake/ebGenerate.cmake` - `--ide` uses the same list as SDK. Omit it when the `.yct` toolchain is already correct - `-c` does not run XDM validation on MCAL_EB Compile a CMake project from the `.yct` directory: cmake -G Ninja -DCMAKE_TOOLCHAIN_FILE=../cmake/gcc.cmake -B build cmake --build build Configure runs Tresos when `TRESOS_BASE` points at an install that contains `bin/tresos_cmd.bat` (Windows) or `bin/tresos_cmd.sh`. The YT Config Tool env value is written into `CMakeLists.txt`. Tresos C and H files stay in `GenerationPath`. CMake globs them together with the copied MCAL sources. `mcal_eb` is an alias of `mcal`. The `.yct` `project.type` selects the flow. Shared flags: | Flag | Required | Meaning | |---|---|---| | `-i, --input` | yes | `.yct` path | | `--verbose` | no | Verbose log | | `-c, --check` | no | Validate. MCAL_EB skips XDM validation | | `-S, --stub` | no | Include stub modules such as `EcuM` and `CanIf` | | `-p, --path` | no | MCAL or MCAL_EB install root | | `-g, --generate` | no | Generate config code, including `Mcal.h` | | `--copyMcal` | no | Copy MCAL sources from plugin move entries | | `--ide` | no | Same IDE list as SDK | | `-O, --optimization` | no | CMake optimization | | `-gm, --generateModule` | no | Only these modules, for example `-gm Mcu Dio` | | `--mcalVer` | no | Overwrite `sdkVersion`, for example `2_0_0` | | `-P, --project` | no | IDE files. Needs `-g` | | `-s, --save` | no | Write the loaded project back to the `.yct`, with a `.yct.bak` backup | CMake optimization values: - `CMakeEWARM`: `-On -Ol -Om -Oh -Ohs -Ohz`. Default `-Ol`. - `CMakeKEIL`: `-O0 -O1 -O2 -O3 -Oz -Omin -Ofast -Omax -Os`. Default `-O1`. - `CMakeGCC`: `-O0 -O1 -O2 -Os -Ofast`. Default `-O1`. - `CMakeGHS`: `-Omaxdebug -Omoredebug -Odebug -Ogeneral -Osize -Ospeed -Onone`. Default `-Ogeneral`.

云途MCU低功耗排查指南 前言

本指南面向云途 MCU 的低功耗调试，帮助开发者定位三类常见问题：无法进入目标模式、进入后反复唤醒，以及稳定休眠后电流仍偏高。排查按“确认测量条件—基准固件对比—按现象定位—修复验证”展开，可根据第 1 章的入口直接选择对应路径。

每次只改变一个因素，保留电流波形和修改前后的记录。具体模式、寄存器及 SDK 接口以对应型号和版本为准；代码集成示例见附录 A。

1. 排查入口与测量准备 1.1 先保证测量有效

接线、量程与供电

操作：电流表串入待测支路；先用可承受启动电流的量程，再选休眠量程。在 MCU 电源引脚附近核对实际电压。 判断与处理：读数不超量程，供电满足该模式要求；有压降或复位时，先处理仪表、线缆及供电。

运行阶段

操作：下载后复位运行，等待初始化、打印和启动延时结束，再读取休眠电流。 判断与处理：不能用初始化或断点暂停时的电流判断休眠功耗。MC0 基准工程延时为 10 秒，其他工程查对应源码。

调试及外部连接

操作：断开调试器、非必需 USB 和串口转换器，保留正常供电及必需唤醒连接，重新上电测量。 判断与处理：若断开后恢复正常，检查调试保持配置、信号电平及反向供电路径。

测量范围

操作：优先通过跳线或串联 0 Ω 电阻测量 MCU 支路；有多路电源时，明确覆盖的供电域。 判断与处理：整板、稳压器输入和 MCU 支路电流应分别记录；无法分测时，用同板、同条件对比。

波形与平均值

操作：读数跳动时用电流分析仪，或合适的采样电阻配合示波器记录波形，确保采样压降不影响供电。 判断与处理：区分运行、休眠、周期唤醒及重复启动；有周期唤醒时，同时记录平台电流和完整周期平均电流。

**开始前记录：**芯片及板卡版本、SDK／应用版本、固件、供电电压、温度、目标模式、保留时钟及唤醒源、测量位置、仪表及量程、外部连接状态。后续对比保持这些条件一致。

1.2 根据现象选择入口

电流接近运行平台，未见休眠平台

排查路径：查第 3.1 节的执行路径、模式配置和接口结果；应用复杂或原因不明时，用第 2 章做基准对比。

电流短暂降低后反复升高，或程序重启

排查路径：先记录唤醒／复位原因及波形，再按第 3.2 节排查触发源。

休眠平台稳定，但 MCU 支路电流偏高

排查路径：有适配固件时，先做第 2 章对比；再按第 3.3 节检查时钟、GPIO 及外围影响。

MCU 支路正常，整板电流偏高

排查路径：直接查第 3.3 节的外围与供电支路，不必逐项排查 MCU 进入流程。

**电流判断标准：**按数据手册中相同型号、供电、温度、模式和保留功能的条件比较。基准工程实测值用于定位差异；整板功耗还需计入稳压器及外围器件，不能直接套用 MCU 电流值。

2. 基准固件对比

应用配置复杂或原因不明时，用同板基准对比缩小范围。下载前确认型号、目标模式及引脚配置适配板卡；没有匹配固件时，按第 3 章对应现象继续排查。

2.1 选择匹配工程

配套测试文档提供 ELF、部分型号工程，以及 SIRC 开／关两组结果。选择时同时核对芯片型号、Flash 配置、目标模式和必须保留的唤醒功能。需要 SIRC 支撑唤醒时，不能为追求最低电流直接选用关闭 SIRC 的方案。

YTM32B1LD0

测试文档列出的模式：StandBy 板级测试注意事项：按对应型号栏目选择 ELF。

YTM32B1LE0

测试文档列出的模式：StandBy 板级测试注意事项：所列开发板测试需移除 RP1、RP2。

YTM32B1MC0

测试文档列出的模式：StandBy 板级测试注意事项：所列测试配置包含 PTA10（JTAG_TDO）上拉。

YTM32B1MD1、YTM32B1ME0

测试文档列出的模式：PowerDown 板级测试注意事项：按对应型号栏目选择 ELF。

YTM32B1HA0

测试文档列出的模式：PowerDown 板级测试注意事项：所列开发板测试需拔掉 J35、J36；另有 PTA10 上拉配置。

YTM32Z1LS0

测试文档列出的模式：StandBy、PowerDown 板级测试注意事项：区分两种模式的 ELF。

YTM32B1MD2

测试文档列出的模式：StandBy 板级测试注意事项：所列测试配置包含 PTA10（JTAG_TDO）上拉。

YTM32B1LE1

测试文档列出的模式：StandBy 板级测试注意事项：按对应型号栏目选择 ELF。

上述模式及板级条件来自本章末尾的配套文档，具体电流、ELF 和工程请查该文档。开发板跳帽与器件处理要求不直接套用于客户板，供电及引脚状态按实际型号手册和原理图确认。

2.2 同板下载与测量

先保存当前应用固件及测量记录，确认可以恢复；记录应用的休眠平台电流、平均电流和外围器件状态。

下载适配的基准 ELF；使用源码时，先核对工程配置并编译。可用 Ozone、支持对应 ELF 的 J-Flash，或已连接正确器件的 J-Link Commander。

下载后断开调试器及不需要的外部连接，重新上电；等待工程设定的启动延时结束及电流稳定，再记录结果。

恢复应用固件，在同一板卡、供电、温度、测量位置、量程和接线条件下复测；比较时同时核对模式、保留功能和外围器件实际状态。

J-Link Commander 已连接正确器件后，可参考以下命令。文件路径需替换为实际 ELF，下载能力取决于器件支持及 Flash 算法：

r h loadfile "C:/firmware/low_power.elf" r g

确认程序可启动后，退出连接、断开调试器，重新上电并按第 1.1 节测量。

根据结果选择下一步：

基准正常，应用偏高

可得到的判断：优先定位两套软件的差异，包括引脚电平对外围电路的影响。 下一步：未进入休眠查第 3.1 节；反复唤醒查第 3.2 节；平台偏高查第 3.3 节，逐项恢复业务功能。

基准与应用都偏高

可得到的判断：尚不能区分固件适配、模式、测量条件和硬件问题。 下一步：先复核匹配及实际进入状态，再分测 MCU 与外围支路，按第 3.3 节定位。

基准只降低了部分电流

可得到的判断：可能存在多个影响因素，或两套固件的模式、时钟、外围状态不同。 下一步：记录差值，逐项对齐条件；不能据此认定全部问题都来自 MCU 内部。

同一固件在不同板上有差异

可得到的判断：需结合供电、电源域、外围器件和引脚连接分析。 下一步：先统一测量条件，再交叉对比板卡及供电支路，不能仅凭整板差异判定芯片异常。 3. 按现象定位问题 3.1 无法进入低功耗

适用于启动延时结束后仍接近运行电流、未观察到目标休眠平台的情况。按以下顺序检查：

是否执行到休眠接口

操作：在 POWER_SYS_SetMode() 前设置断点确认路径，或用不影响板级功能的 GPIO 标记；检查初始化、通信等待、锁和延时。 判断与下一步：到不了接口，先处理阻塞；能到达，再查模式。测量前移除调试影响。

模式是否正确

操作：核对 POWER_SYS_Init() 的配置数组和 LOW_POWER_MODE 对应条目，确认目标模式及支持的唤醒源。 判断与下一步：模式参数是数组下标，不能跨工程照搬。配置不符时修正后复测。

接口是否报错

操作：单独保存 POWER_SYS_SetMode() 返回值。采用 AGREEMENT 策略时，检查回调是否拒绝切换；对应 SDK 可用 POWER_SYS_GetErrorCallback() 定位。 判断与下一步：报错按 SDK 返回码处理；返回成功仍需用波形及芯片状态确认是否保持休眠。

是否进入后立即退出

操作：脱离调试器观察波形，记录唤醒和复位原因，确认是否出现短暂低电流平台。 判断与下一步：短暂降低后上升查第 3.2 节；稳定但偏高查第 3.3 节；原因不明时做第 2 章基准对比。

**确认恢复方式：**唤醒后继续执行的模式，检查接口返回及恢复流程；通过复位启动恢复的模式，在启动早期记录复位／唤醒原因。不能用断点暂停电流判定休眠功耗。

3.2 反复唤醒或重启

**先记录原因，再清标志。**在初始化清除前，按手册规则保存唤醒／复位原因，结合波形区分预期唤醒、异常中断、看门狗及欠压复位。

**只保留一个可控唤醒源。**确认目标模式支持该来源，暂时关闭非必需的 RTC 闹钟、定时器和通信唤醒。异常消失后逐项恢复，找到重新引入问题的来源。

**核对任务及节拍。**暂停非必需采样、通信和定时任务；RTOS 按其低功耗流程处理系统节拍。唤醒周期与任务周期一致时，重点检查该任务及触发外设。

**排查持续触发。**先停止不需要的触发源，再按手册清除外设标志和待处理中断；核对唤醒引脚电平、边沿、上下拉及抖动。

**处理复位与调试影响。**看门狗按目标模式调整服务或配置；欠压先查供电和仪表压降。断开调试器重新上电，确认是否仍有异常。

**通过标准：**无非预期唤醒或复位，主动触发后原因与配置一致。业务要求的周期唤醒应保留，同时分别评估平台电流及完整周期平均电流；修复后执行第 4 章验证。

3.3 稳定休眠但电流偏高

先确认目标模式和保留功能一致，并排除非预期唤醒。有适配固件时，优先做第 2 章对比，再逐项检查：

时钟

操作：列出 RTC、定时器及通信唤醒依赖的时钟；核对目标模式保持选项、外设门控和时钟输出。每次只关闭一个不被必需功能使用的时钟或模块。 判断与下一步：电流下降时恢复该项复验，再结合手册确认原因；保留必需唤醒功能。无变化则查 GPIO。

GPIO

操作：按原理图逐脚核对：确认未使用的普通引脚才关闭不需要的数字通路、上下拉和中断；电源使能、待机及片选脚保持外围要求的电平；复位、调试及唤醒脚单独配置。 判断与下一步：测量实际电平，每次只改变一组引脚。变化可复现时，查上下拉对拉、悬空、外围误开启和反向供电。示例见附录 A。

外围器件

操作：停止 MCU 通信后，继续按器件手册设置 CAN／LIN 收发器和传感器的待机／休眠状态。板卡允许时逐项隔离外围供电或信号。 判断与下一步：记录使电流下降的支路，恢复原状态复验；MCU 停止通信不代表外围已休眠。

供电及跨电源域信号

操作：核对稳压器静态电流、使能和输入／输出测量位置；检查断电器件是否被信号线反向供电。隔离时保留 MCU 供电及必需控制电平。 判断与下一步：分别对比 MCU 与外围支路，结合两端电压及器件手册确认路径；整板差异不能直接证明芯片异常。

**通信引脚处理：**先停止新增发送并等待发送完成，再按 SDK 流程停用外设；仅在不依赖该通信唤醒、且外部电路允许时切换引脚状态。唤醒后恢复时钟、引脚及外设，并验证通信。

**通过标准：**MCU 支路满足对应条件下的规格／目标，外围状态正确，整板电流满足产品预算。找到原因后执行第 4 章；仍无法定位时，保留基准对比、支路测量及波形记录，继续做板卡交叉验证。

4. 修复验证与结果记录

完成以下验证后再关闭问题：

在相同条件下回退修改复现异常，再重新应用，确认电流和行为变化可重复。

多次上电，确认每次都能进入并保持目标模式，无非预期唤醒或复位。

逐一触发必需唤醒源，核对原因及恢复路径，并检查时钟、GPIO、通信和外围功能。

确认唤醒后还能再次休眠；记录平台电流，有周期唤醒时同时记录完整周期平均电流和周期长度。

按对应规格条件及产品预算验收，将测量条件、原因和修改内容与工程版本一起归档。

结果记录：

复现条件

内容：芯片及板卡版本、相关原理图、SDK／应用版本、固件、电压、温度、仪表、量程、测量位置和接线。

配置及现象

内容：目标模式、配置数组条目、保留时钟与唤醒源、外围状态、平台电流、周期平均电流及周期、波形和接口返回码。

定位及修复

内容：唤醒／复位原因、同板基准对比、单项修改及电流变化、最终原因、修复内容和回退复验结果。 附录 A：关闭未使用引脚与串口恢复示例

**适用范围：**以下为接口集成示例，适用于工程中具有相同 PINS、LINFlexD、WKU 和 POWER 接口的 SDK；引脚、实例和生成配置必须与实际芯片及板卡一致。已核对 MC0 基准工程中 PINS_DRV_Init()、POWER_SYS_SetMode() 的返回类型为 status_t；这不代表所有型号都具有示例中的 LINFlexD2 或相同引脚映射。

A.1 仅处理已确认未使用的普通引脚

LowPower_DisableUnusedPin() 是基于 SDK 接口封装的辅助函数，并非 SDK 自带接口。调用前应确认该脚不承担复位、调试、唤醒或外围控制功能，且板级电路允许关闭数字通路及上下拉。

static void LowPower_DisableUnusedPin(PCTRL_Type *pctrl, GPIO_Type *gpio, uint32_t pin) { PINS_DRV_SetPinIntSel(gpio, pin, PCTRL_DMA_INT_DISABLED); PINS_DRV_ClearPinIntFlagCmd(gpio, pin); PINS_DRV_DisableDigitalFilter(gpio, pin); PINS_DRV_SetPinDirection(gpio, pin, GPIO_INPUT_DIRECTION); PINS_DRV_SetPullSel(pctrl, pin, PCTRL_INTERNAL_PULL_NOT_ENABLED); PINS_DRV_SetMuxModeSel(pctrl, pin, PCTRL_PIN_DISABLED); } A.2 串口停用、进入低功耗及恢复

以下函数放入已完成初始化的工程中调用，替换原有“配置引脚保持、进入低功耗及恢复串口”的对应流程。前提是：工程确实使用 PTE12／PTD17 作为 LINFlexD2 TX／RX；唤醒源已配置且不依赖该串口；发送已经完成；外部电路允许 TX／RX 进入高阻；目标模式唤醒后从接口继续执行。若唤醒会复位启动，应在启动流程中恢复，不能照搬本函数的返回路径。

LOW_POWER_MODE 必须是本工程 POWER_SYS_Init() 配置数组中的目标下标。下面保留了原文的“先恢复引脚配置、再解除保持”顺序，集成时还须核对对应型号的引脚保持机制，以及时钟／电源恢复是否由 SDK 或回调完成。生成的引脚初始化数组应包含需要恢复的引脚。

static status_t LowPower_TestWithUartDisabled(void) { /* 调用前等待最后一次发送完成，并停止新增发送请求。 */ status_t deinitStatus = LINFlexD_UART_DRV_Deinit(2U); if (deinitStatus != STATUS_SUCCESS) { return deinitStatus; } LowPower_DisableUnusedPin(PCTRLE, GPIOE, 12U); LowPower_DisableUnusedPin(PCTRLD, GPIOD, 17U); WKU_DRV_SetPinIsolation(true); status_t powerStatus = POWER_SYS_SetMode( LOW_POWER_MODE, POWER_MANAGER_POLICY_AGREEMENT); /* 无论切换成功返回还是报错返回，均执行运行配置恢复。 */ status_t pinStatus = PINS_DRV_Init( NUM_OF_CONFIGURED_PINS0, g_pin_mux_InitConfigArr0); if (pinStatus != STATUS_SUCCESS) { /* 保持隔离；调用方进入板级恢复／错误处理流程。 */ return pinStatus; } WKU_DRV_SetPinIsolation(false); status_t uartStatus = UTILITY_PRINT_Init(); if (uartStatus != STATUS_SUCCESS) { return uartStatus; } /* 恢复完成后返回原低功耗结果，避免被初始化结果覆盖。 */ return powerStatus; }

**调用与判断：**调用方应保存返回值并处理错误，失败时停止后续正常打印及再次休眠，按板级策略恢复；调试时分别查看 deinitStatus、powerStatus、pinStatus 和 uartStatus。返回成功仍需按第 3.1、3.2 节确认实际进入与唤醒行为。该示例已做接口与文本核对，未替代目标工程的编译及实板验证。

**关于 10 秒延时：**配套文档的 YTM32B1MC0_Standby.zip 中，app/main.c 在 POWER_SYS_Init() 后调用 OSIF_TimeDelay(10000)，再进入低功耗。其他型号、版本和业务工程的等待时间应查各自源码。

YTM有没有型号可以实现这个功能：1.输出400Hz单频正弦波；2.输出400Hz叠加1600hz两种频率正弦波

我需要配置一个窗口看门狗，时钟需要不同于MCU的参考时钟，窗口时间可调，能选择启用软件锁或硬件锁，开启看门狗中断。
在B1ME05的MCAL环境下，以上需求是否可以通过YCT配置调整生成。
70670e3c-056b-4e08-8b3d-7a33845bf5ac-image.png

我们底层使用的是MCAL，现在要单独添加SENT模块，目前已使用sdk把sent模块配置完成了，已加入工程，我该如何进行初始化呢

请问下：在MC0中MCAL软件是否支持使用同一个FTM的不同通道用于PWM和ICU？？

b34f664e-ec41-4867-847a-c7c20e374c93-image.png

99d17fe9-9532-4efd-9294-cc63d58c85e8-image.png
如图所示，sent通道数量最大只能配置4个，我需要配置8个通道，该如何配置？还有要怎样确定配置的是SENT0还是SENT1.

1.先使用J-Flash烧录程序A后，断电重新上电的打印信息如下：
db762d25-85b0-4ab6-8a5a-8880c5499d13-image.png
2.使用J-Flash烧录程序B后，断电重新上电的打印信息如下：
5b7d9cd8-e5fe-4686-9c8d-89208c9321e1-image.png
3.使用Keil打开程序A的工程，点debug和Run后的打印信息，和程序B的打印信息一样。
6d85314c-0504-4ffb-969f-c5c730d44123-image.png
4afdc8ac-38f0-4fc6-836f-bb71ad7f1d6c-image.png
Keil配置的Flash地址从0开始
18e574c8-85eb-4f41-909d-abdea5f4aed3-image.png

728842da-9364-49eb-831b-b0acef27f95c-image.png
在MD14中 中断向量表地址与YT-LINK对应
a6a1ece1-8f89-442d-8bab-140034f6b6ee-image.png
在MD24中，中断向量表地址与YT-LINK并不对应，这是什么原因？

https://forum.ytmicro.com/post/4719

看了里面的代码，flash的操作函数使用uds_ip_api_t结构体进行封装了，目前使用MC0的fls_drv_bin_data.h进行测试，写入数据时一直复位重启，麻烦各位帮看一下是哪里有问题 用例中没有等待BUSY标识清除的接口，这个如何添加？
ba75089c-2818-47b8-9487-e58ea6080e48-image.png

e056e843-a974-4b27-9006-083b2a6b685d-image.png

ee3b698c-6331-479c-a349-9cc9397b57ac-image.png

174cec69-6413-4e86-aa87-099da378def0-image.png

4bb6ce50-1a27-4c4d-b234-96c20d84cce1-image.png

a128be6d-db4c-442d-95c8-a315b5c94b06-image.png

如上图，Init 时没有配置 MID 寄存器

关联 SDK 问题
https://forum.ytmicro.com/topic/186/sdk-etmr-pwm输出-没有设置mid值?_=1791963214109

YTM32B1LE15进入休眠模式时 ADC引脚电流倒灌，有没有什么好的解决办法？ 我想进入休眠模式之前把ADC口配置成开漏，退出休眠模式的时候重新配置ADC采集可行吗？LE15怎么配置gpio口开漏输出？

版本：
YCT：3.2.0
MCU：YTM32B1MD14

1. BootSwap和 DisJTAG 原理

BootSwap 用于切换芯片下一次启动使用的 Flash Bank，DisJTAG 用于关闭 JTAG/SWD 调试连接。

CUSNVR：CUS_NVR（Customized NVR）是芯片中存放客户定制信息的非易失性 Flash 区域，断电后数据保留，也用于保存调试口禁用和、Flash 地址保护和BOOT_SWAP配置。

BootSwap：A/B面切换。 芯片把BOOT_SWAP配置保存在 CUS_NVR 中。程序调用BootSwap命令后会更改CUSNVR中的BOOT_SWAP字节段的内容**（A面是0xFF，B面是0x5A）**来实现A/B面的切换

DisJTAG：决定是否允许调试器连接。 芯片把调试禁用配置同样保存在 CUS_NVR 中。程序通过更改CUSNVR中的Disable JTAG字节段的内容**（禁用是0x5A，启用是0xFF)**来实现调试口的状态。

芯片差异说明： MD14 的 BootSwap 与 DisJTAG 配置均保存在 CUS_NVR 中，因此对该区域的擦写可能影响另一项配置。L 系列不支持 BootSwap；M 系列的其他芯片将 BootSwap 配置保存在 BOOTNVR 中，DisJTAG 配置保存在 CUSNVR 中，两项配置位于不同的存储区域，不存在因共用同一配置区域而产生的擦写影响。下文的组合使用注意事项及处理方案仅针对 MD14 芯片。

2. BootSwap 和 DisJTAG 组合使用注意事项 2.1 B→A 切换时会清除原调试配置

《YTM32B1MD1x_RM》“Embedded Flash Module (EFM) → Boot Swap Operation”说明：
d05af363-c330-412d-a58e-b880e855f1b1-image.png
即：如果 STS [BOOT_INFO] 为 1，在执行 BOOT_SWAP 命令后，CUS_NVR 将会被擦除，这意味着用户需要重新配置 Disable_JTAG/SSWD 以及地址保护（Address_Protection）。

例如：当芯片所在程序位于B面且调试口的状态为禁用时，如果此时执行BootSwap命令此时CUSNVR中调试字节段上的内容0x5A（禁用调试口）会被擦除变成0xFF（启用调试口），调试口的状态就由禁用变成了启用

2.2 Disable Jtag可能误修改 Boot Swap

执行CUSNVR写入操作之前需要执行CUSNVR擦除操作，但CUSNVR擦除以扇区为单位，代码中的 FLASH_DRV_EraseNVR() 会清空整个 1 KB CUS_NVR 扇区。如果擦除后只向其中的调试字段写入 0x5A5A5A5A5A5A5A5A，其他原有配置就没有被保留下来。

所以代码需要通过“先保存、再修改、最后写回”处理这个影响：

将整个 1 KB 扇区读到 RAM 中。

在 RAM 中只修改调试字段，保留其余内容。

擦除 CUS_NVR，再将修改后的整个扇区写回。

在读取、擦除和编程均成功的条件下，这个流程可以保留调用时的其他配置。Enable_Jtag() 采用相同流程，只是把调试字段改为全 1。这说明组合使用时要处理好共享区域的擦写，不能仅凭一次擦除操作推断 BootSwap 一定会被改变。

3. BootSwap 和 DisJTAG 并行组合方案 程序执行流程介绍

程序主线如下：

Board_Init() → 初始化时钟、引脚、Flash 和 UART 日志 → 启用 GPIOB/GPIOC 中断 → 读取 BlockFlag()，打印当前 Bank 及 CTRL_OVRD → 进入无限循环： 根据 BlockFlag() 翻转绿灯或红灯，延时约 1 秒 → 处理 SwFlag：按当前 Bank 选择切换路径 → 处理 Jtag_log：执行共用的调试开关逻辑

Board_Init() 当前没有检查初始化调用的返回值。串口使用 LINFlexD2，115200、8 数据位、无校验、1 停止位。LED 每隔约 1 秒翻转一次，完整亮灭周期约为 2 秒；按键请求在主循环延时结束后处理。

3.2 同一份代码如何判断当前启动面

BlockFlag() 的定义为：

#define BlockFlag() ((EFM->STS & EFM_STS_BOOT_INFO_MASK) >> EFM_STS_BOOT_INFO_SHIFT) #define ABANKFlag 0 #define BBANKFlag 1

该宏读取 EFM->STS 的 BOOT_INFO 位，将返回值与 ABANKFlag、BBANKFlag 比较。初始化、按键中断、Flash 驱动、NVR 缓冲区和调试开关函数均共用；运行时按当前状态选择 LED 和切换处理。

BlockFlag() 返回值 应用状态约定 启动日志 LED 指示 SW2 切换方向 0，即 ABANKFlag 当前为 A 面 code run in pflash0! PB5，绿色 LED A→B 1，即 BBANKFlag 当前为 B 面 CODE RUN IN PFLASH1! PE8，红色 LED B→A 3.3 共用的按键中断与请求标志

SW2 为 PB2 上升沿中断，SW3 为 PC1 上升沿中断，Flash 操作均在主循环执行：
8c0889d8-cfc0-4635-9f1b-3bf131a2ec17-image.png
GPIOB_IRQHandler() 检查 PTB2 标志，设置 SwFlag=1 并清除引脚中断标志；GPIOC_IRQHandler() 对 PTC1 执行相同处理，设置 Jtag_log=1。Jtag_log 是调试开关请求标志，并非日志缓冲区。

3.4 共用的 Disable_Jtag 与 Enable_Jtag 3.4.1 Disable_Jtag：先读取整扇区，再修改并写回

当前禁用函数如下图所示：
021a06cd-c991-4927-acfa-ab507146d5ee-image.png

顺序 当前操作 作用 1 关闭全局中断 保护本次配置操作 2 写入 CUS_KEY=0x4DFF32 满足受保护 NVR 操作的 Key 条件 3 从 0x10000400 读取 0x400 字节 将当前整个 1 KB 扇区读入 CUS_NVR_data 4 修改数组索引 2、3 将偏移 0x08、0x0C 的两个 32 位字设为 0x5A5A5A5A（禁用调试口操作） 5 擦除 0x10000400 扇区 为重新编程准备目标区域 6 从扇区起始地址编程 0x400 字节 将修改后的整个缓冲区写回 7 恢复全局中断 结束本次配置操作

FEATURE_EFM_NVR_ARRAY_SECTOR_SIZE=0x400，缓冲区为 volatile uint32_t CUS_NVR_data[256]。逻辑修改范围是调试字段的 8 字节，实际读取和编程范围均为整个 1 KB 扇区。

在读取、擦除和编程均成功的条件下，函数可以保留CUSNVR中写保护和BootSwap配置

3.4.2 Enable_Jtag：将调试字段改为全 1 后整扇区写回

当前启用函数如下：
d4f58b9f-6df4-4bb9-be2a-6f6990abcb06-image.png

顺序 当前操作 作用 1 关闭全局中断 保护本次配置操作 2 写入 CUS_KEY=0x4DFF32 满足受保护 NVR 操作的 Key 条件 3 从 0x10000400 读取 0x400 字节 将当前整个 1 KB 扇区读入 CUS_NVR_data 4 修改数组索引 2、3 将偏移 0x08、0x0C 的两个 32 位字设为 0xFFFFFFFF（启用调试口操作） 5 擦除 0x10000400 扇区 为重新编程准备目标区域 6 从扇区起始地址编程 0x400 字节 将修改后的整个缓冲区写回 7 恢复全局中断 结束本次配置操作

在读取、擦除和编程均成功的条件下，函数可以保留CUSNVR中写保护和BootSwap配置

3.5 A 面处理：切换后直接复位，不重建调试禁用字段

435507b6-5c22-40b2-9146-eff17afa813b-image.png
SW2 请求进入主循环后，先执行 SwFlag=0。当 BlockFlag()==ABANKFlag 时，进入 A 面分支：

当前执行顺序为：

调用 FLASH_DRV_BootSwap(FLASH_INST)，其中 FLASH_INST=0。

若返回 STATUS_SUCCESS，立即调用 SystemSoftwareReset()。

若返回非成功，打印 Boot swap failed, status: ...。

失败路径随后仍会执行 SW2 处理末尾共用的 SystemSoftwareReset()。

A 面分支没有调用 Disable_Jtag()，切换后直接请求复位。 原因是正常 A→B 场景的切换前 BOOT_INFO=0，不满足手册所述“BOOT_INFO=1 时正常 Boot Swap 擦除 CUS_NVR”的条件，所以没有采用 B 面同样的正常切换补偿。

3.6 B 面处理：切换后按条件重建调试禁用字段，再复位

当 BlockFlag()==BBANKFlag 时，进入 B 面分支：
cb053016-e145-4553-b22e-b2c546435f53-image.png
当前执行顺序为：

调用 FLASH_DRV_BootSwap(0)。

切换命令返回后，判断 EFM->CTRL_OVRD==0x02。

条件成立时，调用共用的 Disable_Jtag()，重新写入调试禁用配置。

执行 SW2 处理末尾共用的 SystemSoftwareReset()。

B 面比 A 面多了一步“切换后、复位前重建调试禁用配置”。 这是因为 B→A 的切换前 BOOT_INFO=1，正常 Boot Swap 本身就会擦除 CUS_NVR。原禁用字段一旦被清除，直接复位就不能依靠原 NVR 值保持禁用状态，因此需要在切换命令结束后重新写入。

调用顺序是关键：

A 面：BlockFlag() == 0 → Boot Swap → 请求软件复位 B 面：BlockFlag() == 1 → Boot Swap（该状态下会擦除 CUS_NVR） → CTRL_OVRD == 0x02 时调用 Disable_Jtag() 读取切换后的整个扇区 修改调试禁用字段 擦除并整扇区写回 → 请求软件复位

如果先写禁用值，再执行会擦除 CUS_NVR 的切换命令，刚写入的值仍可能被清除。因此，补偿必须放在切换之后、复位之前。若切换返回时 CTRL_OVRD 不等于 0x02，当前 B 面分支跳过补偿，直接请求复位。

3.7 两条切换路径的差异汇总 对比项 A 面分支 B 面分支 入口条件 BlockFlag()==ABANKFlag，即 0 BlockFlag()==BBANKFlag，即 1 预期切换方向 A→B B→A 调用接口 FLASH_DRV_BootSwap(``0``) FLASH_DRV_BootSwap(0) 执行BootSwap命令下的 CUS_NVR 擦除条件 不满足 BOOT_INFO=1 条件 满足该条件，会擦除 切换后调试禁用补偿<br> 不调用 CTRL_OVRD==0x02 时调用 Disable_Jtag() 复位前操作 直接复位；失败时先打印错误 先判断并按条件补偿，再复位

两条路径共用请求标志、NVR 缓冲区、调试开关函数及 Flash 驱动。主要区别来自切换前的硬件 Bank 状态，以及 B→A 擦除 CUS_NVR 后增加的补偿操作。

3.7.1 补偿能恢复什么

Disable_Jtag() 会保留调用时读到的其他字段，但 B 面补偿中的读取发生在 Boot Swap 之后。若切换前的地址保护等配置已经被擦除，函数无法从切换后的 NVR 恢复其原值。

当前实现重建的是调试禁用字段，没有在切换前备份并恢复全部 CUS_NVR 配置。此外，补偿依据切换后的整个 CTRL_OVRD 值是否恰好为 0x02，没有提前保存调试策略，也没有只按 bit 1 掩码判断。

3.8 SW3 触发的调试开关：A/B 面共用相同流程

SW3 处理没有使用 BlockFlag() 分支，而是清除 Jtag_log 后，直接依据 CTRL_OVRD 执行相同逻辑：
11a0f5a9-6418-44b2-9f85-1ba7d65e4b47-image.png

条件 当前操作 CTRL_OVRD==0x00 打印禁用信息，调用 Disable_Jtag()，打印 SUCCESS，然后软件复位 CTRL_OVRD==0x02 打印启用信息，调用 Enable_Jtag()，打印 SUCCESS，然后软件复位 其他值 本次调试开关请求不执行配置操作或复位 4.测试验证 4.1 将程序烧录到 PFlash0 4.1.1 加载当前工程编译产物

将当前工程编译生成的镜像加载到 J-Flash。当前程序按逻辑地址 0x00000000 链接，可将同一编译产物分别烧录到两个物理 Bank，运行时由 BlockFlag() 区分当前启动面。
8167a51b-8439-4786-85bf-6685e53c9b87-image.png

4.1.2 擦除并烧录 PFlash0

在初始调试连接可用、Bank 映射为默认状态时，先完成芯片擦除，再把当前镜像烧录到 PFlash0。擦除和编程命令以当前 J-Flash 版本及配置为准。
986c1f07-a7e6-4696-8b3a-4917c4c1b432-image.png
e18a293c-3979-4c46-bb22-776367b9dc5f-image.png

4.2 将同一程序烧录到 PFlash1 4.2.1 设置地址偏移

《YTM32B1MD1x_DS》说明 PFlash 总大小为 512 KB，由两个 256 KB Block 组成；当前 SDK 定义的主 Flash 地址范围为 0x00000000～0x0007FFFF。

使用同一份按零地址链接的镜像。在默认 Bank 映射下，将镜像的烧录地址整体偏移 0x00040000，使其放入 PFlash1。这里修改的是烧录位置，不是将代码重新链接到 0x00040000；已处于交换映射时需先核对当前物理 Bank 对应关系。
467557d4-1472-42e7-8465-87d857d3d08d-image.png
e8bf99e9-673d-487c-9bc8-d34fb74ade71-image.png
3a069f19-3290-4126-8743-b4a3bc04c1aa-image.png

4.2.2 烧录 PFlash1

完成 PFlash1 烧录，保留已经写入 PFlash0 的程序，避免在此步骤再次整片擦除。
f41d13d2-8a3d-4f7f-9d67-e50c5db3a796-image.png

4.3 重新上电与基本操作

BlockFlag()==0 时，程序按 A 面逻辑运行，PB5 绿灯约每 1 秒翻转一次。

BlockFlag()==1 时，同一程序按 B 面逻辑运行，PE8 红灯约每 1 秒翻转一次。

按 SW2 切换执行BootSwap操作，切换程序的启动面。

按 SW3 切换调试口的状态。

串口打印数据如下：
2230ae93-589b-4c89-936e-543dd7f47dc3-image.png

项目代码

project.zip

我目前需要检测芯片中LDO1.1V（CPU核心和数字逻辑的电源），2.5V（XOSC、PLL和闪存电源），5V（VDD）的HVD检测，在YTM32B1ME05的MCAL环境下，是否可在YCT工程配置检测，或者芯片内部的某个寄存器可以读取吗？
d91becc5-8c13-45d8-b7cc-96522820bc0f-image.png