/*
 *                        ___           ___                                     ___           ___          _____          ___           ___
 *         _____         /  /\         /  /\          ___                      /  /\         /  /\        /  /::\        /  /\         /  /\
 *        /  /::\       /  /::\       /  /::\        /  /\                    /  /::\       /  /::\      /  /:/\:\      /  /:/_       /  /::\
 *       /  /:/\:\     /  /:/\:\     /  /:/\:\      /  /:/    ___     ___    /  /:/\:\     /  /:/\:\    /  /:/  \:\    /  /:/ /\     /  /:/\:\
 *      /  /:/~/::\   /  /:/  \:\   /  /:/  \:\    /  /:/    /__/\   /  /\  /  /:/  \:\   /  /:/~/::\  /__/:/ \__\:|  /  /:/ /:/_   /  /:/~/:/
 *     /__/:/ /:/\:| /__/:/ \__\:\ /__/:/ \__\:\  /  /::\    \  \:\ /  /:/ /__/:/ \__\:\ /__/:/ /:/\:\ \  \:\ /  /:/ /__/:/ /:/ /\ /__/:/ /:/___
 *     \  \:\/:/~/:/ \  \:\ /  /:/ \  \:\ /  /:/ /__/:/\:\    \  \:\  /:/  \  \:\ /  /:/ \  \:\/:/__\/  \  \:\  /:/  \  \:\/:/ /:/ \  \:\/:::::/
 *      \  \::/ /:/   \  \:\  /:/   \  \:\  /:/  \__\/  \:\    \  \:\/:/    \  \:\  /:/   \  \::/        \  \:\/:/    \  \::/ /:/   \  \::/~~~~
 *       \  \:\/:/     \  \:\/:/     \  \:\/:/        \  \:\    \  \::/      \  \:\/:/     \  \:\         \  \::/      \  \:\/:/     \  \:\
 *        \  \::/       \  \::/       \  \::/          \__\/     \__\/        \  \::/       \  \:\         \__\/        \  \::/       \  \:\
 *         \__\/         \__\/         \__\/                                   \__\/         \__\/                       \__\/         \__\/
 */

联系方式：

📧 e-mail: [email protected]

S32K1xx 的 CAN 接 周立功 USBCANFD-100U-mini，使用 ZCANPRO 软件的 ECU刷新 功能进行测试。在加载相应的安全访问算法 DLL 文件 📦 UDS_SecurityAccess 之后，通过相应的 UDS 服务将 📦 UDS_S32K144_FlashDriver 的 hex 文件下载至 📦 UDS_S32K144_Bootloader 在链接文件中为其预先指定起始地址的 RAM 空间中，并通过 Flash Driver 内实际包含的相应的 Flash 驱动函数的相对偏移量以及驱动函数本身来计算相应驱动函数的入口点在 RAM 内的偏移地址后，再通过函数指针的方式调用相应的编程、擦写、校验等 Flash API 以实现将 📦 UDS_S32K144_APP 烧写至 Flash 的 APP 片区，最终实现 ECU刷新 的整个 APP 更新流程。

📁 ZCANPRO_RefreshFlow_S32K144.zflash 为可被 ZCANPRO 的 ECU刷新 功能所加载的 UDS 刷新流程文件。

⚠️ 注意：S32K144-EVB 开发板需要 12V 独立供电，CAN Transceiver 方可正常工作。

🎲 已做通用性适配，目前一套代码理论同时支持多个型号，已测试 S32K144 和 S32K118 可以同时支持。

• 📦 UDS_SecurityAccess
• 📦 UDS_S32K144_Bootloader
• 📦 UDS_S32K144_FlashDriver
• 📦 UDS_S32K144_APP

• S32K144-EVB
• J-Link
• USBCANFD-100U-mini
• 12V External Power Supply

• S32 Design Studio for ARM Version 2.2
• ZCANPRO
• J-Flash

< 👌 已解决 > 关于 S32K144 APP 工程 调用 Flash_EraseFlashDriverInRAM() 会导致程序卡死的问题进行说明记录：

