1.TC1001—汽车级便携式CAN总线接口
2.UDS 的26个诊断服务之10服务 诊断会话控制服务
3.FOTA技术专栏（一）—UDS刷写
4.Bootloader开发：初识Bootloader
5.bootloader
6.一文了解Bootloader

TC1001—汽车级便携式CAN总线接口

       同星智能引领创新，TC——汽车级便携式CAN总线接口模块</

       TC是由同星智能精心打造的一款专业级便携式CAN总线接口解决方案，其设计旨在为汽车电子领域的开发者和工程师提供高效、便捷的连接工具。这款模块以1M bps的惊人速度，通过高速USB2.0接口无缝对接PC，如何修改表白源码Windows系统无需驱动，无缝兼容，展现极高的灵活性和易用性。

       卓越功能，满足专业需求</

       TC不仅具备TICPSH信息安全测试功能，还支持多种文件格式，如dbc、a2l、blf、asc和arxml，确保在汽车级CAN总线开发、仿真、测试、标定和诊断各个环节都能得心应手。二次开发API接口兼容Windows和Linux，让设备轻松融入各种设备或软件系统，增强集成度。

       硬件特性，彰显专业品质</

精准时间戳</: 硬件报文时间戳精度达到us级，满足高级应用的高精度需求。

便携与集成</: 独特设计的安装孔，无论是车载设备还是仪表板，都能轻松安装，实现无缝集成。

隔离保护</: DCV的CAN通道隔离，确保数据传输的安全性和抗干扰能力。

全面功能支持</: 支持UDS诊断、CCP标定，Flash Bootloader以及各种文件格式的记录和回放，满足多元化应用场景。

终端电阻</: 内置欧姆可软件配置终端电阻，提供灵活的adb 源码编译 rsa连接选项。

许可证加载</: 可加载TSMaster所有付费许可证，扩展功能无界。

       技术参数，保障稳定运行</

       TC采用PC端USB2.0接口和CAN端DB9接口，Windows系统免驱设计，同时支持Linux系统，硬件缓存确保数据完整性。它兼容CAN2.0A和B协议，支持5Kbps至1Mbps的波特率，每秒发送和接收报文高达,个，确保数据传输的高效稳定。

       工作温度范围极广，从-℃到℃，适应各种环境挑战，确保TC在严苛的汽车环境中也能保持高性能和可靠性。

UDS 的个诊断服务之服务 诊断会话控制服务

       在汽车诊断领域，UDS（统一诊断服务）协议是关键的一部分，它涵盖了个诊断服务，其中的服务名为诊断会话控制服务。这个服务的SID为0x，请求固定为2个字节，包含SID和低7位的子功能。这个服务允许ECU（电子控制单元）进入或退出特定的诊断会话。

       在UDS中，诊断会话控制服务通常涉及到三个会话：默认会话、编程会话和扩展诊断会话。默认会话在ECU上电后自动启用，通常限制了部分诊断服务的执行。在默认会话下，ECU不能执行大多数诊断服务，也无法读取或写入大量诊断相关的数据。

       在默认会话下，允许使用的服务有：是否允许响应事件服务取决于具体实现；安全数据标识符和安全内存区域的使用需要通过安全访问服务，因此需要非默认诊断会话；动态定义数据标识符可以在默认和非默认诊断会话中进行；安全常规控制服务同样需要安全访问服务，因此在非默认诊断会话下运行；而需要主动停止的常规控制服务也要求非默认会话。

       编程会话通常只由bootloader使用，是物流系统源码 APP一个特定的诊断环境。扩展诊断会话则是更全面的诊断环境，诊断仪启动后通常会引导ECU进入此模式，允许执行更多诊断服务。为了保持ECU在非默认诊断会话中，诊断仪需要周期性地发送特定服务（如0x3E），ECU接收到此服务后才知会诊断仪，从而维持在非默认会话状态。

       综上所述，诊断会话控制服务（服务）在UDS协议中扮演着重要角色，通过控制诊断会话的进入和退出，确保ECU在适当的时间执行合适的诊断服务，为汽车诊断提供了灵活性和安全性。

