YunTu Forum

根据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

问题描述

最近在使用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; }

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

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

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
该如何继续往下排查

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

使用eTMR_DRV_UpdatePwmChannel接口设置占空比。

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

芯片：YTM32B1HA0abfe314c-7dfb-4e5b-8699-ac52adb50fb7-image.png
生成MAC时软件跑不出HCU_DRV_GenerateMAC的221b8ba4-4de6-4042-bc7a-ab00abb99fe6-image.png ，往下debug发现e8d7e8b9-b0c2-469d-b461-29fc2a2b3024-image.png 条件不满足
初始化以及主函数如下94e13168-87c1-4064-bdf5-9bbe6314fc00-image.png

MD平台制作 ram flash driver 遇到困惑：ram flash driver 不能跟其他代码解耦，如在BOOT的少许修订都要导致ram flash drvier 变更，导致升级BOOT时就要同步更新ram flash drvier 导致OTA升级包更新----导致要维护市场上多个ＢＯＯＴ版本的ram flash drvier 驱动

d11e04f1-ac7c-4b35-aad3-65e9157ebf3e-image.png f0141e97-a8c9-4430-b98c-b0349f295b14-image.png
需求单字节接收，在任务中接收1字节后进入中断，将接收到的数据放入队列里继续开启下次接收
问题：同时发送多个字节的数据，只进入1次中断且只能接受1个字节，剩余字节不触发中断，不知道是不是同时发送没有清楚中断标志位导致。有无相关案例

1.背景
在PWM的下降沿触发ADC采集
2.需求

PWM（eTMR0_CH0）的每个周期中，上升沿触发ADC转换10次后，切换到3个软件触发的group的采集。 MCAL: 2.2.0 , gcc YTM32B1ME0X
3.解决方案描述：
由于PWM模块没有提供MID值的设置API，采用手写代码设置MID值： eTMR0->SYNC |= eTMR_SYNC_CLDOK_MASK; eTMR0->MID = eTMR0->CH[0].VAL1; eTMR0->SYNC |= eTMR_SYNC_LDOK(1);

1d4fd905-ae3c-47d3-888c-f4ee53cb1bf2-image.png
测试波形：
bd8b3693-ae79-4952-81dd-89a6bb2aa4b6-image.png
示例工程：12694718-26d0-4c88-a824-16035e3174d3-Adc_HwTrig_Demo.zip

为了方便用户更好的上手使用云途芯片，除官方YCT Demo外，云途原厂不定期更新应用Demo，现更新Demo如下，具体代码及文档说明联系云途FAE获取。
683dde5f-58aa-4f52-8c62-a203466cad66-image.png

想问一下，接口lin_timeout_handle的周期500us可以改慢一点吗？

在案例中配置ETMR0用4个通道pwm输出，使能PWM时会同时输出4个pwm,能不能指定只输出某一个pwm

如题， 我有部分代码需要封库，使用的是CMake + VScode（GCC）环境，请问如何实现？

有没有SPI使用4线模式的示例程序

我尝试为 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)

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

有没有制作ldf文件的工具