YunTu Forum

问题描述
ME0 SDK 1_4_0
在uart timeout回调函数中调用receive函数不生效
7b40e665-1ed7-4305-b049-6ae6d7596d62-image.png

问题原因及解决办法
在中断中清除中断标志位和调用回调函数的顺序不对导致，将下图顺序交换即可
2ae6a487-b56a-403b-b589-97c5c359accb-image.png

所有操作都是按照教程，然后就会出现如图的错误，但是同样的操作移植32单片机，就不会出现这个问题，有没有大佬知道这是啥情况，求解答。1730941176839.png

YTM32B1LE05官方UDS例程，CanTp_Hal_Mainfunction函数中这个状态一直返回忙碌怎么回事？
只有一个板子有问题，同样的环境换一块板子就好了。
另外，出现问题这个板子单刷App的话，通信也是正常的，单刷Boot有这个问题。
59bfe3a0-56e2-49ee-8cc2-ad9969eb3298-image.png

不同can模块的CanMessageBufferRamRegionNum配置项的数量是和硬件通道相关的吗？例如can0可以配置两个can3只能配置一个7b66a95d-993e-4ffd-994a-5d68effb3301-image.png

我们在ME的can应用时遇到一个问题，我们的系统中存在CCP协议，会在主循环中间
隔一定时间进行发送（发送前都检查邮箱是否空闲），但我们的捕获中断（优先级高于CAN,这是我们系统最重要的中断）里隔一段时间也会利用can外发消息（在系统高负荷时这个频率会随之加快，这里我们选了另一个邮箱进行发送），这导致CCP运行一段时间后出现异常，异常断联，即CCP协议不再主动外发消息了，重连后会恢复；在ccp协议中我们会利用can发送完成中断触发下一次发送（之前我们在S32K144和146上也是这么处理的并没有出现问题）；
目前尝试过将CAN的优先级放在最高这样不会出现断连或者关闭捕获中断中的发送。但这不符合系统运行的要求，请问是否有的别的方案

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

PINS_GPIO_ReadPins(const GPIO_Type * const base)检测的高低电平区间是多少，目前检测的电压为1.8V，显示为低电平

使用芯片ME05,MCAL版本2.20。
程序中使用SPI1，SPI2，SPI5，因为需要进入休眠，调用了SPI_Deinit函数，唤醒后重新走初始化流程，SPI2发送数据时直接进入hardfault_handler，排查发现问题如下：
在init时调用Spi_StatePtrs[HWUnit]，HWUnit为(0,1,2)
42f2cc4f-5ec4-44f1-80bd-2ef059d0411d-afa230f4d329cef7b71a965d6141059a.png
在Deinit调用Spi_StatePtrs[Instance]， Instance为(1,2,5)
daef104e-d89e-49bc-b197-8a7abbe3bd28-4f60fd00f44b7063328ca0426ecccd0a.png
导致使用instance（instance=5) 出现越界，刚好把Spi_BasePtrs[2] 踩踏为0x00, ，Spi_Lld_SetIntMode函数出现hardfault
3e1458bb-87e4-4711-924f-392d482ef9ad-8fb96a9c15fd1707a364612730bccf0e.png
这个问题该如何避免？

在测试中发现，AD口的电压是0.722V，但是AD采集出来的是0.70V。MC的单片机ADC的误差范围是多少？

问题描述

最近在使用YTM32B1ME05的ADC模块时时遇到了一个问题，使用了ADC0和ADC1两个模块，固定通过eTMR的一个通道触发采集，周期大概在1ms，测试发现采集到的AD值会一直跳动，排查发现和切换TMU和ADC_CHSELx的配置有关系，请问下这里有什么需要注意和的地方吗？如何解决？

原理图 VREF：

5d40928c-e247-4a91-b65f-c6f25f61dab7-image.png