FOTA技术专栏（一）—UDS刷写

       FOTA技术专栏（一）—UDS刷写

       随着系列文章的深入，我们从本期开始将专注于FOTA技术的详细介绍。首先呈现的是关于整车控制器FOTA技术实现中的关键底层技术—UDS刷写。UDS，即统一诊断服务，是控制器软件升级流程的基础，尤其对于采用ETH/CAN/LIN等总线通信的车载传统控制器，如以MCU为核心的系统，主要通过诊断上位机（Tester）发送诊断服务命令进行刷写。

       UDS刷写涉及控制器的Bootloader支持，它是启动过程中的关键部分，负责初始化硬件、建立内存映射和引导操作系统。Bootloader在控制器软件升级中负责擦除旧程序并写入新数据。UDS协议，作为ISO标准的应用层协议，定义了基于Bootloader的刷写流程，主机厂OEM会根据此协议制定企业级的诊断刷写规范。

       刷写流程通常分为线下和线上两种。线下通过诊断仪连接车辆OBD口，执行ISO定义的刷写流程，而线上FOTA技术的普及使得升级主控作为上位机，从云端下载更新包后，按照预设的刷写流程对车辆控制器进行升级。UDS线上刷写利用了FOTA技术的Lol 走砍源码成熟，简化了升级过程。

       UDS刷写流程包括预编程、主编程和后编程阶段，涉及网络准备、数据传输和条件设置。其中，预编程阶段检查升级条件，提升网络速度，后编程阶段则支持多路并行刷写，以提高升级效率。当前，FOTA升级一般为串行，但并行刷写在产线诊断仪中已经实现，有助于提升生产效率。

       下期专栏将深入探讨智能控制器的升级方式，如A/B升级。同时，我们诚挚推荐作者花费两年时间整理的自动驾驶科普书籍，从硬件、软件和行业多角度介绍自动驾驶，期待您的关注与支持。

Bootloader开发：初识Bootloader

       Bootloader是嵌入式系统中的关键组件，它在设备上电后启动，负责初始化硬件并加载操作系统或固件。不同于汽车嵌入式开发中的Boot Software，它由Boot Manager和Reprogramming Software组成，主要任务是管理和更新Application Software。Bootloader的存在是为了确保在Application Software出现故障时，能够安全地进行更新，避免车辆无法使用。

       当Application Software出现问题时，如果没有Bootloader，需要物理替换整个ECU，而有了Bootloader，只需更新Application即可。上电流程中，Bootloader首先检查更新请求和程序有效性，猎人时空源码然后决定是否加载新软件。如果需要更新，它会执行一系列步骤：从预编程检查、编程会话的安全验证，到下载和擦除旧软件、写入新软件指纹、配置信息，最后是网络恢复和ECU重置。

       汽车ECU的Application Software升级通常遵循UDS规范，通过严格的验证确保操作的合法性和数据完整性。关注"开心果 Need Car"公众号，可以一起探讨Autosar开发中的问题和解决策略。关于Bootloader的更多细节，可以参考百度百科和ISO -1标准。

