YunTu Forum

1，采样点测试原理：
中心思想是：对于指定位，将其缩短或增长，如果缩短或增长至 DUT 的采样点位置，则 DUT 将会发送错误帧。这个指定位的位置可以是一帧报文中的任何位置。但最好的位置是“隐形位”-> “显性位”-> “隐形位” 序列中的“显性位”，称此为最佳干扰位。这是由于重同步仅会发生在由隐形位变为显性位的跳变沿上， 一般来说在此处跳变沿将会位于同步段（Sync Segment）。
dca5f322-259a-4b17-a3fe-718f40ef4d8b-image.png
假设 DUT 会以 10ms 为周期向总线发送 ID 为 0x100 的 CAN 报文。VH6501 将在程序启动后，在 DUT 发送 报文的总线空闲间隙发送 ID 为 0x0 的干扰报文。VH6501 发送的所有报文，其【ACK Slot】位都为显性位“0”，为系统默认，无需额外特殊设置。每次干扰循环发送结束，微调干扰报文的【CRC Delimiter】位 长度，使其逐次缩短，并将后一位【ACK Slot】的长度增加。导致的结果为，后一位【ACK Slot = 0】前移。而一旦显性位电平由后往前，前移至 DUT 采样点位置，被 DUT 采到判定为高电平，则出现 Form Error， DUT 随即发送错误帧，并被 CANoe 捕获到（RxErr）。故 CANoe 测试逻辑通道（VH6501 所在通道）采样点须选取靠前位置（e.g. 50%），从而避免被 VH6501 本身先干扰到。另，每次干扰循环结束，VH6501 将 发送 30 次 ID 为 0x1 的正常报文，从而使 DUT 始终保持 Error Active 状态，因其主动错误帧容易辨认。
4298de21-9731-486f-91b8-50a852580213-image.png
1）∆𝑡𝑀𝑒𝑠𝐻𝑤指 VH6501 每次缩短或增长的步进长度。 VH6501 采用160M时钟频率，每个tick 6.25ns，单次可调整步长为1个tick。因此，∆𝑡𝑀𝑒𝑠𝐻𝑤=6.25ns。
2）∆𝑡𝑇𝑄指 DUT 的 CAN 参数配置中一个 TQ 的时间长度。 上文中提到的采样点最佳干扰位置是“隐性位-显性位-隐性位”序列中的“显性位”，ISO 11898-1协议里规定重同步会使跳变沿落在同步段里，但是协议并未明确定义跳变沿具体落在同步段的位置，从同步段的开始到结束均可以，因此这会带来1个TQ的误差。所以由DUT自身带来最大误差为1个TQ,而TQ数量与DUT采用的时钟，预分频值以及传输波特率等都相关。
当前CAN 时钟频率为20MHZ,预分频值为1，∆𝑡𝑇𝑄 = 𝑃𝑟𝑒𝑠𝑐𝑎𝑙𝑒𝑟 /𝐶𝐴𝑁 𝐶𝑙𝑜𝑐k=50ns;
仲裁域波特率500K,位时间长度为2000ns,TQ总数为40;
数据域波特率2M,位时间长度为500ns,TQ总数为10。
∆𝑡𝑅𝑒𝑐指总线上一个位的电平长度与 DUT 内部主控芯片 RxD 引脚上的一个位电平长度的时间差。
6b010407-af50-424e-b905-f5a70bb02899-image.png
在2M 波特率下，一个TQ 长度为50ns,位长度为500ns,∆𝑡𝑅𝑒𝑐 范围为-65ns 到+40ns, ∆𝑡𝑅𝑒𝑐需要被考虑进采样点测试的结果当中，为了方便计算∆𝑡𝑅𝑒𝑐取25ns。

