YunTu Forum

1 简介 1.1 此demo适配于YTM32B1LE05H0MLHT, YTM32B1MC03H0MLHT, YTM32B1MD14G0MLHT, YTM32B1ME05G0MLHT这四款封装为LQFP64的通用MCU，代码中引脚配置pintopin兼容； 1.2 Demo实物图

023d05ee-2dd2-459b-add4-1758c8d74582-image.png

1.3 电机实物图

三线为电机的三项，五线为传感器端，不使用建议用绝缘胶带包裹；
a8c25300-f3d2-4353-9425-c08d4563ebcc-image.png

1.4 此demo采样方式为三电阻相电流采样方案与单电阻母线电流采样方式； 2 demo配置步骤 2.1 MCU供电选择

MCU通过跳帽可选5V或3.3V电源域；
原理图
ba11ca4c-4e2b-4c89-adf6-595ae1e054f0-image.png
实物图，此时为5V供电；
b593f6a6-7f21-4705-a616-4b3daf6ec18d-image.png

2.2 采样电阻配置

原理图
94524827-3455-418d-8ab7-d62b8a483de6-image.png
2.2.1 将SJP1-1与SJP1-2用锡短接，将SJP2-1与SJP2-2用锡短接，配置为三项电阻采样；
实物图
94d71e68-bf40-4cc5-874c-ef43d25b688a-image.png

2.2.2 将SJP1-1与SJP1-2用锡短接，将SJP2-1与SJP2-2用锡短接，配置为单电阻母线电流采样；
实物图
dd545584-07b7-4672-9f90-2d56f207f76b-image.png

2.3 电机与demo连接

接线端口
49bbc0b0-cfa2-4373-beb0-f08b1261d994-image.png
注：接线不同导致转向不同；

2.4 Debug调试口连接

debug为SWD协议，板上端口为10pin SWD标准防呆端口；
125c72e7-9a34-4770-b988-da3e97b482d4-image.png

2.5 电源连接

此demo为12V系统，直流源供电
a7ca5450-8e39-4222-82e6-da22348584a7-image.png
注：使用直流源供电时，推荐限流5A防止系统因直流源限流不工作；

经过以上步骤后，即可上电调试了；

3 调试 3.1 电机参数测量

3.1.1 电阻与电感
测试仪器：LCR
选用LS-RS档，电平选择1V，测电阻时频率选择100Hz，测量电感时选择1KHz，测试之前最好进行开路和短路清零。接线方式为表笔与电机任意两相连接，需测三组(例：黄蓝，黄绿，蓝绿三组)；
3f6ab13d-059f-4e99-9211-c30c78439233-image.png
测得结果为线电阻与线电感，进行计算得到相电阻与相电感：
phase resistance = ((R1 + R2 + R3) / 3 ) / 2；
phase inductance = ((L1 + L2 + L3) / 3 ) / 2；
注：此电机为表贴式电机，Lq=Ld；

3.1.2 磁链常数测量
测试仪器：示波器
用示波器一个探头的地与信号分别连接电机任意两相，用绳子或其它工具缠绕电机转子，拉动使其旋转，示波器捕捉反向电动势，选取较为均匀的反向电动势波形；
a2f22800-76ff-47a9-8007-74904949316b-image.png
得到峰峰值Vpp和频率F，计算得到磁链常数：
KFI = Vpp / (4 * π * F * sqrt(3))；

3.1.3 极对数测量
有多种方式，这里介绍较为常用的一种方式，将电机任意两相连接直流源的正负，通电，电压自定义(不能过大，通常为1V)，电流500mA，然后用手转动转子，可以感觉出来有停顿，几次停顿即为几对极，若停顿感觉不明显可每次500mA递增电流后重复动作；

3.2 PEAK_VOLATGE

BUS电压采样分压电路
503c21ca-4e41-420c-b96c-5586162e87b8-image.png
根据原理图可得知可测量最大母线电压为 Vbusmax = VDDmcu * 105 / 5;

3.3 PEAK_CURRENT