bootloader

       引导程序概念：引导程序是系统上电或复位后运行的一段小程序。它的主要任务是将系统的软硬件环境带到一个合适的状态，为最终调用应用程序准备好正确的环境。

       主要功能：引导程序完成处理器和周边电路正常运行所需要的初始化工作。例如，处理器和周边电路在上电之后，可能处于不稳定状态，需要时间稳定。此时，引导程序会等待直到稳定后，再开始正常运行。

       两种操作模式：引导程序在单片机启动加载模式和下载模式下操作。在启动加载模式下，引导程序负责加载应用程序到内存；在下载模式下，引导程序负责接收应用程序并将其加载到内存。

       进入引导程序的方式常见于可烧写目标代码格式。常见的格式包括Intel十六进制目标文件格式、Motorola S-Record文件格式等。从主机下载文件时，需要通过引导程序的通信协议完成。

       在引导程序中，基于CCP将程序、数据保存于Flash中，CANape提供两种Flash编程机制。在MCU中，Flash的编程和擦除受到S/SX中的Block对的影响。通常，引导程序在RAM中运行，通过搬移代码到RAM中实现。Link规格文件的编写对于引导程序的构建至关重要。为了保护引导程序，Flash保护功能将引导程序的映像保护起来，防止擦除和编程操作，确保即使引导程序运行异常，系统仍能恢复。

       引导程序的Flash保护方案以SXE为例，首先需编写针对硬件环境的Flash擦写函数，并集成于引导程序中。在CCP命令处理模块的子函数中调用该擦写函数，实现对Flash的保护。

       引导程序的Flash部分包含Flash kernel，当ECU需要重新编程Flash时，引导程序通过UDS下载Flash kernel至RAM，并获得ECU控制权，执行新的应用程序写入Flash中。这个过程涉及两次下载：首先接收主机传来的引导程序至RAM并开始运行，然后RAM中的引导程序负责更新代码和数据。

       ECU引导程序代码模块主要包括初始化、通信和Flash擦写三部分。初始化模块负责硬件电路和内存的初始化。通信模块与PC通信，分为CAN Driver、CCP Driver两部分。CAN Driver实现CAN数据的收发和解包功能。CCP Driver包含命令处理机和命令应答处理机，负责接收和发送参数。Flash擦写模块包含多个文件，涉及RAM缓存、高压执行程序转换、数据传输和Flash擦除与写入的合理安排。

       引导程序在ECU中存储于特定位置，如VCU Flash的0xF-0xFF存储区。当进行应用程序升级时，复制Flash编程代码到RAM缓冲区，验证工程师身份后，引导程序执行升级后的应用程序。PC端引导程序模块包含S-record目标文件格式、通信模块、命令序列处理机及安全机制等。

一文了解Bootloader

       多数Bootloader含有两种模式：启动加载模式及下载模式，汽车软件开发者往往关注后者，以满足客户对CAN Bootloader的特定需求。接下来，我们将聚焦于从CAN Bootloader的一般要求展开，提供整个实现过程的概览。

       升级基于CAN的系统通常需遵循以下维度，针对单个节点、单一节点功能设计以及进入Bootloader模式的方式。

       针对单节点升级，使用CAN网络需确保不干扰其他节点。通过定义每个ECU的诊断ID来实现点对点操作。标准中常指定两个接收ID（功能寻址ID、物理寻址ID）和一个发送ID（诊断发送ID），确保升级过程无干扰。

       在CAN网络中实现数据更新时，master ECU需有效传输至Slave ECU，随后由后者对自身Flash进行操作。数据传输需保证准确性、安全性和可靠性，可通过执行UDS实现master与slave间的交互，通过握手协议与服务例程等流程满足这一需求。

       进入Bootloader通常有多种方法。依据OEM的需求，使用较为普遍的方式是通过session跳转，并启动特定命令将应用程序转移到Bootloader模式。进入此模式时需避免触发的条件过于广泛，以防止误触。

       Bootloader的设计需考虑多个要求，其中包括但不限于传输协议的可靠性、特定操作逻辑的实现、与应用程序的互动机制等。

       OEM对Bootloader的基本要求涉及刷写过程，大致分为前处理、刷写和后处理阶段。前处理阶段涉及系统准备，刷写阶段实现点对点交互，后处理阶段主要执行ECU状态恢复、配置更新等。

       基于这些要求，Bootloader需具备以下功能：

       1. 在最小控制系统的支撑下，Bootloader实现基本操作，如循环执行主函数，检测是否需要转向应用程序，并接收/处理通讯接口数据。

       2. 以中断模式实现CAN通讯驱动，包括配置波特率及其他相关参数，对数据传输路径进行初始化，并定义接收与发送接口。

       3. 内存驱动确保对PFlash和DFlash的读写操作，以及实现存储结构（如Hex或S格式的代码与数据）的分发与管理。

       4. 集成CRC校验与加密算法，确保数据完整性和安全性。

       5. 设定交互逻辑与上层应用程序需求，如数据交换、参数校验等。

       以上概述了Bootloader的主要内容与设计实现。欲深入了解可关注本公众号：汽车与基础软件。更多技术细节与实现方法可参阅：STM Bootloader实施指南。