在仲裁域中，∆𝑡𝑀𝑒𝑠𝐻𝑤 带来的误差为6.25/2000=0.3125%;∆𝑡𝑇𝑄带来的误差为 50/2000=2.5%; ∆𝑡𝑅𝑒𝑐 带来的误差为25/2000=1.25%；
在数据域中，∆𝑡𝑀𝑒𝑠𝐻𝑤 带来的误差为6.25/500=1.25%;∆𝑡𝑇𝑄带来的误差为 50/500=10%; ∆𝑡𝑅𝑒𝑐 带来的误差为25/500=5%；
综上所述，在仲裁域中，总的误差为0.3125%+2.5%+1.25%=4.0625%,约等于4%，数据域中，总的误差为1.25%+10%+5%=16.25%。
因此，若理论采样点为80%，而实际测试的结果，仲裁域在80%±4%，数据域在80%±16.25%范围内都是合理的。
由上可知，由 VH6501 所带来的误差所占比例是很小的。而大部分是由于 CAN 协议本身所带来的误差，以及由于总线长度不同所带来的误差（尤其在CANFD 数据域测试中）。
这些误差可以认为是合理且无法避免的，在实际测试验证中需要进行一定的考量。

ME芯片:
https://forum.ytmicro.com/topic/1566/me05-sdk-saflib-基于iar编译器demo示例

环境
SDK：1_4_0
MCAL：2_2_0

demo中为YTM32B1MD14 KEIL环境，MCAL部分功能安全模块移植到SDK
移植模块：CorTst、RamTst、StkTst、EccTst
MD14_Safty_KEIL.zip

问题表现：

重复进入中断处理函数LINFlexD_UART_DRV_RxIRQHandler；

状态位异常：uartState->isRxBusy=0（接收未完成却置0）、uartState->receiveStatus=Overrun（接收溢出）；

66706010-2046-4fd6-9b97-9f19f419217d-1d9e50227d7aa4c18b131df73764275f.png
60a7c100-aac3-4f59-b2a8-c473839ffbcf-image.png
adffb33e-9954-41a1-a482-c19b411df680-image.png
621ddc5d-7d48-4572-a4a9-5dad18a267a4-7b438e9f315073cb51cc014b2a428b30.png
0b2c05a7-8e28-4d02-98d3-19ea192dca3c-6c8276a44691de2072ec81d1ad1162c9.png
客户目前尝试把清标志位的动作加上（即使uartState->isRxBusy 被置0也会去清中断标志位）来避免中断溢出
bfedcfa5-7396-4059-9d89-e068955b9848-cce6212fd417f6d8c7c09b46cd320a5c.png

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

本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
dbc523c3-21f4-4d1a-98b3-3b50282fac1a-image.png

烧录Bootloader
新建YTM32B1MD14的JFLASH工程
c609c5a4-00b8-434b-a244-ae5bde77e46e-image.png
找到Bootloader编译的烧程文件
a0b6c9f7-8e07-40e7-aaa4-3076355c8caa-image.png
加载Bootloader文件
3900e9bd-c72e-4bc9-acc3-e2287c796557-image.png
擦除芯片（或者快捷键F4）
156d3954-7e53-4a13-8e5f-026e4a1bff49-image.png
fae94334-266c-4740-969c-f69d2650440e-image.png
烧录程序（或者快捷键F6）
ac129ec4-4b1b-42cc-80ba-44d166e59e25-image.png
6d1d1b5c-28af-444d-84a1-01280c9a14e3-image.png 上下电运行Bootloader
拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。 升级上位机配置
将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
3f15b88d-af6f-43f6-b285-877a7d0ca419-image.png
打开升级上位机工程（如上图中.TSProj_x86文件）配置收发ID
ade66a27-609f-4150-8fde-a1f6f0833ec9-image.png

配置TP时间参数，配置加密dll
b8723e3c-c726-4876-b46a-e8e4488d0ec1-image.png
配置FlashDriver和Application和校验方式
95adfb20-50a3-4532-bd58-7b9a69330010-image.png
配置自动诊断流程
6d7f2e9f-73b1-4354-a03a-37f565903759-image.png
4. 执行升级
4.1 从Bootloader升级
b35da6fc-c501-4ebb-9e57-6167a92185d6-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.2 从Application升级
从Bootloader升级成功运行到Application后，再次点击运行，从Application升级。
14c4d1e0-df93-4efb-80f3-fda4130399e3-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.3 StayInBoot升级
从Application升级中，是有升级请求标识的（KeepInBootVar变量）。
本方案设计上认为：
运行到Bootloader以后，如果通讯一半断开未发生升级服务（擦除芯片/请求下载/数据传输/下载退出等UDS服务），则即使有升级请求，可以超时退出重新跳转到Application运行；反之则必须StayInBoot等待重新升级。
4.3.1 未发生升级流程请求
升级一半，拔掉CAN线模拟通讯断开，升级失败
b38f0141-062e-4be3-96d8-74d35fb5f42b-image.png
通讯断开超时后，Bootloader重新进入Application运行，Demo板上LED灯1000ms闪烁。
4.3.2 已发生升级流程请求
执行到升级流程后，拔掉CAN线模拟通讯断开，升级失败
d66fcdc3-fedc-4180-98b0-07e4e5dc9259-image.png
通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级
e3fce7cf-3ad9-49f9-b415-9d64b295a22b-image.png
升级成功，Demo板上LED灯1000ms闪烁。
5. 附件代码
uds_can_fbl_md14_release_20250530_2.zip

