基于UDS协议的LIN总线OTA升级实战指南

1. 项目概述为什么在LIN总线上跑UDS诊断协议做OTA升级不是“炫技”而是解决真问题你手头有一台带LIN总线的汽车座椅控制器或者一个智能车窗模块又或者某款国产电动两轮车的灯光管理单元——它们共同的特点是主控芯片资源紧张比如STM32F103C8T664KB Flash、20KB RAM没有CAN控制器也没有以太网口甚至没接Wi-Fi模组但客户突然提了个需求“能不能像手机一样远程把新固件推过来不用拆壳、不用插线、不用换芯片”这时候有人会脱口而出“上ESP32做Wi-Fi OTA啊”——但现实是这颗ESP32得和LIN节点通信而LIN节点本身才是功能主体。你不能让ESP32替它跑UDS 31服务、处理刷写流程、校验Flash页、管理Bootloader跳转。真正的OTA升级必须由被升级设备自己完成。所以“基于UDS诊断协议的LIN通信OTA升级”这个标题本质是在资源受限、物理层简陋单线、低速、无硬件CRC、拓扑固定主从结构的LIN总线上复现一套完整、可靠、可量产的汽车级固件更新能力。它不是把UDS协议栈硬塞进LIN帧里就完事而是要解决LIN物理层抖动导致的报文错位、LIN调度表周期性中断带来的响应延迟、LIN从节点无独立时钟源引发的超时误判、以及UDS服务在无ACK重传机制下的鲁棒性设计等一连串嵌入式底层硬骨头。我做过7个不同车厂的LIN节点OTA项目最深的体会是LIN OTA的成败80%取决于对LIN帧格式与调度表的理解深度而不是UDS协议本身。你看到的热搜词里反复出现“lin诊断报文”“lin帧结构”“uds 31服务”“stm32f103c8t6串口通信”恰恰印证了这一点——大家卡住的地方从来不是“怎么写UDS代码”而是“怎么让LIN总线老老实实把31服务的请求和响应一帧不落地送过去”。2. 整体架构设计与核心思路拆解为什么放弃CAN/UART直连死磕LINUDS这条窄路2.1 架构选型背后的三重现实约束很多初学者看到“UDSLINOTA”第一反应是“为什么不直接用UART连PC升级或者加个CAN收发器”这个问题背后藏着三个无法绕开的工程现实物理层合规性车规级产品必须通过EMC测试。LIN总线采用单线、12V供电、内置终端电阻、差分接收阈值典型±300mV其抗共模干扰能力远超普通UART线缆。我曾用USB转TTL模块直连STM32的USART1做OTA样机在整车EMC暗室里一上电LIN从节点就频繁丢帧——因为USB线缆成了天线高频噪声直接耦合进RX引脚。而LIN收发器如MC33661、TJA1021内部集成了滤波和ESD保护这是UART无法替代的硬性门槛。协议栈复用成本该节点已量产LIN通信栈包括调度表解析、信号打包、诊断报文处理早已通过ASPICE CL2认证。如果为OTA单独新增一路UART通道意味着要额外维护一套串口驱动、一套AT指令解析、一套新的Bootloader入口逻辑还要重新做所有功能安全验证ISO 26262 ASIL-B。而复用现有LIN诊断通道只需在原有UDS诊断服务框架内扩展31服务RoutineControl和34/36/37服务RequestDownload/TransferData/ExitTransfer所有通信、校验、超时逻辑都走同一套经过验证的LIN传输层V模型验证工作量减少60%以上。产线与售后兼容性4S店技师用的诊断仪如VCDS、ODIS只认LIN物理层上的UDS诊断ID0x3E/0x7E等。如果OTA走UART就得给每台车配一个专用烧录夹具售后工程师无法用标准诊断仪触发升级。而基于LIN的UDS OTA技师只需在诊断仪里点选“软件刷新”菜单输入VIN码系统自动调用UDS 19服务读取当前版本再触发31服务启动OTA流程——整个过程与原厂ECU升级完全一致零培训成本。提示不要被“LIN速率只有20kbps”吓退。实测表明在正确配置调度表的前提下LIN 20kbps足以支撑128KB固件包在90秒内完成传输含UDS协议开销、校验、重试。关键不在速率而在如何避免因LIN主节点调度延迟导致的UDS超时中断。2.2 核心数据流与模块划分四层解耦设计整个系统严格遵循AUTOSAR分层思想但针对资源受限场景做了裁剪形成清晰的四层结构物理层PHYMC33661 LIN收发器 STM32F103C8T6的USART2硬件LIN模式。这里必须强调绝不能用GPIO模拟LIN。MC33661的同步时钟输出SYNC引脚必须接到STM32的TIM2_CH1用于精确捕获LIN Break Field起始沿这是实现高精度波特率自适应的基础。我见过太多项目因忽略SYNC信号导致在不同温度下LIN波特率漂移UDS响应超时。数据链路层DLL基于AUTOSAR LIN Stack裁剪的轻量级实现核心是两个函数Lin_MainFunction()每1ms调用处理调度表轮询和Lin_TxFrame()发送LIN帧。重点在于调度表Schedule Table的设计——OTA专用调度表必须包含至少3个SlotSlot0BreakSyncID0x3EUDS请求帧、Slot1BreakSyncID0x7EUDS响应帧、Slot2BreakSyncID0x00空闲帧用于维持总线活性。Slot周期设为20ms确保UDS 0x7E响应能在下一个Slot内发出规避UDS默认35ms超时。网络层NWLUDS协议栈核心。我们不使用Vector或EB的商业栈而是基于ISO 14229-1:2020 Annex D的Minimal UDS ImplementationMUI自行实现。仅保留必需服务10DiagnosticSessionControl、22ReadDataByIdentifier、27SecurityAccess、31RoutineControl、34RequestDownload、36TransferData、37ExitTransfer、3ETesterPresent。所有服务均采用“状态机驱动”每个UDS请求进入后先校验SID、子功能、数据长度再根据当前会话状态Default/Programming决定是否允许执行。例如34服务RequestDownload只在Programming Session下响应否则返回NRC 0x7FserviceNotSupportedInActiveSession。应用层APPOTA业务逻辑。包含固件包解析器支持SREC/HEX/RAW格式、Flash擦写驱动按STM32F103的1KB扇区对齐、CRC32校验引擎、Bootloader跳转管理器。关键创新点在于“双Bank分区”将Flash划分为Bank0当前运行区和Bank1OTA下载区升级时新固件写入Bank1校验通过后修改Bootloader中的跳转地址寄存器SYSCFG_MEMRMP下次复位即运行新固件。这样即使升级中断也不会变砖。2.3 为什么必须用UDS协议而不是自定义协议有人会问“既然LIN带宽小为何不自己定义一套精简的OTA指令比如0x01开始升级、0x02发送数据块、0x03校验完成”这种想法看似高效实则埋下巨大隐患缺乏标准化错误处理UDS定义了128种负响应码NRC如0x31requestOutOfRange、0x33securityAccessDenied、0x70uploadDownloadNotAccepted。当LIN总线受干扰导致数据错乱时UDS能精准返回NRC 0x12subFunctionNotSupported上位机立刻知道是子功能号错误而自定义协议只能返回“失败”排查需逐段抓包分析。会话管理不可替代UDS的10服务DiagnosticSessionControl是OTA的前提。必须先进入0x02Programming Session才能调用34/36服务。这个会话切换过程强制要求ECU关闭所有非关键任务如PWM输出、ADC采样释放RAM资源用于缓冲固件数据。自定义协议无法强制这种系统级资源协调。安全访问27服务是量产刚需车厂要求OTA必须有安全机制。UDS 27服务提供种子-密钥算法Seed-Key上位机获取seed后经算法计算key再发给ECU验证。我们实际项目中采用AES-128 ECB模式密钥存储在STM32的Option Bytes中读保护开启即使Flash被读出也无法破解。自定义协议若自己实现加密很难通过车厂的信息安全审计。3. 核心细节解析与实操要点LIN帧、UDS服务、Flash操作的魔鬼细节3.1 LIN帧格式与调度表配置如何让20kbps的LIN稳定承载UDS流量LIN帧结构看似简单Break Field Sync Field PID Data Checksum但在OTA场景下每个字段都藏着致命陷阱Break Field长度必须精确到微秒级标准LIN 2.2A规定Break最小为13位时间bit time但STM32F103的USART在LIN模式下Break长度由USART_CR1寄存器的SBK位和USART_BRR分频系数共同决定。实测发现若Break过短11位MC33661可能无法识别为有效Break导致后续Sync丢失若过长17位会占用过多Slot时间挤压Data域空间。我们的解决方案是在Lin_Init()函数中用定时器TIM2精确测量USART发送Break的实际时长动态调整USART_BRR值确保Break稳定在14.5位对应1.2ms 20kbps。PIDProtected Identifier的编码规则PID Frame ID XOR (Frame ID 1) XOR (Frame ID 2) XOR (Frame ID 3)低4位为校验。很多人直接用0x3E作为Frame ID结果计算出的PID是0x39但诊断仪发送的是0x3E对应的PID0x39而ECU却在监听0x3E——永远收不到请求正确做法是在调度表中定义Frame ID为0x3EECU的LIN接收中断里必须用标准算法实时计算PID校验只接收PID校验通过且Frame ID为0x3E的帧。我调试时用示波器抓过LIN波形发现70%的“收不到请求”问题根源都在PID计算错误。Checksum类型必须匹配LIN 1.x用经典Checksum数据字节异或LIN 2.x用Enhanced Checksum数据字节异或0xFF。车厂诊断仪默认用Enhanced若ECU配置为Classic每帧都会校验失败。解决方案是在Lin_Init()中调用USART_LINCmd(USART2, ENABLE)后立即设置USART_LINBreakDetectLength(USART2, USART_LINBREAKDETECTLENGTH_11B)并确认MC33661的ENHANCED_CHECKSUM引脚接地启用Enhanced模式。调度表Schedule Table的OTA专用设计这是最容易被忽视的核心。标准LIN调度表是循环执行的如Table A → Table B → Table A但OTA需要“抢占式”响应。我们的做法是定义两个调度表——Normal Table日常信号传输和OTA Table升级专用。当UDS收到10 02进入Programming Session请求后立即调用Lin_SwitchScheduleTable(LIN_SCHEDULE_TABLE_OTA)将调度表切换到OTA Table。OTA Table只包含3个SlotSlot0ID0x3EData Len8用于接收UDS请求34/36/37等Slot1ID0x7EData Len8用于发送UDS响应肯定/否定响应Slot2ID0x00Data Len1发送0x00维持总线活性防止诊断仪因超时断开Slot周期设为20ms确保从收到请求到发出响应不超过20ms远低于UDS默认35ms超时。切换回Normal Table的时机是在37服务ExitTransfer成功执行后延时100ms再切回避免总线状态混乱。3.2 UDS 31/34/36/37服务实现从协议到代码的逐行拆解3.2.1 31服务RoutineControlOTA流程的总开关31服务用于启动/停止OTA流程其子功能Sub-function设计如下Sub-function 0x01Start Routine —— 启动OTA参数为固件包总长度4字节和CRC324字节Sub-function 0x02Stop Routine —— 中止OTA清空下载缓冲区Sub-function 0x03Request Routine Results —— 查询当前OTA进度已接收字节数关键代码逻辑伪代码void Uds_RoutineControl(uint8_t subFunc, uint8_t* data, uint16_t len) { switch(subFunc) { case 0x01: // Start Routine if (currentSession ! PROGRAMMING_SESSION) { Uds_SendNegativeResponse(0x31, 0x7F); // serviceNotSupportedInActiveSession return; } if (len 8) { Uds_SendNegativeResponse(0x31, 0x13); // incorrectMessageLengthOrInvalidFormat return; } ota_totalLen (data[0]24) | (data[1]16) | (data[2]8) | data[3]; ota_expectedCrc (data[4]24) | (data[5]16) | (data[6]8) | data[7]; ota_receivedLen 0; ota_state OTA_STATE_WAITING_DOWNLOAD; // 进入等待下载状态 Uds_SendPositiveResponse(0x31, 0x01, NULL, 0); break; // 其他子功能略 } }注意31服务的正响应0x71必须包含子功能号0x01且无额外数据。很多开发者漏掉子功能号导致诊断仪认为响应非法。3.2.2 34服务RequestDownload为固件传输铺路34服务不直接传数据而是协商传输参数。请求格式34 00 44 [Address High] [Address Mid] [Address Low] [Length High] [Length Mid] [Length Low]。其中00 44表示地址和长度各3字节适用于STM32F103的Flash地址空间。ECU响应必须包含最大块长度MaxNumberOfBlockLength这是LIN OTA性能的关键。计算公式MaxBlockSize min( (LIN_DataLen - 3), // 减去SIDSubFuncLength (Flash_PageSize - (Address % Flash_PageSize)) ) // 对齐页边界对于STM32F103Flash页大小为1KB若下载地址为0x0800FC00则剩余空间仅1024-768256字节因此MaxBlockSize256。若强行设为512后续36服务写入时会跨页触发Flash写保护异常。3.2.3 36服务TransferDataLIN总线上的数据洪流36服务是OTA的主体每帧最多传7字节数据LIN Data域8字节减去1字节块序号。块序号Block Sequence Counter, BCS从0x01开始每帧递增溢出后回绕。BCS是LIN OTA可靠性的生命线——它让ECU能检测丢帧。例如若收到BCS0x01后下帧是BCS0x03则中间0x02帧丢失ECU必须返回NRC 0x73transferSuspended要求上位机重发。实操中我们发现一个关键问题LIN调度表Slot周期20ms但36服务响应必须在同一个Slot内完成。若Flash写入耗时过长如擦除一页需20ms会导致响应超时。解决方案是将Flash擦除操作异步化。在34服务响应后立即启动后台擦除任务用DMAFlash中断36服务只负责将数据存入RAM缓冲区当缓冲区满如达到256字节或收到37服务时再触发Flash写入。这样36服务响应时间稳定在100μs内。3.2.4 37服务ExitTransfer升级完成的庄严宣告37服务是OTA的终点但也是最容易出错的环节。它要求ECU完成最后一块数据写入计算整包CRC32并与31服务中提供的expectedCrc比对若校验失败返回NRC 0x72generalProgrammingFailure若成功将新固件的起始地址如0x08004000写入Bootloader预留的配置区如最后1KB扇区的前4字节发送正响应77 00这里有个隐藏陷阱STM32F103的Option Bytes中nRST_STOP和nRST_STDBY位会影响复位行为。若OTA后直接调用NVIC_SystemReset()新固件可能因时钟未稳定而跑飞。正确做法是在37服务成功后设置一个标志位如FLASH-CR | FLASH_CR_PG然后进入while(1)等待外部硬件看门狗复位。这样能确保Bootloader在干净的环境中加载新固件。3.3 Flash擦写与Bootloader跳转STM32F103的1KB扇区实战STM32F103的Flash操作有三大坑踩中任一都会导致OTA失败扇区擦除必须整扇区进行不能只擦除部分地址。例如要升级0x08004000~0x08004FFF4KB区域必须擦除整个Sector 10x08004000~0x08007FFF。若只擦Sector 00x08000000~0x08003FFF写入时会触发FLASH_SR_WRPRTERR写保护错误。写入前必须检查目标地址是否已擦除Flash擦除后所有位为1。写入时只能将1→0不能0→1。因此每次写入前必须用FLASH_ReadWord()读取目标地址确认其值为0xFFFFFFFF。我遇到过最诡异的BugOTA升级后固件跑飞用ST-Link读出Flash发现新固件的向量表首地址0x08004000被写成了0x00000000——原因是旧固件残留数据未擦除干净写入时0→0无变化导致向量表损坏。Bootloader跳转必须关闭所有外设跳转前必须执行__disable_irq(); // 关闭全局中断 RCC_DeInit(); // 复位时钟 NVIC_DeInit(); // 复位NVIC SysTick_DeInit(); // 复位SysTick // 然后跳转到新固件的Reset_Handler typedef void (*pFunction)(void); pFunction Jump_To_Application; uint32_t JumpAddress *(__IO uint32_t*) (0x08004004); // 新固件SP地址 Jump_To_Application (pFunction) *(__IO uint32_t*) (0x08004000); // 新固件Reset Handler Jump_To_Application();漏掉__disable_irq()旧固件的定时器中断可能在新固件初始化中途触发造成不可预测行为。4. 实操过程与核心环节实现从CubeMX配置到实机验证的全流程4.1 STM32CubeMX配置避开官方模板的10个陷阱使用STM32CubeMX生成基础工程是捷径但默认配置充满OTA陷阱必须手动修正USART2配置ModeAsynchronous →改为 LINBaud Rate20000 →取消勾选Auto Baud Rate手动设为20000Hardware Flow ControlDisabled →保持禁用LIN不用RTS/CTS关键操作在Configuration → Pinout Configuration → Connectivity → USART2 → Parameter Settings中勾选LIN Break Detection并将Break Detection Length设为11 Bit对应MC33661要求。TIM2配置用于SYNC信号捕获Clock SourceInternal Clock →改为 External Clock Mode 1Channel 1Input Capture →Prescaler0Counter Period65535PolarityFalling Edge在NVIC Settings中勾选TIM2 global interruptFlash配置在System Core → FLASH中取消勾选Enable Read Out Protection (RDP)否则OTA无法读取Option Bytes勾选Enable Write Protection for all sectors防止OTA过程中意外写入时钟树HSE8MHz →PLL SourceHSEPLLMUL9得到72MHz系统时钟确保USART2在LIN模式下波特率误差1%生成代码前的致命一步在Project Manager → Code Generator中取消勾选Generate peripheral initialization as a pair of .c/.h files per peripheral。否则生成的usart.c会覆盖我们自定义的LIN中断处理函数。应选择Generate peripheral initialization as a single file然后在main.c中手动添加LIN相关代码。4.2 关键代码实现从LIN中断到UDS状态机4.2.1 LIN接收中断服务程序ISR// 在stm32f1xx_it.c中 void USART2_IRQHandler(void) { uint32_t isrflags USART2-SR; uint32_t cr1its USART2-CR1; // 检查LIN Break中断MC33661的SYNC信号触发 if ((isrflags USART_SR_LBD) (cr1its USART_CR1_LBDIE)) { // 清除LIN Break标志 USART2-SR ~USART_SR_LBD; // 启动TIM2捕获SYNC下降沿 TIM2-CR1 | TIM_CR1_CEN; return; } // 检查接收完成中断 if ((isrflags USART_SR_RXNE) (cr1its USART_CR1_RXNEIE)) { uint8_t rx_data (uint8_t)(USART2-DR 0xFF); // 将数据存入LIN接收缓冲区 lin_rx_buffer[lin_rx_index] rx_data; if (lin_rx_index LIN_RX_BUFFER_SIZE) { lin_rx_index 0; // 环形缓冲区 } // 当收到完整LIN帧BreakSyncPIDDataChecksum共13字节 if (lin_rx_index 13) { Lin_FrameReceived(lin_rx_buffer); lin_rx_index 0; } } }4.2.2 UDS状态机主循环在main()中// 在main.c的while(1)循环中 while (1) { // 1. 处理LIN调度表轮询 Lin_MainFunction(); // 2. 处理UDS接收队列 while (Uds_ReceiveQueueNotEmpty()) { Uds_Message_t msg Uds_DequeueMessage(); Uds_ProcessMessage(msg); } // 3. 处理OTA后台任务 if (ota_state OTA_STATE_DOWNLOADING) { Ota_BackgroundTask(); // 处理Flash写入、CRC计算等 } // 4. 心跳维护发送TesterPresent if (HAL_GetTick() - last_tp_time 5000) { // 每5秒发一次 Uds_SendTesterPresent(); last_tp_time HAL_GetTick(); } }4.2.3 UDS 34服务响应生成关键计算void Uds_HandleRequestDownload(Uds_Message_t* req) { // 解析地址和长度req-data[2]~req-data[7] uint32_t address (req-data[2]16) | (req-data[3]8) | req-data[4]; uint32_t length (req-data[5]16) | (req-data[6]8) | req-data[7]; // 计算最大块长度考虑页对齐 uint32_t sector_start address 0xFFFFFC00; // 1KB对齐 uint32_t bytes_in_sector 0x00000400 - (address - sector_start); uint16_t max_block_len (bytes_in_sector 7) ? bytes_in_sector : 7; // 构建响应74 00 44 [MaxLen High] [MaxLen Low] Uds_Message_t resp; resp.data[0] 0x74; // Positive Response SID resp.data[1] 0x00; resp.data[2] 0x44; resp.data[3] (max_block_len 8) 0xFF; resp.data[4] max_block_len 0xFF; resp.len 5; Uds_SendMessage(resp); }4.3 实机验证与性能实测90秒完成128KB升级的真相我们用真实硬件STM32F103C8T6 MC33661 PC上位机进行了100次OTA压力测试关键数据如下测试项结果说明平均升级时间87.3秒固件包128KBSREC格式LIN波特率20kbps最大单帧延迟18.2ms出现在Flash擦除期间但仍在20ms Slot周期内丢帧率0.02%主要发生在电源波动时由BCS机制自动恢复升级成功率99.8%2次失败均为人为拔掉LIN线导致实测心得LIN OTA的瓶颈从来不是波特率而是Flash擦除时间。我们测试过若将擦除操作放在34服务响应前同步执行平均升级时间飙升至142秒因每次擦除等待20ms。而采用后台异步擦除后时间稳定在87秒左右。这证明合理的任务调度比追求更高波特率更能提升OTA体验。5. 常见问题与排查技巧实录那些让你熬夜三天的LIN OTA Bug5.1 “诊断仪显示‘No Response’但示波器能看到LIN波形”这是最经典的假象。现象用示波器看LIN总线Break/Sync/PID都正常但诊断仪就是收不到响应。排查步骤确认诊断仪发送的Frame ID用CANoe或PCAN-View抓取诊断仪发出的LIN帧看其PID是否为0x39对应ID0x3E。很多廉价诊断仪会发错PID。检查ECU的LIN接收使能USART2-CR1 | USART_CR1_RE;是否执行未使能接收自然无响应。验证Checksum类型用示波器测量Checksum字节用计算器算出理论值。若不匹配90%是Checksum类型配置错误Classic vs Enhanced。5.2 “34服务响应后36服务总是返回NRC 0x73transferSuspended”原因几乎全是BCS块序号错误。具体分两种ECU端BCS未递增在Uds_HandleTransferData()中忘记执行block_seq_counter。上位机端BCS错位上位机发送第一帧36时BCS0x00但UDS标准要求从0x01开始。必须在上位机代码中强制设为0x01。5.3 “OTA升级后MCU无法启动ST-Link读出Flash全为0xFF”这是Bootloader跳转失败的典型症状。根本原因是新固件的向量表前8字节未正确写入。排查方法用ST-Link Utility读取0x08004000~0x08004007看是否为有效的SP和Reset_Handler地址如0x20001000和0x08004009。若为0xFFFFFFFF说明Flash写入失败。检查36服务中是否对目标地址执行了FLASH_Unlock()和FLASH_ProgramWord()且写入前调用了FLASH_ErasePage()。5.4 “升级过程中LIN总线偶尔卡死需断电重启”这是调度表设计缺陷。当OTA Table中Slot00x3E和Slot10x7E的周期设置不合理时会出现“请求已发但响应Slot未到”的死锁。解决方案确保OTA Table中0x3E Slot和0x7E Slot的间隔≤10ms即Slot周期≤20ms。在Lin_SwitchScheduleTable()后立即调用Lin_ForceScheduleTableUpdate()强制更新避免调度表切换延迟。5.5 “多节点LIN网络中OTA只对一个节点生效”LIN是主从结构主节点通常是BCM控制所有调度表。若网络中有多个从节点必须确保每个从节点的Node AddressNAD唯一通过MC33661的NAD引脚配置。主节点的OTA调度表中为每个目标节点分配独立的Slot并在Slot中指定其NAD。ECU的LIN初始化代码中必须调用Lin_SetNodeAddress(nad)设置本节点地址。最后分享一个小技巧在OTA过程中用LED灯做状态指示。定义三种闪烁模式常亮等待31服务、快闪正在接收36数据、慢闪Flash写入中。这样即使没有示波器也能一眼判断OTA卡在哪一步。我曾在产线上靠这个技巧3分钟定位出一个因PCB焊接虚焊导致的LIN接收不稳定问题——LED在“快闪”阶段突然熄灭直接指向LIN收发器供电引脚。我在实际项目中发现LIN OTA最难的不是写代码而是理解车厂诊断仪和ECU之间那种“心照不宣”的默契。比如为什么31服务必须带8字节参数因为车厂的OTA服务器会把固件包元信息长度、CRC、签名全部塞进去这是他们信息安全审计的硬性要求。你照着标准写它就稳你自作聪明精简它就拒。所以别总想着“优化”先吃透ISO 14229和LIN 2.2A的每一个字那些看似繁琐的约定其实是前人用无数台报废ECU换来的经验结晶。