• 根据 Ozone 调试得知，实际现象为出现 HardFault ， HFSR 寄存器 FORCED 位被置 1，所以可以判断由其它 Fault 异常提升而来，实际为 UsageFault ， INVSTATE 位被置 1，如下图所示：
  • 
• 由于程序卡死的位置并不是每次都在同一位置，故初期的排查非常困难。由于同样的代码，在 S32K118 APP 工程 中被调用时，并不会产生该问题，所以需要从两个不同芯片的工程的不同之处寻找原因。经过比对，初步判断与两芯片的链接文件空间分配有关联，具体为两个芯片的 Flash Driver 所占用的 RAM 地址空间不同。其中，在 S32K144 的 Bootloader 工程 中，m_flash_driver 地址空间在 APP 工程 中会与 m_data 地址空间合并，从 Bootloader 跳转至 APP 时，会先调用 Reset_Handler 汇编函数，此汇编函数会进行相关初始化之后再跳转到 main 函数，其中在初始化时，会调用 init_data_bss() 函数，此函数其中的一个工作就是将位于 ROM 中（即 m_interrupts 地址空间内）的中断向量表拷贝到 RAM 中（即 m_data 地址空间内）的起始地址处，此时，如若在 APP 工程 中尝试调用 Flash_EraseFlashDriverInRAM() ，会对 0x1FFF8000 起始地址处连续 0x800 个字节的内容进行清零操作，而 0x1FFF8000 ~ 0x1FFF8800 地址空间段已经完全属于 m_data ，如若再执行 Flash_EraseFlashDriverInRAM() 则会将 RAM 中的中断向量表擦除，导致中断响应出现异常，故最终会导致程序卡死，详细配合以下截图进行分析。
  • 
  • 
• 解决方法有两种：APP 工程中一律不调用 Flash_EraseFlashDriverInRAM() 或将链接文件内 m_flash_driver 的地址空间从 m_data_2 地址空间的后半段进行划分。
  • 但经过评估，显然前者为更恰当的解决方法，因为在 APP 工程中，已不存在 m_flash_driver 地址空间，此时就算在 Bootloader 中将 m_data_2 的后半段空间划分给 m_flash_driver ，在 APP 工程中再对该片空间进行自行清零的操作是不妥的，因为 m_data_2 会用于存放 customSectionBlock、 bss、 heap、 stack， 此时如若再在 APP 中调用 Flash_EraseFlashDriverInRAM() ，同样有可能会将这些数据清零。

UDS（Unified Diagnostic Services，统一诊断服务）诊断协议是 ISO 15765 和 ISO 14229 定义的一种汽车通用诊断协议，位于 OSI 模型中的应用层，它可在不同的汽车总线（例如CAN、LIN、Flexray、Internet、K-line）上实现。UDS协议的应用层定义是 ISO 14229-1，目前大部分汽车厂商均采用 UDS on CAN 的诊断协议。

网络层最主要的目的就是 把数据转换成能适应 CAN 总线规范的单一数据帧，从而进行传输。 如果将要传输的报文长度超过了 CAN 数据帧的长度，则需要将报文信息进行拆分后传输，每次至多可以传输4095个字节长度的报文。

所有的网络层服务都具有相同的通用结构。为了定义这种服务，需要定义三种类型的服务原语：

• 请求服务（Request）：用于向网络层传递控制报文信息及要发送的数据，应用于更高层或应用层。如诊断仪向 ECU 发出数据。
• 指示服务（Indication）：用于向更高层或应用层传递状态信息及接收到的数据，应用于网络层。如 ECU 收到了诊断仪的数据，传至应用层。
• 确认服务（Confirm）：被网络层使用，用于向更高层或应用层传递状态信息。如诊断仪收到了 ECU 方面的数据。

具体说来，Indication 前端应该执行的是底层传入数据的处理函数，即读取 PDU 信息，这一帧具体是 SF、FC、CF 还是 FF。若满足条件，继续向上，即应用层传递。

具体说来，Confirm 和 Indication 很像的是都是从网络层向应用层传递信息，有何区别呢？

在代码的处理中，Confirm 的前端应向底层外发 Tx 数据或超时处理函数，反馈的信息不需要包含数据。而 Indication 传递的信息则分为两种，一种包含真实数据，另一种不包含。