3.3.1 电流采样运放电路
4e4a27c2-5428-4675-8d21-16326a4d112c-image.png

3.3.2 shunt电路
076e9d73-9ae7-44d0-9751-07f4f97d51a7-image.png
根据原理图可得知电流增益G = 10KΩ/2KΩ = 5, 采样电阻R = 0.05Ω，计算公式为：
Peak current = (0.5 * Vref / G) / R；

至此需测量参数测量结束，将测得参数填入代码；

4 YTM32B1XXX系列MotorDemo原理图

SCH_motor_driver_2025-04-22.pdf

5 MotorDemoFOC算法电流环时间对比

c75ba5d5-9a0b-4a1f-9c72-0dd6b73d29c1-image.png

6 YTM32B1XXX系列MotorDemo代码

MotorDemo.zip

7 YTM32B1XXX系列MotorDemo调速

demo可调速范围为300rpm/min - 1500rpm/min

7.1 CAN总线调速

CAN总线接线口实物图：
6a3379f9-e380-454b-995d-fac3350e1216-image.png
通过CAN总线可控制电机转速，停止，复位，观察电机速度
DBC文件为：
MotorCtrl.zip
控制电机demo报文ID为0x201
223447f6-cf0c-487e-b910-8dc67105f1cb-image.png
电机demo发送报文ID为0x200
139c0410-6de6-4fff-94d0-b5e032021470-image.png
注：电机温度与Bus总线电压报文待改板后更新

7.2 按键调速

每次按键调速为100rpm/min
0f593ccf-7ca2-48ad-9a6e-8089589a2fb0-image.png

AN0078_General_Mcu_Motor_Control_Guide_zh.pdf

下载uds_can_fbl_md14_release_20250530_2.zip并解压，使用YT Config Tool，Open Existing Projects uds_can_bootloader.yct，报401错误。
6d82028a-ca18-4371-a029-255fb03dac71-image.png

基于YTM32B1MD1-EVB开发板，使用ytm32b1md14-uds-can-fbl Demo, 1_3_1 SDK, 连接Keil调试，使用的TSProj工程进行升级，
TSMaster报错：从系统变量转化为字节数组失败，请问是什么原因
7989fc77-2fa6-4994-8af9-35375b420388-image.png 04942405-d32b-4c4a-bfbb-57dd7fb5ae29-image.png 9909f9e9-7095-4b33-9bc7-ba64561994c7-image.png

问题现象：同样的代码和同样的IAR配置：在LE14的64PIN demo板上面能正常下载运行，在20pin的芯片上面运行不起来

调试信息：

20PIN的memory内容：fd854e69-759d-4a25-b542-18155c4c33d2-image.png

0x00000000: 00 40 00 20 → 栈顶指针 = 0x20004000
0x00000004: a9 3d 00 00 → 复位向量 = 0x00003DA9

9c822312-8c13-46a9-b1ea-b23e73518176-image.png

SP 从 0x20004000 变为 0x20003FE0，正好减少了 0x20（32 字节）—— 这正是 HardFault 压栈 8 个通用寄存器 的大小（每个 4 字节）。
这证明：复位后 CPU 正确从 Flash 0x0 读取了栈顶指针（0x20004000），并初始化了 SP。

但 PC 却变为 0xFFFFFFFE，说明 CPU 从 地址 0x4 读取复位向量时，获得了一个无效值。Memory 窗口中看到 0x00000004 的内容为 0x3DA9（正确），但 CPU 实际读取到的内容并非此值。

请帮忙分析为啥

请教下YTM32B1ME0芯片，在IIC总线通信的时候开发板I2C波形图1.jpg 客户实际板子测出来的波形.jpg ，SDA会有锯齿波， 这个软件有改善方法吗，后续是否有风险，还请各位大神帮忙评估下?硬件上拉电阻2.2K，同时试过4.7K也一样，附上开发板的波形和实际测试板子的波形图。