不切换配置 void user_adc_start_conversion(void) { tmu_target_module_t targetModule = TMU_TARGET_MODULE_ADC0_EXT_TRIG; /* Configure ADC channel selection based on PWM index */ if(adcInst[UserAdcParams.pwmIndex][0] == ADC1_INST) { // ADC1->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; // targetModule = TMU_TARGET_MODULE_ADC1_EXT_TRIG; } else { // ADC0->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; // targetModule = TMU_TARGET_MODULE_ADC0_EXT_TRIG; } /* Update TMU target module directly without reinitializing entire TMU * This is more efficient than TMU_DRV_Init which resets all target modules */ TMU->MUX[3] = 0; TMU->MUX[4] = 0; TMU_SetTrigSourceForTargetModule(TMU, TMU_TRIG_SOURCE_eTMR0_EXT_TRIG, targetModule); }

结果如图，基本在2938~2948之内，波动比较小
12ce6b9a-cd59-44af-be94-d96c91fa69c4-image.png

周期切换TMU void user_adc_start_conversion(void) { tmu_target_module_t targetModule = TMU_TARGET_MODULE_ADC0_EXT_TRIG; /* Configure ADC channel selection based on PWM index */ if(adcInst[UserAdcParams.pwmIndex][0] == ADC1_INST) { // ADC1->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; targetModule = TMU_TARGET_MODULE_ADC1_EXT_TRIG; } else { // ADC0->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; targetModule = TMU_TARGET_MODULE_ADC0_EXT_TRIG; } /* Update TMU target module directly without reinitializing entire TMU * This is more efficient than TMU_DRV_Init which resets all target modules */ TMU->MUX[3] = 0; TMU->MUX[4] = 0; TMU_SetTrigSourceForTargetModule(TMU, TMU_TRIG_SOURCE_eTMR0_EXT_TRIG, targetModule); }

结果如图
ca3aea5b-fc44-4907-95d7-69118442a9b3-image.png

周期切换ADC通道

注意通道0和1不切换，只切换2和3

void user_adc_start_conversion(void) { tmu_target_module_t targetModule = TMU_TARGET_MODULE_ADC1_EXT_TRIG; /* Configure ADC channel selection based on PWM index */ if(adcInst[UserAdcParams.pwmIndex][0] == ADC1_INST) { // ADC1->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC1->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; ADC1->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; ADC1->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; targetModule = TMU_TARGET_MODULE_ADC1_EXT_TRIG; } else { // ADC0->CHSEL[0] = adcInst[UserAdcParams.pwmIndex][1]; // ADC0->CHSEL[1] = adcInst[UserAdcParams.pwmIndex][1]; ADC0->CHSEL[2] = adcInst[UserAdcParams.pwmIndex][1]; ADC0->CHSEL[3] = adcInst[UserAdcParams.pwmIndex][1]; targetModule = TMU_TARGET_MODULE_ADC0_EXT_TRIG; } /* Update TMU target module directly without reinitializing entire TMU * This is more efficient than TMU_DRV_Init which resets all target modules */ TMU->MUX[3] = 0; TMU->MUX[4] = 0; TMU_SetTrigSourceForTargetModule(TMU, TMU_TRIG_SOURCE_eTMR0_EXT_TRIG, targetModule); }

结果如图，抖动的比较厉害
e9dba9d3-df63-48a0-af25-c6f373d1a629-image.png

用到的函数

/** * @brief Print latest ADC samples in JustFloat-like format */ void user_adc_print_samples(void) { uint8_t frame[4U * sizeof(float) + 4U]; uint32_t offset = 0U; if(!sendFlag) { return; } sendFlag = false; for(uint8_t idx = 0U; idx < 4U; idx++) { float f = (float)adcSapleResult[idx]; (void)memcpy(&frame[offset], &f, sizeof(float)); offset += (uint32_t)sizeof(float); } (void)memcpy(&frame[offset], c_justfloat_tail, sizeof(c_justfloat_tail)); offset += (uint32_t)sizeof(c_justfloat_tail); /* Send with LINFlexD UART polling, instance = 2 */ LINFlexD_UART_DRV_SendDataPolling(2U, frame, offset); } /** * @brief ADC0 interrupt handler * @return none */ void ADC0_IRQHandler(void) { ADC_DRV_ClearEoseqFlagCmd(0); adcSapleResult[0] = ADC_DRV_ReadFIFO(0); adcSapleResult[1] = ADC_DRV_ReadFIFO(0); adcSapleResult[2] = ADC_DRV_ReadFIFO(0); adcSapleResult[3] = ADC_DRV_ReadFIFO(0); adcSapleSum = adcSapleResult[0] + adcSapleResult[1] + adcSapleResult[2] + adcSapleResult[3]; updateAdcResult(adcSapleSum >> 2); UserAdcParams.boardSupplyVolt.rawAdcValue = ADC_DRV_ReadFIFO(0); UserAdcParams.ledSupplyVolt.rawAdcValue = ADC_DRV_ReadFIFO(0); } /** * @brief ADC1 interrupt handler * @return none */ void ADC1_IRQHandler(void) { ADC_DRV_ClearEoseqFlagCmd(1); adcSapleResult[0] = ADC_DRV_ReadFIFO(1); adcSapleResult[1] = ADC_DRV_ReadFIFO(1); adcSapleResult[2] = ADC_DRV_ReadFIFO(1); adcSapleResult[3] = ADC_DRV_ReadFIFO(1); adcSapleSum = adcSapleResult[0] + adcSapleResult[1] + adcSapleResult[2] + adcSapleResult[3]; updateAdcResult(adcSapleSum >> 2); sendFlag = true; }

f369597a-2379-494a-b632-1278d67c3184-image.png

使用eTMR_DRV_UpdatePwmChannel接口设置占空比。

将etmr0的ch1和ch4通道初始状态配置成0（低电平），在勾选“Polarity of the channel PWM signal”的情况下，执行完
eTMR_DRV_InitPwm(0,&ETMR_PWM_Config0); 后，初始状态被反转了。
267799eb-3c5f-4c07-8845-368e87bd4b4f-image.png
326cfd2f-81cc-4be5-b949-dd9841f83266-image.png
因为我需要将初始通道状态配置成0.如果把初始状态配置成1，在使能反转的情况下，还是会有一个持续1us的电平
d4a22892-003a-44f6-9143-ce546f9fff1c-image.png

请问关于ytm32b1md1的saftylib 中 有关于cpu test 的相关内容么

有客户问到YunTu IDE使用相关的一些问题，可以参考以下PDF文档：
如何搭建独立路径的YunTu Eclipse IDE工程.pdf
但是建议客户使用VSCODE+GCC编译，ozone进行调试，因为YunTu IDE后期没有计划继续对其进行维护了，出现问题可能响应速度会相对慢一些。

根据EFM应用手册， 代码如下：
e5d06a67-707a-4437-9453-a1f2d6c6c344-image.png
实际得出的MAC值与第三方不一致：
854f3bc4-6c9c-4006-98f5-90f5794c4e8a-301990fa21c0cbedaf55036d58c482fa.png 0eed32cf-46d9-4d5f-8ffd-12583f05f3d3-image.png
是不是load的硬件key不对？
CUS_KEY寄存器中的match==1
e3850e1e-ba9d-4c02-99af-43bbf38c2d9c-image.png
40a655bc-2833-417d-b6a0-ed78d856f1f0-image.png
更换字节顺序也无效
demo工程如下
Flash_Demo.zip
调用的写入擦除函数分别是FLASH_DRV_Program FLASH_DRV_EraseSector

e787d53a-3da3-425f-9991-1e52a81cd921-1767528811346_4FBF0B6F-B60F-4a53-A8B6-A8A1EA9D6215.png
想要实现上面图片的CRC校验，crc_config应该如何配置
d6321be0-7075-4813-bbbd-7cf50e4c3719-1767528908738_2D8AD0FB-7EBD-4546-B53D-4E762E1C0E9B.png

在应用ME05 CUS_NVR时，如果直接调用“FLASH_DRV_Program”会无法操作，因为ME05的NVR有单独的驱动：“FLASH_DRV_ProgramNVR”等；（而HA01系列则是同一套flash驱动，需要区分应用）

下述具体测试情况

环境

软件：YCT_SDK1.3.1 Flash_Disable_Jtag_Demo 硬件：ME05 EVB Rev.C开发板

测试

查询手册，USER_NVR的地址区域为0x10030000-0x100303FF，共1KB；
66dd21ae-3340-4a28-b91b-d3b03a30642d-image.png Flash_Disable_Jtag_Demo工程中，有对CUS_NVR进行读擦写操作，直接下载测试；
e3dcc63b-036d-41fe-be2f-764bb45a6373-image.png 读、擦、写测试成功。
4723e3a3-348b-4d1a-9006-ba5a5fda8618-image.png

测试代码

Flash_Disable_Jtag_Demo.zip

Dear Yuntu Support Team,

I hope you are doing well.
I am currently working with the YTM32B1MD microcontroller series and using the on‑chip CRC32 hardware module to verify firmware integrity. However, we have observed that the CRC32 result generated by the Yuntu hardware CRC engine does not match the CRC32 result produced by the IAR ielftool (CRC32/Ethernet configuration).
To ensure our firmware integrity workflow is correct, we would like to request official confirmation of the exact CRC32 parameters used by the Yuntu CRC hardware.
Specifically, could you please help confirm the following details?

CRC Polynomial

We currently understand the polynomial as:
X^32 + X^26 + X^23 + X^22 + X^16 + X^12 + X^11 + X^10 + X^8 + X^7 + X^5 + X^4 + X^2 + X + 1
which corresponds to 0x04C11DB7 (CRC‑Ethernet / IEEE 802.3).
Please confirm whether this is correct.

Input and Output Reflection

Does the Yuntu CRC module perform:

REFIN (bit reflection on input bytes)?
REFOUT (bit reflection on the final CRC value)?

Initial CRC Value (Init / Seed)

What is the default initial value used by the hardware?
(e.g., 0xFFFFFFFF, 0x00000000, or another value)

Final XOR Value

Does the hardware apply a final XOR (e.g., 0xFFFFFFFF) automatically, or should this be done in software?

Byte Ordering / Word Feeding

When feeding 32‑bit data into the CRC module:

Should bytes be provided in little‑endian order?
Does the hardware internally reverse byte order?

Any Known Differences Compared to Standard CRC‑Ethernet

Are there any Yuntu‑specific variations that may cause mismatch with tools such as IAR, Python, or standard CRC32 calculators?

Understanding these exact CRC parameters is important for us to:

Align our bootloader and firmware integrity checks Ensure IAR post‑build CRC matches Yuntu HW CRC results Comply with integrity requirements in our production workflow

We would greatly appreciate your guidance or example code/configuration showing the correct CRC32 usage for YTM32B1MD.

fdcc3fa0-dd3d-4050-b4c4-ee70ae4f9513-image.png

IAR generated CRC32
ielftool --checksum=__CRC32:4,crc32:i,0xFFFFFFFF;0x00000000-0x000203FB
firmware.out firmware_crc.out

是否是load的KEY有问题91eb1e02-b578-49ee-803d-20ab39184507-image.png 6fa3bd30-1415-4b21-8c47-25056977ce3e-image.png 42594a82-fb1c-4e6f-9788-4a1cd7af8d03-image.png
该如何继续往下排查

求助：云途IDE如何配置生成Hex文件