YunTu Forum

我尝试为 openocd 添加 pflash 写入功能，根据手册和 demo 的描述，pflash 单次写入要 32 字节，目前每32字节都要根据这个流程处理一遍，使用 jlink 测试下载的速度大概在 1KB/s,

> flash write_image Hello_World.hex Padding image section 0 at 0x020000a0 with 1888 bytes Padding image section 1 at 0x02000bd4 with 44 bytes Padding image section 2 at 0x02004e68 with 24 bytes (bank write end alignment) wrote 20096 bytes from file Hello_World.hex in 13.192564s (1.488 KiB/s)

请问有没有提高速度的方向或者思路？

本文主要发布 OpenOCD 云途版 工具包：无需安装 Keil / J-Link 补丁包，使用 DAP-Link（CMSIS-DAP） 就能对 YTM32 系列芯片进行 烧录、擦除、校验和在线调试，也可以直接配合 VS Code + Cortex-Debug 使用。

下面以 YTM32B1HA01 开发板 + DAP-Link（SWD） 为例，演示从烧录到在 VS Code 里单步调试的完整流程，文中截图均为实板操作。

一、下载 工具包：openocd-ytmicro-20261024.zip（Windows 64 位，约 5.4 MB）
openocd-ytmicro-20261024.zip

解压即可使用，无需安装，也不依赖其他运行库。可以放在任意目录，下文假设解压到 D:\tools\openocd：

D:\tools\openocd\ ├── openocd.exe ├── YTMicro\ <- 各系列芯片的下载算法和器件信息 ├── interface\ <- cmsis-dap.cfg、jlink.cfg、stlink.cfg └── target\ <- ytmicro.cfg（所有云途芯片通用） 二、支持的芯片和调试器

芯片（DEVICE 取下面任意一个名字，不区分大小写）：

系列 DEVICE 名称 YTM32B1HA0 YTM32B1HA01 YTM32B1LD0 YTM32B1LD04 YTM32B1LE0 / LE1 YTM32B1LE04、YTM32B1LE05、YTM32B1LE14、YTM32B1LE15 YTM32B1MC0 YTM32B1MC03 YTM32B1MD1 / MD2 YTM32B1MD14、YTM32B1MD24 YTM32B1ME0 / ME1 YTM32B1ME05、YTM32B1ME15 YTM32Z1LS0 / LS1 YTM32Z1LS06、YTM32Z1LS16 YTM32Z1MC0 / MD0 / ME0 YTM32Z1MC03、YTM32Z1MD04、YTM32Z1ME05

PFlash 和 DFlash 都会自动识别，可直接烧录。

调试器（接口均为 SWD）：

调试器 配置文件 驱动 DAP-Link / CMSIS-DAP interface/cmsis-dap.cfg 免驱，插上即用（推荐） J-Link interface/jlink.cfg 需用 Zadig 把 J-Link 切换为 WinUSB 驱动 ST-Link interface/stlink.cfg 需用 Zadig 安装 WinUSB 驱动

提示：J-Link 切换为 WinUSB 后，SEGGER 官方软件（J-Flash、Ozone 等）就无法识别它了，需要时再在设备管理器中改回来。日常使用 OpenOCD 更推荐 DAP-Link。

三、命令行烧录（一条命令搞定）

打开 cmd，进入工程目录（固件路径相对于当前目录），执行：

D:\tools\openocd\openocd.exe -f interface/cmsis-dap.cfg -c "set DEVICE YTM32B1HA01" -f target/ytmicro.cfg -c "program build/HA0_Adc_Demo.elf verify reset exit"

参数说明：

-f interface/cmsis-dap.cfg：使用的调试器，换成 jlink.cfg / stlink.cfg 即可切换； -c "set DEVICE YTM32B1HA01"：芯片型号，必须写在 target/ytmicro.cfg 前面； -f target/ytmicro.cfg：云途芯片通用配置，所有型号都用这一个； program ... verify reset exit：烧录 → 校验 → 复位运行 → 退出。

实板运行结果（HA01 + DAP-Link，ADC Demo 约 14 KB，烧录 + 校验约 1 秒）：

命令行烧录

看到 ** Programming Finished ** 和 ** Verified OK ** 就表示烧录成功。