1. 问题背景 软件：MD24 SDK 1_4_0_HF001 I2c_Master_Demo 硬件：MD24 EVB 背景描述： 客户反馈 MD24 I2C1 Master 接收超过 256 Byte 数据后出现接收异常的情况 实际测试最大只能接收 256 Byte，如果设置 rxSize 是 259 Byte，理论上 i2c master SCL 应该发送 259 Byte 的时钟波形，但实际只发送 3 byte 就结束了，259 Byte - 256 Byte = 3 Byte I2C_DRV_MasterReceiveData 断言判断对 rxSize 要求不大于 256 Byte

2e2776f2-6a05-4e37-b8d2-cd7ae47f2306-image.png

2. 原因分析 关于 I2C Master、Slave 一次性可以收发多少 Data 取决于 MDATA、SDATA 和 Functional Description。

be539550-ff81-4792-a710-ac955704274d-image.png
83821aca-9259-4c00-99f0-4fee7afbf05b-image.png

I2C Master Receive 的命令需要告知接收数据长度，即 I2C_DRV_MasterReceiveData API 的第三个参数 rxSize Receive(DATA + 1) 对应的就是 MDATA 寄存器的 RXDATA 位（7bit，最大值为 255），所以 I2C Master Receive 最大一次只能接收 256 Byte。 3. 结论 I2C 的操作命令只有对 Master Receive 的命令需要提前传入 MDATA.RXDATA Master Transfer、Slave Receive 和 Slave Transfer 都对 MDATA.TXDATA、SDATA.TXDATA 和 SDATA.RXDATA 无要求 综上所述，I2C Master Receive 一次性最大接收长度为 256 Byte。属于 IP 硬件限制，若需要 I2C Master Receive 超过 256 Byte，可以使用 GPIO 软解模拟 I2C 实现。 /* rxSize 的值，最大不能超过 256 */ I2C_DRV_MasterReceiveData(INST_I2C, rxBuff, rxSize, true);

SWSPI如何配置，没有找到相应的文件

正常的demo怎么修改偏移量从0x15800开始跑，目前只改了LD文件，发现初始化跑着进00地址了，一直卡在时钟初始化。是还需要修改其他什么地方嘛？2bfa6795-190b-48a6-aeb5-9f24311dea3b-222fa9ddd01fe4a678cade0ddf511de3.png

我想问一下Keil打开现有工程识别不到云途的芯片，用YT config tool工具generate生成的Keil文件也是识别不到云途的芯片，但是使用Keil新建一个空工程是有云途的各种型号芯片的，这是什么原因造成的

使用的例程代码和配置 只有 19200 波特率下通信正常，其他波特率例如9600 无法正常通信

5c56aee9-745e-4616-bb65-5f55e7e78360-image.png

Master :19200 Slave:19200
8ccb1556-301e-463d-9547-dd4e7a0aafc0-图片1.png

Master :19200 Slave:9600
71d9fcdf-a138-4c94-b0ee-70d8cd533c39-图片2.png

Master :9600 Slave:9600
9226b787-1eaa-4b43-b680-d8421d6a3407-image.png

如下两张图说明LIN_PHY没有问题：
61eeba4c-58d5-4eaa-832a-6ab04e557da9-image.png

f338fe74-75c0-4402-b232-ec56d2907e5a-image.png

下载uds_can_fbl_md14_release_20250530_2.zip并解压，使用TSMaster把uds_can_application.bin另存的tsbinary文件，与UDS_CanFbl_TsMaster路径下Demo自带的uds_can_application.tsbinary有差异，请问是什么原因，另外，请教一下tsbinary文件怎么解析？1bf82e14-2add-48e2-be36-2154b69e7712-image.png

大佬们好，客户在集成 YCT 生成的 MCAL 工程和第三方 AUTOSAR BSW 代码时遇到一个问题。
工程中有一些同名公共头文件，例如：

Std_Types.h
Compiler.h / Compiler_Cfg.h
ComStack_Types.h
Platform_Types.h

这些文件一部分来自 YCT/MCAL，另一部分来自BSW 工具生成。现在编译 XCP 模块时，出现 AUTOSAR 宏没有展开的问题，例如：