网络层协议数据单元（N_PDU，Network Protocol Data Unit）包含 N_AI，N_PCI，N_Data。即地址信息，协议控制信息和数据。

网络层协议数据单元（N_PDU）有四种类型，即单帧（SF）、首帧（FF）、连续帧（CF）、流控制帧（FC），用于建立对等实体间的通信。

⚠️ 注意

本网络传输层的报文格式为：ISO 15765-2 2004

而在 ISO 15765-2 2016 中，单帧 SF 用第 2 字节存放长度 DL，首帧 FF 用第 3 ~ 6 字节存放长度 DL，故本协议栈尚不支持 ISO 15765-2 2016

ISO 15765-2 定义了一种 CAN 帧分割的网络传输层通信协议，该协议对 CAN 帧的 Byte0 - Byte2 进行了定义，由此产生了单帧（SF）、首帧（FF）、连续帧（CF）、流控帧（FC）。当发送端需要发送数据时，网络传输层会做如下处理，如果数据能用一帧 CAN 报文传输完则封装为单帧传输，否则就需要涉及到首帧、连续帧和流控帧。

单帧：用于发送小于等于 7 字节的数据，如下图所示，Byte0 高 4bit 为 0 的是单帧，Byte0 低 4bit 为报文有效字节数。Byte1-Byte7 为数据（包括无效的填充字节，填充数据可为任意值，通常为 AA 或 55）。比如应用层需要发送数据 [10 03]，经过网络传输层封装，最终发送至总线的实际数据为 [02 10 03 AA AA AA AA AA]

多帧：当需要发送的数据字节数大于 7 字节，需要用到首帧、连续帧和流控帧的多帧传输方式

接收者通过 Flow Control Frame（流控帧）的机制，告知发送者自己有多大的接收能力。（其实就是每两个 FC 之间允许连续发送多少个 CF，每两个 CF 之间的时间不能过快）

其中：

• DL：有效数据的长度，不包括 PCIbyte，具体定义见 network_layer_private.h
  • UDS_SF_DL_MAX = 7 （单帧 DL 取值最大 7 字节）
  • UDS_FF_DL_MIN = 8 （首帧 DL 取值最小 8 字节）
  • UDS_FF_DL_MAX = 4095 （首帧 DL 取值最大 4095 （0xFFF）字节）
• SN：连续帧的序列号 0 ~ 15，FF 帧没有 SN 域，但是它“算” CF 帧的序列号0，所以第一帧 CF 帧的 SN = 1
• FS：表示发送方是否可以继续传输消息，0表示可以继续发送 Continue To Send（CTS），1表示等待发送 Wait（WT），2表示数据溢出 Overflow（OVFLW），一次发送的数据大于接收方所能接收的量
• BS：接收方一次能接收的数据最大量，BS = 0，再无 FC 帧，CF 帧可无限制发送
• STmin：表示两个连续帧之间的最小时间间隔，参照图1中的定义

网络层定时参数定义了N_As、N_Ar、N_Bs、N_Br、N_Cs、N_Cr六个参数。

• N_As 超时：发送方没有及时发送 N_PDU。
• N_Ar 超时：接收方没有及时发送 N_PDU。
• N_Bs 超时：发送方没有接收到流控帧。
• N_Br 超时：接收方没有发出流控帧。
• N_Cr 超时：接收方没有收到连续帧。
• N_Cs：即STmin，发送两个连续帧需要等待的最短时间。

s = 发送者，r = 接收者

下表将 ISO 14229-Part 1:Specification and requirements 中信息进行整理，梳理了 UDS 汽车诊断协议所有服务以及对应服务支持的否定响应代码 NRC：

Resulting sub-function parameter byte value (bit 7 ~ 0)

• SuppressPosRspMsgIndicationBit = 1 抑制正响应
• SuppressPosRspMsgIndicationBit = 0 正响应不被抑制

正响应抑制位是在 Sub-Function 里的这个字节的最高位，我们把它叫做正响应抑制位。只有这个服务支持 Sub-Function 的时候，才有可能支持正响应抑制位。这里要注意的是它只是抑制正响应，而负响应是不被抑制的。