常用操作 rem 烧录 hex / elf（自带地址） openocd.exe -f interface/cmsis-dap.cfg -c "set DEVICE YTM32B1HA01" -f target/ytmicro.cfg -c "program app.hex verify reset exit" rem 烧录 bin 文件，需要指定起始地址（HA0 PFlash 起始地址为 0x02000000，其他系列请查手册存储器映射） openocd.exe -f interface/cmsis-dap.cfg -c "set DEVICE YTM32B1HA01" -f target/ytmicro.cfg -c "program app.bin 0x02000000 verify reset exit" rem 擦除第一个 flash bank（PFlash） openocd.exe -f interface/cmsis-dap.cfg -c "set DEVICE YTM32B1HA01" -f target/ytmicro.cfg -c "init; reset halt; flash erase_sector 0 0 last; exit" rem 调低 SWD 速率（线较长或连接不稳定时），单位 kHz，默认 4000 openocd.exe -f interface/cmsis-dap.cfg -c "set DEVICE YTM32B1HA01" -c "set ADAPTER_SPEED 1000" -f target/ytmicro.cfg -c "program app.elf verify reset exit" 四、在 VS Code 中调试（Cortex-Debug） 1. 准备 VS Code 安装扩展 Cortex-Debug（marus25.cortex-debug）； 安装 ARM GCC 工具链（需要其中的 arm-none-eabi-gdb.exe）。用云途 YCT 配置工具生成过 GCC 工程的话，工具链已经自带了； 工程能正常编译出 .elf。 2. 配置 .vscode/launch.json { "version": "0.2.0", "configurations": [ { "name": "HA0_Adc_Demo Debug", "type": "cortex-debug", "request": "launch", "cwd": "${workspaceFolder}", "executable": "${workspaceFolder}/build/HA0_Adc_Demo.elf", "servertype": "openocd", "device": "YTM32B1HA01", "serverpath": "D:/tools/openocd/openocd.exe", "configFiles": [ "interface/cmsis-dap.cfg", "target/ytmicro.cfg" ], "openOCDPreConfigLaunchCommands": [ "set DEVICE YTM32B1HA01" ], "svdFile": "${workspaceFolder}/.vscode/chip.svd", "runToEntryPoint": "main", "liveWatch": { "enabled": true, "samplesPerSecond": 4 } } ] }

需要按自己的情况修改的地方：

字段 说明 executable 编译生成的 elf 路径 serverpath openocd.exe 的实际解压路径（用 / 或 \\） configFiles 第一项为调试器，换 J-Link 就写 interface/jlink.cfg openOCDPreConfigLaunchCommands set DEVICE <芯片型号>，芯片型号写在这里，它会在 ytmicro.cfg 之前执行 svdFile 芯片 SVD 文件，用于查看外设寄存器（可选） armToolchainPath 如果 arm-none-eabi-gdb 不在 PATH 中，加上这一项指向工具链的 bin 目录，例如 "C:/xxx/gcc-arm-none-eabi-10.3-2021.10/bin"

launch.json 配置

3. 开始调试

按 F5（或点击 运行和调试 → 开始调试）。Cortex-Debug 会自动启动 OpenOCD、下载程序，并停在 main()。之后就可以正常设置断点、单步、查看变量：

断点调试

上图在 ADC 采样循环中设置了断点，左侧 Variables 中可以看到实时读到的 voltage 值。

配置了 svdFile 后，在 XPeripherals 面板中可以按位域查看外设寄存器，例如 ADC0 的 CFG0：

外设寄存器

五、注意事项 set DEVICE 一定要在 target/ytmicro.cfg 之前。命令行中放在 -f target/ytmicro.cfg 前面；VS Code 中写在 openOCDPreConfigLaunchCommands 里。 烧录会占用一段 SRAM 作为工作区，烧录完成后不会恢复其中的内容。正常的"烧录 → 复位运行"流程没有影响；如果在调试过程中写 flash 后不复位直接继续运行，需要注意这一点。 芯片处于低功耗模式、或 SWD 引脚被复用时，可能连不上，可以在复位状态下连接（按住复位键再启动 OpenOCD）。 六、常见问题 现象 处理方法 Device 'XXX' not found 芯片名写错了，对照第二节表格检查 Error: unable to find a matching CMSIS-DAP device 调试器没插好，或被其他软件（Keil、其他 OpenOCD 进程）占用 Error connecting DP: cannot read IDR 检查 SWD 接线和目标板供电；可尝试降低 ADAPTER_SPEED Not enough working area 可在 set DEVICE 后加 -c "set WORKAREASIZE 0x4000" 增大工作区 VS Code 提示找不到 gdb 在 launch.json 中加 armToolchainPath 七、性能参考

YTM32B1ME05，1 MB PFlash，DAP-Link SWD 4 MHz：

整片擦除：约 0.1 s 写入速度：约 160 KB/s 1 MB 完整镜像烧录 + 校验：约 9 s

使用中遇到问题，欢迎在本帖回复，附上芯片型号、调试器型号和 OpenOCD 的完整输出，方便我们定位。

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口开漏输出？