STATIC FUNC(void, XCP_CODE) Xcp_InitDaq(...)

编译时报错：
e83cf2ab-bae4-45f2-ae8b-bb6c76cf583f-image.png

想请教一下，有办法在Generate选择不生成某些文件吗

我在使用YTM32B1ME05的全模块demo工程时，手动修改代码中的喂狗模式宏，随后调用喂狗函数，但是会一直复位喂狗失败，需要怎么修改成周期喂狗的看门狗模式呢fc621572-cfb1-4541-abf0-3c266baa4a63-68b90d905f48b75258089a939f5fd4e7.png

YTM32B1LE05中CAN通信采样点配置83.33%，实际测试只有78.438%；
时钟使用的是外部12M时钟，配置波特率为500K正常；
3e4a23c8-05e8-4222-9036-16a4c86e3600-image.png
测试结果：
3742a996-6e33-4b9e-a387-fc759224e871-b9cc218fe82514176ecd6198bca66549.jpg

如题：
有基于SKD或者MCAL的ADC上下限阈值超限唤醒MCU（deepsleep）的demo吗？或文档

在MC03这，功能是一定可以实现的吧？

谢谢支持

一、客户及工程信息

MCU：YTM32B1ME05

二、问题现象

客户执行 A/B 升级时，两个方向表现不一致：
A 面切换到 B 面：

固件升级完成； 执行 Fls_WriteSwap()； “升级成功”CAN 报文可以正常发送； 复位后能够正常运行在 B 面。

B 面切换回 A 面：

固件升级及校验均正常； 执行 Fls_WriteSwap()； 专门用于提示“升级成功”的 CAN 报文没有发送出来； 同一时间其他后台周期 CAN 报文仍能正常发送，CAN 总线及控制器并未整体失效； 随后进行复位，MCU 可以正常运行在 A 面； 通过 BOOT_INFO 及程序版本确认，实际 A/B SWAP 已经执行成功。

三、客户诉求

请问如何进行进一步的排查方向.
确认两个方向的swap在软硬件上是否一致.

14ed4027-5e07-4d77-b75b-9999cd6a40f0-image.png

我在使用YTM32B1ME05芯片的板子时，有个设计需求如下：BT刷写过程中要求一直发送数据，同时flash要写入内存；但是按照我当前的使用方法，flash写入时需要while执行mainfunction等到flash写完，我理解在这个过程中，上位机下发的can数据中的内容我就无法接收并且存储下来，无法实现边收数据，边写入的要求，请问一下该芯片是否支持类似flash异步写入的功能，来实现flash写入时，不影响我周期任务中其他功能正常执行86dc5df1-5b00-431f-a070-46ac0d3d8fef-7cb68a5da13c60b3702133e8c4c3f47d.png

TRACE32 / Lauterbach 调试下载问题修改说明

日期：2026-07-13

工程目录：

C:\Users\xiangye\Desktop\trace32\YTMicro\ytm32b1ha0\testScript\Spi_Master_Demo_YTM32B1HA0 1. 问题现象

在 YTM32B1HA0 的 MCAL SPI demo 工程中，使用 Lauterbach TRACE32 下载/调试时出现异常，而使用 Ozone 调试可以正常运行。

过程中出现过的典型现象包括：

FLASH programming error around address ST:0x200FC10--0x200FC1F target reset detected DAP: DebugPortFail: CTRLSTAT=0x00000000 running (core power down)

其中 ST:0x200FC10 实际应理解为 0x0200FC10，该地址位于 PFlash0 的 .TEXT 段中，对应函数：

Spi_Lld_ReadRXBuffer() Mcal/Spi/src/Spi_Lld.c:1425

因此该问题不是普通 RAM 地址访问问题，而是 Flash 下载/运行后调试口连接稳定性问题。

2. 原因分析

本次问题主要分为两个阶段。

2.1 下载阶段问题