问题描述：

在使用YCT工具配置工程时，当将RAM初始化区域配置为 4字节对齐 (4bytes align) 时，工具生成的 RamInit0.s 汇编代码在 Green Hills (GHS) 编译器下编译失败。

环境信息：

芯片型号： YTM32B1LE0x
编译环境： Green Hills Software (GHS) / asarm
报错文件： RamInit0.s

复现步骤：

列表在YCT工具中，将RAM大小设置为4的倍数，触发四字节对齐。 生成代码。 使用GHS编译器进行编译。

编译器报错如下：

[asarm] (error #2071) ... RamInit0.s 63: bad parameter
STR R0, [R1], #4

19977c18-e357-41cc-afbe-832f9d796339-d93a61c7f1c448a84914ce789c91253b.jpg

bcb572fa-e6cc-4442-b646-f8c3bf4f724d-3f545784704100c3579df506a0eb608f.jpg

版本：

Config Tool Version：2.7.6
IDE:GCC+VSCode

使用方法

在调查分析低功耗问题时，可以将下面对应的elf文件下载到板子上进行功耗测试。
如功耗比对正常，就可以快速排除芯片自身，及部分硬件电路的原因。

ELF文件可以使用Ozone 或者 JFlash 直接进行下载； 也可以J-Link Commander 连接后，"loadfile XXX.elf" 进行下载； 下载后注意需要复位运行。 工程配置 使用FIRC作为系统时钟，关闭PLL及外部晶振时钟，模块时钟也都默认不做配置 芯片引脚全部默认不做配置 10秒后进入最低功耗模式 Reset脚复位唤醒
f18aa665-d8af-435b-9981-992492ca43b9-image.png 测试注意事项 电流表串联进芯片VDD PIN脚，不要分流其他器件。 断开仿真器。 YTM32B1LE0开发板测试需要拿掉2个滑动变阻器RP1，RP2。 YTM32B1HA0开发板测试需要拔掉J35，J36 YTM32B1LE0

70b758b4-afe6-491a-a319-25d0c53dd0ed-image.png
YTM32B1LE0_Standby_SIRC_Enable.elf
YTM32B1LE0_Standby_SIRC_Disable.elf
YTM32B1LE0_Standby.zip

YTM32B1LE1

63a82db6-5051-47ab-b533-9820fa1f5cdf-image.png
YTM32B1LE1_Standby_SIRC_Enable.elf
YTM32B1LE1_Standby_SIRC_Disable.elf
YTM32B1LE1_Standby.zip

YTM32B1MC0

b793ad60-3863-45a0-9f9d-17f74b9f8174-image.png
YTM32B1MC0_Standby_SIRC_Enable.elf
YTM32B1MC0_Standby_SIRC_Disable.elf
YTM32B1MC0_Standby.zip

YTM32B1MD1

1b7e4233-649d-4cda-9418-50b5d730852a-image.png
YTM32B1MD1_PowerDown_SIRC_Enable.elf
YTM32B1MD1_PowerDown_SIRC_Disable.elf
YTM32B1MD1_PowerDown.zip

YTM32B1MD2

7817f175-04da-4eaa-8be8-fd6aa3560b12-image.png
YTM32B1MD2_Standby_SIRC_Enable.elf
YTM32B1MD2_Standby_SIRC_Disable.elf
YTM32B1MD2_Standby.zip

YTM32B1ME0

e850dcf9-221f-444a-a263-ba9d9fd7e36f-image.png
YTM32B1ME0_PowerDown_SIRC_Enable.elf
YTM32B1ME0_PowerDown_SIRC_Disable.elf
YTM32B1ME0_PowerDown.zip

YTM32B1HA0

e2cda702-687a-49a6-b46b-5463fde1a933-image.png
YTM32B1HA0_PowerDown_SIRC_Enable.elf
YTM32B1HA0_PowerDown_SIRC_Disable.elf
YTM32B1HA0_PowerDown.zip

YTM32Z1LS0

82f66f21-ce70-42c7-bd12-0bc1f923596a-image.png
YTM32Z1LS0_Standby_SIRC_En.elf
YTM32Z1LS0_Standby_SIRC_Dis.elf
YTM32Z1LS0_PowerDown.elf

调试低功耗注意事项 调试低功耗模式时在main函数中加一个延时 在进入低功耗之前加入适当的延时。防止芯片因上电后立即进入低功耗模式而无法烧录，调试正常后再去掉延时函数。 SysTick在进入低功耗模式或者跳转APP时关闭 列表SysTick在调用OSIF_TimeDelay等函数会自动打开；需要在bootloader跳转APP之前关闭: SCB->ICSR |= SCB_ICSR_PENDSTCLR_Msk; SysTick->CTRL = 0x00; 低功耗休眠LPACK问题 低功耗休眠唤醒压测时，监测RSSR出现LPACK 出现LPACK的原因是在睡眠之前，有外设有中断消息产生总线请求，导致MCU无法进入低功耗
措施： 在睡眠之前把不需要工作的外设Disable，其外设中断Disable； 在唤醒以后吧需要工作的外设重新Enable，其外设中断Enable；

背景

部分工程编译出来的可执行文件 (.hex, .srec) 可能存在地址不连续，分段等现象，这是合理的，符合 Hex 协议或 Srec 协议，协议内容可参考 Hex，Srec 文件格式。
但是有些上位机可能无法正确的读取这些文件内的数据，所以需要对数据进行填充，默认填充值为 0xFF
此外部分云途的 MCU 最小编程单元是 8字节，如果 boot 相关的上位机不进行 8字节填充对齐，可能会导致最后一个word 没编进去。

使用说明

将附件中的压缩包解压，在 Power Shell 中运行，运行结果如下图
d209bcbe-b919-4b81-97b4-2ed468e81891-image.png

参数解释

输入 -h 可查看帮助，可达到参数内容

App

需要进行补全对齐的文件，这个必须配置

-s 或者 --start

应用程序的起始地址，如果不专门进行指定，脚本会读取程序的起始地址，可不配置

-e 或者 --end

应用程序的结束地址，如果不专门进行指定，脚本会读取程序的结束地址，可不配置

-a 或者 --align

应用程序的对齐方式，脚本会根据对齐方式，修改起始地址域结束地址来确保对齐。可不配置，默认 4 字节对齐。
例如设置对齐方式为 8字节，可在命令行中输入

.\outputPadding.exe .\random.srec -a 8

如果检测出程序的起始地址为 0x4004，脚本会校准起始地址为 0x4000
如果检测出程序的结束地址为 0x8004，脚本会校准结束地址为 0x8008
如果用户指定了生成程序的起始地址与结束地址，则该参数无效

-l 或者 --lineLength

生产的 Hex 或 Srec 一行所包含的有效数据字节个数（不包含地址字段与校验字段），可不配置，默认一行包含 32 字节

-o 或者 --output

输出的文件，可不配置，默认生成 output.hex 或者 output.srec

附件

压缩包中包含 outputPadding.exe , random.srec, test.hex
random.srec, test.hex 是两个测试文件，用户可在里面自由删除，并测试是否补全
test_padding.zip

987dda7c-024e-4b4d-ba05-631c91ce6ed3-image.png

adc采样配置为2M

f783ae0c-b2e5-4bd4-828c-69b3bcb2c0c4-image.png

6b033185-6d3b-4ed6-a910-bc019235c5c6-image.png

但是和实际万用表测量下来的数据有误差

以下是测量单组稳定数据：
d796ca2c-0509-4466-b81c-e9b7b1e7f886-image.png

最多存在10mv多的误差

YCT生成的CMAKE工程默认是增量编译，每次只编译有变化的文件。

但是有的客户想要每次都全量编译（通常适用于服务器端的CI/CD等业务）

可以进行如下修改：

打开工程下的.vscode/settings.json文件 增加如下配置： "cmake.buildArgs": [ "--clean-first" ], ok, 这样每次编译都是全量编译，对于的cmake 命令为：
cmake --build . --clean-first

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

背景说明

在早期版本的 YCT 中，工程导入功能无法跨芯片使用。其主要原因在于，不同芯片之间的驱动层（Driver）差异较大，直接复用会导致配置不兼容。

然而，在实际使用中发现，中间件（Middleware）的配置在不同芯片之间往往是可复用的，此前的限制在一定程度上影响了工程迁移和复用效率。

解决方案

自 YCT v2.7.9 及以上版本起，新增支持跨芯片导入中间件（Middleware）配置的能力。

用户可以在不同芯片工程之间，仅导入中间件相关配置，而无需关心底层驱动的差异。

如下图所示，freertos 和 unitu_print 等中间件模块已支持跨芯片导入：

middleware-import

注意事项

在进行跨芯片中间件导入时，请注意以下操作顺序：

例如：从 MD1 工程向 ME0 工程导入中间件配置

先使用当前版本的 YCT 打开 MD1 工程的 .yct 文件 执行一次保存操作（用于工程格式升级） 再打开 ME0 工程 从 MD1 工程中导入中间件配置

未按上述步骤操作，可能会导致导入失败或配置不生效。

如下图所示，工具界面中默认开启了 -ffunction-sections 和 -fdata-sections。

原因： 生成的 cmake/gcc.cmake 脚本中使用 SET(CMAKE_C_FLAGS ...) 强制重置了编译参数，导致工具传入的这些标志被覆盖丢失。

后果： 链接器无法正确剔除未使用的代码（Dead Code Elimination）

关联问题:
https://forum.ytmicro.com/topic/1302/同样的工程vscode-gcc编译的二进制文件远远大于keil-mdk生成的?_=1763805564704

65761351-0095-445c-b8bd-577719c47dfd-image.png

c0a0e3cc-1b9e-4e8c-a7eb-9c0610679f16-image.png

1747634828985.png 1747634787483.png !

1、当block数量多的时候选择左边的block需要滑动到底下，此时选中又需要滑动到最上面才能显示配置参数，这点能不能提前把修改好的工具释放出来，目前项目需要使用700个block，配置很麻烦。
2、后续如果能支持excel导入导出编辑效率会更好

目前使用的YTM32MD14芯片DEMO只有物理寻址，我这边想要添加功能寻址具体有什么详细步骤吗

Dio_Demo.hex

c54c19da-ab65-4d71-803f-d5d44ed82e7c-image.png

本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
5e1b4583-94f0-4786-8b03-c70851e6bb51-image.png

烧录Bootloader
新建YTM32B1MC03的JFLASH工程
e31f21d8-f1b4-4be0-960d-b1bdd08bc63d-image.png
找到Bootloader编译的烧程文件
9ceb1572-c212-4c57-a815-0b8d7e84806c-image.png
加载Bootloader文件
807cf228-2a95-43a9-b84f-4cf29b0332a3-image.png
擦除芯片（或者快捷键F4）
ace171c2-6b70-4201-99c3-50d9863d1af6-image.png
4ddc4c41-a35e-49fd-9404-c0a4cf401dd3-image.png
烧录程序（或者快捷键F6）
98170abf-7180-46a8-b7da-86a82369cd88-image.png
d226326b-944a-499f-ad36-a6af638db7fb-image.png 上下电运行Bootloader
拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。 升级上位机配置
将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
435a580c-314d-4f54-8a4b-6d2e9007348d-image.png
打开升级上位机工程（如上图中.TSProj_x86文件）配置收发ID
45aa0f66-c39f-4794-8fc9-eb3a8489d382-image.png

配置TP时间参数，配置加密dll
6438a816-417d-45ad-b0f1-200d3b1e75ce-image.png
配置FlashDriver和Application和校验方式
8a33cf16-38f8-4cb4-b500-e24496e683db-image.png
配置自动诊断流程
b726c12e-406e-485c-9441-b671b51efb75-image.png
4. 执行升级
4.1 从Bootloader升级
dc21dc68-a986-49b0-a596-453a1e948641-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.2 从Application升级
从Bootloader升级成功运行到Application后，再次点击运行，从Application升级。
1ba1902e-953b-4e91-978d-989d81d4320e-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中。
4.3 StayInBoot升级
从Application升级中，是有升级请求标识的（KeepInBootVar变量）。
本方案设计上认为：
运行到Bootloader以后，如果通讯一半断开未发生升级服务（擦除芯片/请求下载/数据传输/下载退出等UDS服务），则即使有升级请求，可以超时退出重新跳转到Application运行；反之则必须StayInBoot等待重新升级。
4.3.1 未发生升级流程请求
升级一半，拔掉CAN线模拟通讯断开，升级失败
0b519b6a-91d3-44a0-b6bf-794829a3652b-image.png
通讯断开超时后，Bootloader重新进入Application运行，Demo板上LED灯1000ms闪烁。
4.3.2 已发生升级流程请求
执行到升级流程后，拔掉CAN线模拟通讯断开，升级失败
d9d0ca85-0330-4f42-b93e-c7196f69ca0b-image.png
通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级
93dce8d5-9f9f-4619-b11d-62bbfea398c7-image.png
升级成功，Demo板上LED灯1000ms闪烁。
5. 附件代码
uds_can_fbl_mc03_release_20250529_2.zip

YT配置工具生成demo工程时，Toolchain/IDE选项中没有IDE，无法生成可以导入YunTuIDE的工程

LE15 UDS LIN FBL demo(SDK 1_3_1)
本方案基于YT Config Tool开发，使用Vscode+Cmake+Ozone工具链开发编译调试；基于Demo板硬件搭建实施；使用同星科技TC1012P CAN/LIN工具及同星科技TSmaster软件。
f4a50300-1cf4-4b4d-acea-b125d11fcf9f-image.png

烧录Bootloader
新建YTM32B1LE15/JFLASH工程
152c33e6-c83b-4830-87c5-a1268be3a0f8-image.png
找到Bootloader编译的烧程文件,加载Bootloader烧录文件
8a37c389-3570-4e30-acc6-2c432d917601-image.png
擦除芯片（或者快捷键F4）
a8358db1-545a-453c-af80-0dbee9c4ccf8-image.png
d5455a9e-0a33-4ed3-af75-83efcf9936f5-image.png
烧录程序（或者快捷键F6）
a51146c0-8741-42ee-a818-82c74ea0c119-image.png
6a76e5ea-df92-4e01-90ec-13cd4b850b1d-image.png 上下电运行Bootloader
拔掉JLINK烧录器，重新上下电后，板子重新工作，LED按照100ms快速闪烁，程序工作在Bootloader里面。 升级上位机配置
将FlashDriver文件、Application文件、SeedAndKey.dll几个文件放到升级上位机目录下。
0c6f1518-0e24-42f8-acda-56227c2263e1-image.png
打开升级上位机工程（如上图中.TSProj_x64文件）配置收发ID 0x2
ca0c69e1-413f-42d7-8f7d-baf7c31d314e-image.png
配置TP时间参数，配置加密dll
3654342d-0558-4cff-abe1-074be5e9c4e4-image.png
配置FlashDriver和Application和校验方式
932dd152-9ab4-4404-85c5-1ebcc1613589-image.png
配置自动诊断流程
c2b83dc6-e991-4020-b9d5-036f9c221383-image.png 执行升级
4.1 从Bootloader升级
17d4d974-cecb-400b-8431-6647d8a92bdf-image.png
升级完成后，LED灯1000ms闪烁，运行在Application程序中（Bootloader程序中LED灯100m闪烁）。
从App升级
ff6dc525-fd43-4e0f-a428-35e44992b107-image.png
4.1.1 已发生升级流程请求
执行到升级流程后，拔掉LIN线模拟通讯断开，升级失败
581429a6-299b-4b8e-9cdb-7128d6381204-image.png
通讯断开超时后，Boootloader不能进入Application，执行StayInBoot（重新复位或者上下电等均保持StayInBoot）。
重新执行升级
74d6ef52-6e30-4546-974e-80993e54427e-image.png
升级成功，Demo板上LED灯1000ms闪烁。
YTM32B1LE1(sdk_ver_1_3_1)_lin-stack_0_9_0 (1).zip
uds_lin_fbl_le151210.zip