基于UDS的bootloader开发。 包括诊断协议栈，网络协议栈，瑞萨底层驱动，通过周立功can盒通讯，实现上位机对单片机的程序更新功能，同时包含主机厂和供应商开发资料，可以很好的参考学习。
最近在搞车载ECU的bootloader开发，发现UDS协议栈这玩意儿真是让人又爱又恨。今天就跟大伙儿唠唠怎么用瑞萨RH850单片机整出个能远程刷写的bootloader，顺便分享几个开发时踩过的坑。
诊断协议栈这块最要命的是会话控制，像0x10切会话这种操作，很多新手容易栽在定时器配置上。看这段代码：
void HandleSessionControl(uint8_t sessionType) { static uint32_t activeSessionTimer = 0; if(sessionType == DEFAULT_SESSION) { // 默认会话下关闭安全访问 SecurityUnlockState = SECURITY_OFF; activeSessionTimer = 0; } else { // 扩展会话激活后启动30秒超时 activeSessionTimer = GetSystemTick() + 30000; } CurrentSession = sessionType; SendPositiveResponse(SID_SESSION_CONTROL, &sessionType, 1); }这里有个骚操作——用系统滴答计时代替独立定时器，省了硬件资源。但注意GetSystemTick()要确保在1ms中断里自增，否则时间不准会搞出幽灵bug。
网络层处理CAN报文时，瑞萨的CAN驱动有个坑爹的地方：接收FIFO的配置必须严格按手册来。有次调试发现CAN盒死活收不到响应，最后发现是波特率计算时少了个零：
void CAN_Init(void) { CAN0.CTMR.BIT.TPM = 0; // 使用内部时钟 CAN0.BITREG.BIT.BRGC = (BRP_VALUE << 16) | (TSEG1 << 8) | TSEG2; // 波特率计算公式：1Mbps时BRP=0, TSEG1=4, TSEG2=3 // 实际调试发现寄存器值要减1，瑞萨手册里的小字说明 }周立功CAN盒的API调用也有讲究，他们的ZLGCanApi.dll有个隐藏功能——异步发送模式比同步模式快3倍。但要注意线程安全问题，最好加个互斥锁：
from ctypes import * can_dll = WinDLL('ZLGCanApi.dll') def send_can_msg(msg): with threading.Lock(): can_dll.ZCAN_Transmit(handle, byref(msg), 1)刷写流程中最容易翻车的是Flash驱动。RH850的Flash操作必须关中断，但很多开发板例程里没提醒这事。有个血的教训：刷写时突然来个中断，直接导致Flash锁死，最后只能上J-Link强行解锁。
主机厂的诊断规范文档里经常藏着魔鬼细节。比如某德系厂商要求编程会话下必须支持0x3E服务保活，但响应时间不能超过15ms。这时候就得在任务调度上动脑筋：
void Task_3E_KeepAlive(void) { if(CurrentSession == PROGRAMMING_SESSION) { // 使用RTOS的软件定时器触发响应 if(osTimerExpired(KeepAliveTimer)) { SendPositiveResponse(SID_TESTER_PRESENT, NULL, 0); osTimerReset(KeepAliveTimer); } } }供应商给的参考代码也别全信，有次发现他们的CRC校验算法居然用的是XMODEM标准，而主机厂要求SAE-J1850，差点导致项目延期。后来自己重写了校验函数：
uint16_t CalculateCRC_J1850(uint8_t *data, uint32_t len) { uint16_t crc = 0xFFFF; while(len--) { crc ^= *data++; for(int i=0; i<8; i++) { if(crc & 0x0001) { crc = (crc >> 1) ^ 0x8408; } else { crc >>= 1; } } } return ~crc; }最后给个忠告：做bootloader一定要留后门！我们项目里偷偷做了个通过连续三次非法会话切换触发紧急下载模式的功能，结果在产线救回了好几个锁死的ECU。这事儿主机厂不知道，知道了估计得骂街，但关键时刻真能救命啊。