HA0 PFlash 的 program page 为 32 Byte。原 linker 配置中，部分 load segment 的起始地址或长度没有完全按照 32 Byte 对齐，可能导致 TRACE32 target flash algorithm 在烧写 ELF 时遇到非整页烧写场景，从而在 .TEXT 区域附近报 flash programming error。

2.2 运行后 DAP 掉线问题

Ozone 工程使用的是 SWD：

Project.SetTargetIF ("SWD")

原 TRACE32 脚本使用的是 JTAG：

SYStem.CONFIG DEBUGPORTTYPE JTAG

MCAL 程序运行后会执行：

Port_Init(&Port_Config);

该配置可能会重新配置部分非 SWD 的 JTAG 复用引脚，导致 TRACE32 使用 JTAG 时，在点击 Go 后调试口失联，出现：

DAP: DebugPortFail: CTRLSTAT=0x00000000 running (core power down)

将 TRACE32 调试接口切换为 SWD 后，与 Ozone 保持一致，问题消失。

3. 修改文件清单

本次主要修改以下文件：

board\yt_linker.ld cmake\targets\GENERATED_SDK_TARGET.cmake ..\ytm32b1ha0-debug.cmm

其中 ytm32b1ha0-debug.cmm 位于 testScript 目录：

C:\Users\xiangye\Desktop\trace32\YTMicro\ytm32b1ha0\testScript\ytm32b1ha0-debug.cmm 4. 具体修改内容 4.1 修改 board\yt_linker.ld

新增 Flash page 对齐宏：

FLASH_PAGE_SIZE = 32;

对 Flash 中的 loadable section 结尾进行 32 Byte 对齐：

.BVT .IVT .NC_TEXT .TEXT .ARM

对带 ROM copy image 的 RAM section 进行 32 Byte 对齐：

.CODE_RAM .D_DATA .NC_DATA .DATA_RAM

重点修改包括：