SK UDS Bootloader开发-下位机篇-FlashDriver的制作

       本文详细介绍了如何为SK UDS Bootloader开发制作Flash Driver的过程。首先，我们回顾了上一篇文章中对 SK UDS Bootlodaer 开发中UDS相关更改的介绍，并指出本文将着重于Flash Driver的制作。

       参考NXP官网提供的SK UBL，发现其中的FlashDriver并未包含Flash擦除和写入的函数，仅涉及寄存器配置的修改。这导致，在Flash Driver未写入时，调用Flash擦除和写入功能无法实现预期效果。因此，实际的FlashDriver功能仅由C_Ip_StartSequence函数实现。

       针对ld文件配置，考虑到FlashDriver应放置在起始地址为0x的RAM区域，boot程序中的配置与之对应。通过判断Flash_IsFlashDriverSoftwareData，确保FlashDriver的位置及大小正确。

       在bootloader中加入FlashDriver代码，并通过编译、使用hexview提取函数地址，完成代码生成。在main函数中调用该函数以确保FlashDriver功能实现。提取出对应的ram区域的hex文件后，FlashDriver即制作完成。

       为了正确使用FlashDriver，实际函数中在初始化阶段调用C_Ip_StartSequenceInit获取RAM区域地址。同时，对C_IP.c进行修改，增加宏定义与初始化获取RAM区域的函数。此外，还需对C_Ip_MainInterfaceSectorErase和C_Ip_MainInterfaceWrite函数进行相应的修改。

       在处理FLASH_HAL_WriteData函数的bug时，通过修正第行代码，解决了潜在问题。至此，FlashDriver的制作与使用流程完成。

       最后，本文总结了关于FlashDriver提取与使用的关键点，并预告了后续内容将涉及Bootloader调试中的修改点以及APP的实现。若有帮助，请点赞、关注、收藏或转发，您的鼓励是对我最大的支持。欢迎加入《汽车电子学习笔记》的微信公众号，文章内容将同步更新。

UDS on CAN的BootLoader上位机开发demo

       UDS on CAN的BootLoader上位机开发demo概述

       在汽车电子系统中，BootLoader扮演着至关重要的角色，它通过CAN总线报文，遵循ISO和ISO标准，以及主机厂自定义内容，对ECU进行程序升级。这个过程分为预编程、主编程和后编程三个阶段，确保系统的安全性和一致性。

       预编程阶段，诊断工具首先通过物理寻址和功能寻址控制ECU进入扩展会话模式，检查编程条件，关闭DTC记录，禁止非诊断报文，为下载做准备。主编程阶段则进行单个ECU的编程，通过安全访问、FlashDriver下载和指纹数据写入等步骤确保软件安全下载。后编程阶段重启ECU，恢复总线通信和故障码记录。

       上位机软件开发采用C#和Visual Studio ，采用分层设计，支持Kvaser、USBCAN等硬件驱动，具有波特率设置和两路软件通道，能处理S、Hex和Bin文件，通过ISO -2和ISO -3协议进行数据传输。这个开源项目可以广泛应用于各类ECU的软件更新，其通用性和标准化操作使其在汽车行业具有实用性。

       关于更多详细教程和汽车电子开发测试知识，请查看相关链接。