CODE_RAM_rom_start = ((CODE_RAM_rom_start_not_align + FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE) * FLASH_PAGE_SIZE; D_DATA_rom_start = ((D_DATA_rom_start_not_align + FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE) * FLASH_PAGE_SIZE; NC_DATA_rom_start = ((NC_DATA_rom_start_not_align + FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE) * FLASH_PAGE_SIZE; DATA_RAM_rom_start = ((DATA_RAM_rom_start_not_align + FLASH_PAGE_SIZE - 1) / FLASH_PAGE_SIZE) * FLASH_PAGE_SIZE;

并对 section 本身增加对齐：

.CODE_RAM ALIGN(FLASH_PAGE_SIZE) : AT(CODE_RAM_rom_start) .D_DATA ALIGN(FLASH_PAGE_SIZE) : AT(D_DATA_rom_start) .NC_DATA ALIGN(FLASH_PAGE_SIZE) : AT(NC_DATA_rom_start) .DATA_RAM ALIGN(FLASH_PAGE_SIZE) : AT(DATA_RAM_rom_start)

修改目的：

保证 ELF 中 Flash load segment 的起始地址按 32 Byte 对齐； 保证 Flash load segment 的 FileSiz 按 32 Byte 对齐； 避免 TRACE32 flash algorithm 处理非整页烧写时失败。

修改后确认的 ELF Program Header 关键段如下：

LOAD 0x02000000 size 0x000a0 LOAD 0x02000800 size 0x003e0 LOAD 0x0200c000 size 0x05d20 LOAD 0x02011d20 size 0x00020 LOAD 0x02011d40 size 0x003c0

这些段的起始地址和长度均满足 32 Byte 对齐。

4.2 修改 ytm32b1ha0-debug.cmm 4.2.1 降低调试口时钟

由原先较高 JTAG 时钟调整为：

SYStem.JtagClock CTCK 2MHz

说明：TRACE32 命令名仍为 JtagClock，但这里用于配置调试口访问速度。降低速度可以提高 reset / flash / run 阶段 DAP 访问稳定性。

4.2.2 调试接口由 JTAG 改为 SWD

原配置：

SYStem.CONFIG DEBUGPORTTYPE JTAG

修改为：

SYStem.CONFIG DEBUGPORTTYPE SWD

修改目的：

与 Ozone 工程保持一致； 避免 MCAL Port_Init() 运行后复用 JTAG 相关引脚导致 TRACE32 失联； 解决点击 Go 后出现 DAP: DebugPortFail: CTRLSTAT=0x00000000 的问题。 4.2.3 增加看门狗处理

脚本中增加 WDG 解锁和配置操作：

&WDG_SVCR = 0x401A8000 &WDG_CR = 0x401A8004 &WDG_TOVR = 0x401A800C

并执行相关 Data.Set 操作。

修改目的：

避免 TRACE32 flash algorithm 运行过程中目标芯片被看门狗复位； 减少下载过程中出现 target reset detected 的概率。 4.2.4 Flash algorithm 装载地址恢复为原厂推荐区域

当前配置：

FLASH.TARGET 0x20020000 0x20021000 0x1000 ~~~~\..\flashAlgorithm\ytm32b1ha0.bin

修改目的：

使用 OCRAM 区域执行 flash algorithm； 避免与 DTCM / stack / application RAM 区域冲突。 4.2.5 下载文件改为当前 build ELF

当前配置：

FLASH.Program.ALL Data.LOAD.Elf ~~~~\Spi_Master_Demo_YTM32B1HA0\build\Spi_Master_Demo_YTM32B1HA0.elf FLASH.Program.off

修改目的：

使用修正后的 linker 生成的 ELF； 让 TRACE32 按 ELF Program Header 进行 Flash 下载； 避免旧 HEX 文件或非当前 build 产物影响验证结果。 4.3.6 烧录后重新加载符号并设置入口

新增：

Data.LOAD.Elf ~~~~\Spi_Master_Demo_YTM32B1HA0\build\Spi_Master_Demo_YTM32B1HA0.elf /NoCODE Register.Set MSP STACK_end Register.Set PSP STACK_end Register.Set PC Reset_Handler

修改目的：

烧录结束后只加载符号，不重复写 Flash； 将 MSP / PSP 设置到应用栈顶； 将 PC 设置到 Reset_Handler； 保证点击 Go 后程序从应用启动入口运行，而不是从 TRACE32 flash algorithm 的上下文继续执行。 4.3.7 关闭非必要窗口操作

注释：

;per.view ~~~~\..\ytm32b1ha0.per ;Data.List

修改目的：

减少脚本执行后的额外外设访问； 避免在目标状态不稳定时触发不必要的 DAP 访问。 5. 验证结果

修改后重新编译工程成功。

Build size：

text 24992 data 992 bss 6224 dec 32208 hex 7dd0

ELF load segment 已确认 32 Byte 对齐。

使用修改后的 TRACE32 脚本：

C:\Users\xiangye\Desktop\trace32\YTMicro\ytm32b1ha0\testScript\ytm32b1ha0-debug.cmm

执行下载后点击 Go，程序可以正常运行，未再出现 DAP 失联问题。

6. 推荐使用方式

建议使用以下流程：

重新编译工程； 板子断电重上电； 在 TRACE32 中执行： DO C:\Users\xiangye\Desktop\trace32\YTMicro\ytm32b1ha0\testScript\ytm32b1ha0-debug.cmm 脚本执行完成后点击 Go。 7. 注意事项 当前验证使用的是 ytm32b1ha0-debug.cmm。 ytm32b1ha0-trace.cmm 如果后续也要使用，需要同步修改为 SWD，并同步 ELF 下载方式及 FLASH.TARGET 配置。 如果后续重新通过配置工具生成工程，GENERATED_SDK_TARGET.cmake 或 yt_linker.ld 可能被覆盖，需要重新确认本说明中的修改是否仍然保留。 主要集中在 linker 对齐、编译配置和 TRACE32 调试下载脚本。

82ad020a-e80a-4c52-b238-d90db2a8be21-HA Trace32 test okt.zip

在开启接收是，出现故障就没办法恢复了，有没有遇到过的大佬
34c01ebb-e3d9-4ffc-9bdd-6f6181fdf27f-image.png