1  技术背景

传统 Bootloader 刷写中，数据下载（Download）与 Flash 编程（Program）多为严格串行：须等一整块数据经 CAN、以太网等总线完全接收并校验后，才能启动擦除与写入。高速总线等待 Flash 时空闲，Flash 等待下一块时空闲，形成“等待—忙碌”交替，资源利用率低，整体刷写时间被显著拉长。随着 ECU 程序存储从数百 KB 增至数 MB 甚至更大，该问题在产线下线与售后 OTA 中愈发突出。

队列刷写引入 RAM 缓冲队列，将“接收块 N+1”与“编程块 N”在时间轴上重叠，以空间换时间。在 Flash 容量大或通信带宽相对有限时，收益最为明显。这是嵌入式 Bootloader 中经典的高效刷写策略。

知从青龙除pipeline外，还在诊断传输层增加多槽接收队列，以应对 UDS 连续多帧与 P2 应答约束；下文将二者统称为“两层队列”。

Figure 1 传统刷写和队列刷写时序对比

2  方案运行注意事项

知从科技可以为客户提供队列刷写方案，以下内容为方案实施的注意点：

l  队列停滞（并行度下降）

l  数据不同步（块错乱或校验失败）

当单块编程时间持续大于传输时间，缓冲槽位被占满，诊断仪只能等待，总时间接近串行，甚至伴随挂起增多或超时。除“生效前提与调参”外，应实测擦除段、传输段占用比，避免在编程峰值阶段仍采用最短发送间隔。

多缓冲切换时，若条件不严谨或缺少块序号核对，可能覆盖、错块编程，最终校验失败。设计上应保证：临界区保护、切换前多重状态检查、每块带序号且编程前核对。

3  常见问题剖析

在知从青龙队列刷写中，以下五类问题在联调、压力刷写与量产回归测试中反复出现。它们并不孤立：同一轮刷写中可能先后或叠加出现“响应超时”“仅主控失败”“从节点多包失败”等多种表现，若仅从单一报文或单一阶段判断，容易误判根因。

3.1  传输数据服务响应超时

刷写进行到一定进度后，诊断仪界面提示“响应超时”“未收到应答”或类似告警，进度条长时间停在某一百分比不动。此时上位机可能仍显示“正在发送数据”，给人以 ECU 仍在接收的错觉；若在 ECU 侧抓取日志或 CAN 记录，则往往能看到：对传输数据服务的请求已被确认，并反复回复“请求已正确接收—响应挂起”（行业惯称 NRC 0x78），但在较长时间内等不到该请求对应的最终正响应（传输数据服务的正常完成应答）。

从发生阶段看，该问题并非均匀分布在整个刷写过程中，而多集中在以下几类时刻：

l  Flash 大面积擦除刚刚结束、即将开始或刚刚开始第一包数据传输时。擦除作业占用主循环时间极长，若擦除结束后未立即恢复对诊断链路的调度，首包传输数据极易撞上 P2 时限；

l  单包传输的数据长度明显大于常规块（例如接近单帧或多帧上限），导致单次入队、校验或后台预处理时间变长；

l  采用压缩格式下载时，后台解压占用主循环，且解压耗时随数据内容波动，某些区段出现“突发慢处理”；

l  诊断仪配置为较短的发送间隔或较高的并发期望，连续多帧传输数据之间的间隔小于 ECU 在“当前后台负载”下完成入队与首帧响应的能力。

CAN 上常见：连续传输数据请求 → 偶发挂起 → 长时间无响应 → 诊断仪判定 P2 超时并中止会话。

该问题经排查后，通常从以下方面处理

（1）区分“最后一块”与“中间块”的应答策略

对非最后一块：数据长度、块序号、地址范围等检查通过后，完成入队即应回复正响应，使诊断仪可以继续发送后续块；不得等待后台编程完成。对最后一块：须待数据队列排空、后台编程作业空闲后，再给出该块的最终正响应——这是正确性要求，现场不应将“最后一块晚应答”误判为本节的超时缺陷。

（2）建立“下一帧已就绪则主动挂起”的机制

当检测到通信队列中已有下一帧传输数据（或同类长耗时服务）待处理，且当前诊断发送通道空闲、尚未对上一请求给出最终响应时，应主动发送挂起响应，争取在 P2 内给出“首个响应”。该机制与“仅依赖周期任务轮询挂起”相比，可显著降低边界超时概率，尤其在擦除刚结束、首包紧接着到达的场景。

3.2  多从节点或主从联合刷写时会话超时

随着域控、区域控制器等架构普及，一次 OTA 或产线刷写往往需按顺序对多个对象完成固件更新：例如先主控、再从节点 A、再从节点 B；或两个从节点依次升级。队列刷写引入后，单个对象的传输数据阶段通常明显加快，但现场仍频繁报告：第一个对象全程正常，切换至第二个对象后出现问题。

分析发现，队列提高单对象吞吐，多对象仍受会话定时与互斥约束；队列刷写解决的是单对象时间轴上“接收与编程重叠”的效率问题，并未自动解决多对象时间轴上的会话保活、资源互斥与状态切换。

该问题经排查后，通常采用以下方案进行处理

（1）对象切换前的“排空 + 复位状态”*

每一对象刷写结束前，确认：数据队列无未处理块、通信队列无未递交帧、后台编程作业空闲、无未完成的挂起等待。再进入下一对象前，按项目规范重启或刷新 S3 等相关定时器，必要时执行会话保持交互。

（2）长作业周期挂起与 CAN 调度

对象 A 的擦除、大块转发等阶段，周期回复挂起并调度链路层，使诊断仪与会话保持逻辑认为 ECU 仍在响应。避免数秒级“完全无诊断报文”窗口。

（3）操作与“当前目标对象”绑定

复位、进入编程会话、保持会话、切换波特率等操作，应带目标对象判断，仅影响当前刷写节点。禁止在“即将刷 B”前对 B 或共用总线上的节点执行无关复位。

（4）区分验签失败与会话超时

验签失败时，先查失败前是否有 S3 超时、是否仍能正常响应会话保持或切换会话；若会话已失效，优先修复定时与切换流程，再重试验签。

3.3  开启队列刷写后，仅刷主节点亦失败

分析发现，从节点刷写场景中，主控除接收 CAN 诊断数据外，还需经 UART 或其它链路向从节点转发。转发往返时间往往远大于 CAN 上单块传输时间。为避免“主控已收块 N、从节点尚在写块 N−1”时诊断仪发送块 N+1 导致 P2 超时，软件常在发出一块数据后，暂时停止后台刷写主控任务，直到确认下一帧诊断数据已进入通信队列，再恢复后台并可能对队首请求回复挂起。

该问题经排查后，通常采用以下方案进行处理

（1）在途诊断帧计数的严格配对

从通信层分配接收缓冲开始计数，到诊断层取走数据或接收失败回滚时减计数。任何超时、BusOff 恢复、会话切换后应检查计数是否归零，防止泄漏。

（2）“等待下一帧”分支增加时间窗口 

在暂停后台刷写的状态下启动定时；窗口内若检测到新帧进入通信队列，按从节点策略恢复；窗口到期仍无新帧，则判定为普通刷写，强制恢复后台任务与队列消费，清除“等待”状态。

（3）刷写模式配置分层

产品配置应明确区分：仅主控、仅某一从节点、主从联合等，避免用单一全局变量贯穿所有刷写路径。文档与标定数据应说明各模式适用场景。

4  知从青龙产品

知从青龙BootLoader是由知从科技自主研发的程序刷新软件(BootLoader)。使用知从青龙BootLoader的控制器，可以通过CAN、LIN、SPI等通信方式实现应用程序的更新功能。目前，知从青龙BootLoader已支持NXP、Infineon、Renesas、ST等多家芯片，并且支持多家整车厂程序刷新规范，可提供定制开发服务。

通常每家整车厂都有各自的程序刷新规范，目前知从青龙BootLoader支持的整车厂程序刷新规范包括：广汽、长安、上汽、一汽、东风商用车、东风、上海通用、吉利、奇瑞、上汽通用五菱、萨博、长城、北汽新能源等（以上排名不分先后）。

1  Technical Background

In conventional Bootloader flashing, data download and Flash programming are predominantly executed in a strictly sequential manner: the system must wait until an entire data block has been fully received and verified via CAN, Ethernet, or other vehicle buses before initiating the erase and write operations. During this process, the high-speed bus remains idle while waiting for the Flash to complete programming, and conversely, the Flash sits idle while awaiting the next data block. This alternating "wait–busy" pattern results in poor resource utilization and significantly prolongs the overall flashing time. As ECU program memory has grown from hundreds of kilobytes to several megabytes or even larger, this issue has become increasingly pronounced in both production-line end-of-line (EOL) programming and after-sales OTA updates.

Queue flashing introduces a RAM-based buffer queue to overlap the reception of block N+1 with the programming of block N in the time domain, trading memory space for reduced time. The benefits are most pronounced when Flash capacity is large or when communication bandwidth is relatively constrained. This is a classic high-efficiency flashing strategy in embedded Bootloaders.

In addition to data-layer ping-pong buffering, ZC.QingLong implements a multi-slot reception queue at the diagnostic transport layer to address UDS consecutive multi-frame transmission and P2 response timing constraints. For the purposes of this discussion, both mechanisms are collectively referred to as the "two-layer queue."

FIGURE 1 Timing Diagram: Traditional Flashing vs. Queue Flashing

2  Implementation Considerations

ZhiCong Technology can provide customers with the queue flashing solution. The following points require attention during implementation:

Queue Stall (Parallelism Degradation)

Data Desynchronization (Block Misalignment or Verification Failure)

When the programming time of a single block persistently exceeds the transmission time, the buffer slots become fully occupied, forcing the diagnostic tester to wait. The total time then approaches that of sequential flashing, potentially accompanied by an increased number of suspensions or timeouts. Beyond verifying the activation prerequisites and tuning parameters, the actual erase-segment and transmission-segment occupancy ratios should be measured. Avoid using the shortest transmission interval during peak programming phases.

During multi-buffer switching, if the conditions are not rigorously enforced or block sequence number verification is omitted, overwrites or incorrect block programming may occur, ultimately resulting in verification failure. The design must guarantee: critical section protection, multiple state checks prior to buffer switching, and inclusion of a sequence number with each block that is verified before programming.

3  Common Issue Analysis

In the ZC QINGLONG queue flashing process, the following five categories of issues recur during integration debugging, stress flashing, and mass-production regression testing. They are not isolated: within a single flashing session, multiple symptoms such as "response timeout," "master node failure only," and "multi-packet failure on slave nodes" may appear sequentially or simultaneously. If diagnosis is based solely on a single message or a single phase, the root cause is prone to misjudgment.

3.1  TransferData Service Response Timeout

After the flashing process reaches a certain progress, the diagnostic tool interface displays warnings such as "Response Timeout" or "No Response Received," and the progress bar remains stuck at a certain percentage for an extended period. At this time, the host computer may still display "Sending Data," creating the illusion that the ECU is still receiving. However, if logs or CAN traces are captured on the ECU side, it is often observed that: the request for the TransferData service has been acknowledged, and the ECU repeatedly replies with "Request Sequence Error - Response Pending" (commonly referred to in the industry as NRC 0x78), yet the final positive response corresponding to that request (the normal completion acknowledgment for the TransferData service) fails to arrive within a considerable time frame.

From the perspective of the occurrence phase, this issue is not uniformly distributed throughout the flashing process; it predominantly concentrates at the following moments:

l  Immediately before, during, or right after Flash mass erase: The erase operation occupies the main loop for an extremely long duration. If diagnostic link scheduling is not resumed immediately after the erase completes, the first data transfer packet is highly likely to breach the P2 timeout.

l  Single-packet data length significantly exceeds the standard block size (e.g., approaching the Single Frame or Multi-Frame length limit), resulting in prolonged queuing, checksum verification, or background preprocessing time.

l  Compressed format download: Background decompression consumes the main loop, and the processing time fluctuates with data content, leading to "sudden slow processing" in certain segments.

l  Tester configured with aggressive timing: Short inter-frame transmission intervals or high concurrency expectations are set on the tester. The interval between consecutive multi-frame data transfers is shorter than the ECU's capability to complete queuing and the initial frame response under the current background load.

On the CAN bus, the typical symptom is: Continuous Transfer Data Request → Occasional Busy/Hang → Prolonged No Response → Tester judges P2 Timeout and aborts the session.

Root Cause Analysis & Countermeasures

After investigation, the issue is typically addressed through the following measures:

(1) Differentiating Response Strategy for "Last Block" vs. "Intermediate Blocks"

For non-last blocks: Upon passing checks (data length, block counter, address range, etc.) and completing queuing, a positive response must be sent immediately to allow the tester to proceed with subsequent blocks. Do not wait for the background programming operation to finish.

For the last block: The final positive response must be withheld until the data queue is drained and the background programming job is idle—this is a correctness requirement. On-site personnel should not misclassify "late response of the last block" as a timeout defect described in this section.

(2) Implementing a "Proactive Pending" Mechanism

When detecting that the next frame (or another long-duration service) is already queued for processing, and the current diagnostic transmit channel is idle while the final response to the previous request has not yet been issued, a Pending Response (0x78) should be actively sent to secure the "first response within P2." Compared to mechanisms relying solely on periodic task polling for pending status, this approach significantly reduces boundary timeout probabilities, especially in scenarios where the first packet arrives immediately after an erase operation ends.

3.2  Session Timeout During Multi-Slave or Master-Slave Combined Flashing

With the proliferation of domain controllers and zone controller architectures, a single OTA or production line flashing process often requires sequential firmware updates for multiple targets: for example, updating the Master Control Unit first, followed by Slave Node A, then Slave Node B; or upgrading two slave nodes sequentially. After introducing queued flashing, the data transfer phase for individual targets is usually significantly faster. However, field reports frequently indicate that the first target operates normally, but issues arise when switching to the second target.

Analysis reveals that while queuing improves single-target throughput, multi-target operations remain constrained by session timing and mutual exclusion. Queued flashing addresses the efficiency of "overlapping reception and programming" on a single object's timeline; it does not automatically resolve session keep-alive, resource contention, and state switching across multiple objects' timelines.

Root Cause Analysis & Countermeasures

After investigation, the following solutions are typically implemented:

(1) "Drain + Reset State" Before Target Switching*

Before concluding the flashing of each target, confirm that: the data queue contains no unprocessed blocks, the communication queue has no pending frames, the background programming job is idle, and there are no outstanding pending waits. Before proceeding to the next target, restart or refresh relevant timers (such as S3) according to project specifications, and perform session keep-alive interaction if necessary.

(2) Long Job Cycle Pending and CAN Scheduling

During phases involving Flash erase or large-block forwarding for Object A, periodically send Pending Responses (NRC 0x78) and schedule the link layer to ensure the tester and session management logic recognize the ECU as still responding. Avoid multi-second windows of "complete diagnostic silence."

(3) Binding Operations to the "Current Target Object"

Operations such as reset, entering the Programming Session, session keep-alive, and baud rate switching must include target object identification logic and affect only the currently active flashing node. It is prohibited to execute irrelevant resets on Node B or any nodes sharing the bus just before "flashing B is about to start."

(4) Differentiating Signature Verification Failure from Session Timeout

Upon signature verification failure, first check whether an S3 timeout occurred prior to the failure and whether the ECU can still respond normally to session keep-alive or session switching requests. If the session has expired, prioritize fixing the timing and switching flow before retrying the signature verification.

3.3  Session Timeout During Multi-Slave or Master-Slave Combined Flashing

Analysis revealed that in a slave node flashing scenario, the Master Control Unit must forward data to slave nodes via UART or other links, in addition to receiving CAN diagnostic data. The round-trip forwarding time is often significantly longer than the CAN single-block transfer time. To prevent the tester from sending Block N+1 and causing a P2 timeout while the "Master has received Block N but the Slave is still writing Block N-1," the software often temporarily suspends the background Master flashing task after transmitting one block. It resumes the background task only upon confirmation that the next diagnostic frame has entered the communication queue, potentially issuing a Pending Response for the head-of-queue request.

Root Cause Analysis & Countermeasures

After investigation, the following solutions are typically implemented:

(1) Strict Pairing of In-Flight Diagnostic Frame Counters

Counting should begin when the communication layer allocates receive buffers and decrement when the diagnostic layer retrieves the data or when reception fails and rolls back. After any timeout, BusOff recovery, or session switching, verify that the counter has returned to zero to prevent leaks.

(2) Adding a Time Window to the "Wait for Next Frame" Branch

Start a timer when the background flashing task is suspended. If a new frame is detected entering the communication queue within the window, resume operation according to the slave node strategy. If the window expires and no new frame has arrived, classify the operation as a normal flash sequence, forcibly resume the background task and queue consumption, and clear the "waiting" state.

(3) Layered Configuration of Flashing Modes

Product configurations must explicitly distinguish between modes such as "Master Only," "Specific Slave Only," and "Master-Slave Combined," avoiding the use of a single global variable across all flashing paths. Documentation and calibration data should specify the applicable scenarios for each mode.

4  ZC.QingLong

ZC.QingLong BootLoader is a self-developed flash programming software (BootLoader) by ZCTechnology. Controllers using ZC.QingLong BootLoader can update the application through communication methods such as CAN, LIN, and SPI. Currently, ZC.QingLong BootLoader has supported multiple chips from manufacturers like NXP, Infineon, Renesas, and ST, and complies with the program refreshing specifications of various vehicle manufacturers. It also offers customized development services.

Typically, each vehicle manufacturer has its own specifications for program refreshing. The vehicle manufacturers whose program refreshing specifications are currently supported by ZC.QingLong BootLoader include: GAC (Guangzhou Automobile), Changan, SAIC (Shanghai Automotive Industry Corporation), FAW (First Automobile Works), Dongfeng Commercial Vehicles, Dongfeng, SGMW (SAIC General Motors Wuling), Geely, Chery, SAIC-GM-Wuling, Saab, Great Wall, BAIC New Energy, etc. (listed in no particular order).

1  方案介绍Solution Introduction

  汽车通过 OTA 对车载控制器软件进行刷写，能够便捷修复软件缺陷、升级新增功能，同时大幅降低线下服务的人力与物力成本，软件刷新能力已成为车载控制器的标配基础功能。随着汽车芯片技术不断迭代升级，主流车用微控制器 MCU 已从传统单核架构全面升级为双核及多核架构，为高性能、高可靠的刷写方案提供了硬件基础。本文重点阐述多核控制器如何利用双核 / 多核架构实现 Bootloader 并行刷写，从而提升软件刷写速度，优化升级体验，提高客户满意度。

 By flashing the software of vehicle controllers via OTA, automakers can conveniently fix software bugs, upgrade new functions, and greatly reduce labor and material costs for offline maintenance. Software refresh capability has become a standard basic function of most on-board controllers.

 With the iterative upgrading of automotive chips, mainstream vehicle MCUs have evolved from traditional single-core architecture to dual-core and multi-core architectures, providing a hardware foundation for high-performance and high-reliability flashing solutions.

 This document mainly introduces how multi-core controllers implement Bootloader flashing based on dual-core / multi-core architecture, so as to speed up software flashing, optimize upgrade experience and improve customer satisfaction.

2  软件构成 Software Element

      MCU Bootloader 软件主要由以下核心模块构成，各模块协同保障多核刷写高效、安全运行：

The MCU Bootloader software is mainly composed of the following core modules, which work together to ensure efficient and safe multi-core flashing:

 底层驱动 / Low-level Drivers

核心功能：与MCU硬件交互，负责初始化、通信及存储驱动，实现多核独立运行与协同，为各模块提供硬件访问接口。

Core Function: Interact with MCU hardware, responsible for initialization, communication and storage drivers, enabling independent operation and collaboration of multiple cores, and providing hardware access interfaces for each module.

 任务调度管理 / Task Scheduling

核心功能：统筹Bootloader任务，分配优先级，实现多核任务同步与通信，避免冲突，保障“边收边写”顺畅执行。

Core Function: Coordinate Bootloader tasks, assign priorities, realize multi-core task synchronization and communication, avoid conflicts, and ensure smooth "receiving while writing".

 Bootloader Manager（升级管理） / Bootloader Manager (Upgrade Management)

核心功能：管控整个刷写流程，启动刷写、协调多核协同、处理异常并触发回滚，保障升级完整安全。

Core Function: Control the entire flashing process, start flashing, coordinate multi-core collaboration, handle abnormalities and trigger rollback, ensuring complete and safe upgrade.

 UDS 诊断服务 / UDS Diagnostic Services

核心功能：基于UDS协议，负责接收刷写指令、解析固件数据并传输，反馈刷写状态，实现远程管控。

Core Function: Based on UDS protocol, responsible for receiving flashing instructions, parsing and transmitting firmware data, feeding back flashing status, and realizing remote control.

 Flash 擦写 / Flash Erase, Write

核心功能：负责Flash擦除与固件写入，支持分片写入，配合“边收边写”，确保操作高效精准。

Core Function: Responsible for Flash erasure and firmware writing, supporting block writing, cooperating with "receiving while writing" to ensure efficient and accurate operation.

 数据校验 / Data Verification

核心功能：贯穿刷写全程，校验报文、写入数据及整体固件，防止非法或错误数据，保障刷写安全。

Core Function: Throughout the flashing process, verify messages, written data and the entire firmware to prevent illegal or wrong data and ensure flashing security.

Bootloader SW modules

3  多核任务分配 Task assignment

  知从科技可为客户提供完整的多核刷写解决方案，并可根据项目特定需求、硬件平台及芯片特性进行定制化开发。在双核 MCU 架构下，青龙多核 Bootloader 方案将 Bootloader 相关任务进行解耦与分工，分配至不同核心并行运行，相比传统单核架构，可显著提升运行速度、刷写效率与系统实时性。

 ZC provides customers with a complete multi-core flashing solution, which can be customized according to specific project requirements, hardware platforms and chip features. In a dual-core MCU architecture, the ZC.QingLong multi-core Bootloader decouples and assigns Bootloader tasks to different cores for parallel execution. Compared with the traditional single-core architecture, it significantly improves running speed, flashing efficiency and system real-time performance.

 Core 0 task assign

 负责：OS 任务调度、底层驱动、Bootloader Manager、UDS 诊断服务、CAN/CAN FD 报文接收与解析

 Responsible for: OS task scheduling, low-level drivers, Bootloader Manager, UDS diagnostic services, CAN/CAN FD message reception and parsing

 Core 1 task assign

 专注执行 Flash 相关硬核操作，负责：Flash 擦除、Flash 写入、固件数据校验、刷写状态监控等任务

 Focused on Flash-related hard real-time operations, Responsible for: Flash erasure, Flash programming, firmware data verification, flashing status monitoring and other tasks

4  多核并行刷写Multicore Reflash

 知从科技可提供完整的安全诊断与并行刷写方案，可针对项目需求与硬件模块做定制化开发，实现的核心刷写特性包括：

 ZC can provide customers with a complete solution for secure diagnosis and parallel flashing, with customizable development according to project requirements and hardware modules. Key flashing features include:

 Core 0：持续接收并解析诊断报文

 Core 0: Continuously receive and parse diagnostic messages

 Core 1：同步执行 Flash 擦除与编程操作

 Core 1: Perform Flash erase and write operations synchronously

 双核之间通过通用共享 RAM 实现高效数据交互与任务同步，真正实现边接收报文、边写入 Flash 的流式并行刷写效果，大幅缩短整体升级时间。为实现数据交互的精准性与高效性，共享 RAM 设计专属数据缓冲区，Core 0 与 Core 1 分别配置独立的读写指针，通过指针协同完成数据的有序传递，避免数据错乱与冲突。

 具体实现逻辑：Core 0（负责接收 CAN 报文）配置写指针（Write Pointer），接收并解析 CAN 报文后，将有效固件数据按顺序写入共享 RAM 缓冲区，每写入一段数据，写指针自动偏移对应长度，标记当前可写入的空闲地址；Core 1（负责 Flash 写入）配置读指针（Read Pointer），实时监测共享 RAM 中的数据，当读指针与写指针不重合时，从读指针指向的地址读取数据执行 Flash 写入操作，读取完成后，读指针同步偏移，释放已读取的缓冲区空间。

 通过读写指针的独立协同，Core 0 可持续接收 CAN 报文并写入共享 RAM，Core 1 同步读取数据执行刷写，无需等待对方完成操作，真正实现“边收边写”的并行效果，同时有效避免双核心对共享 RAM 的读写冲突，保障数据传递的完整性与刷写效率。

 The two cores achieve efficient data interaction and task synchronization through general shared RAM, realizing a true streaming parallel flashing effect: receiving messages while writing to Flash, which greatly shortens the overall upgrade time. To ensure the accuracy and efficiency of data interaction, the shared RAM is designed with an exclusive data buffer. Core 0 and Core 1 are respectively configured with independent read and write pointers, and the ordered data transmission is completed through pointer coordination to avoid data disorder and conflicts.

Specific implementation logic: Core 0 (responsible for receiving CAN messages) is configured with a Write Pointer. After receiving and parsing CAN messages, it writes valid firmware data into the shared RAM buffer in sequence. Each time a segment of data is written, the Write Pointer automatically offsets by the corresponding length to mark the current free address for writing; Core 1 (responsible for Flash writing) is configured with a Read Pointer, which monitors the data in the shared RAM in real time. When the Read Pointer does not coincide with the Write Pointer, it reads data from the address pointed by the Read Pointer to execute Flash writing operation. After reading, the Read Pointer offsets synchronously to release the read buffer space.

Through the independent coordination of read and write pointers, Core 0 can continuously receive CAN messages and write them into the shared RAM, while Core 1 synchronously reads data to execute flashing, without waiting for the other party to complete the operation. This truly realizes the parallel effect of "receiving while writing", and effectively avoids read-write conflicts of the shared RAM between the two cores, ensuring the integrity of data transmission and flashing efficiency.

 The two cores achieve efficient data interaction and task synchronization through general shared RAM, realizing a true streaming parallel flashing effect: receiving messages while writing to Flash, which greatly shortens the overall upgrade time.

 同时，多核任务并行架构避免了单核因长时间 Flash 操作导致任务阻塞、系统卡死等问题，有效解决传统单核 Bootloader 喂狗不及时、任务卡死等行业痛点，显著提升系统稳定性与可靠性。

 In addition, the multi-core parallel architecture avoids task blocking and system freezes caused by long-time Flash operations in single-core design. It effectively solves industry pain points such as untimely watchdog feeding and task stuck in traditional single-core Bootloader, greatly improving system stability and reliability.

5  多核刷写的优势Advantage

1、刷写速度显著提升：报文接收与 Flash 编程并行执行，消除 “先收完再写入” 的等待耗时。

Significantly improved flashing speed: Message reception and Flash programming run in parallel, eliminating the waiting time of “receive first, then write”.

2、系统更稳定，不卡死、不复位：诊断任务与 Flash 操作分离，避免长时间阻塞导致看门狗复位。

More stable system, no stuck or reset: Diagnosis tasks and Flash operations are separated, avoiding watchdog reset caused by long-time blocking.

3、架构清晰，易于维护与扩展：多核任务解耦，模块化设计，便于适配不同芯片、多节点 OTA 与批量升级。

Clear architecture, easy to maintain and extend: Multi-core task decoupling and modular design make it easy to adapt to different MCUs, multi-node OTA and batch upgrades.

4、支持高安全合规场景：可无缝集成安全启动、安全诊断、固件验签等机制，满足车载功能安全与信息安全要求。

Supports high security and compliance scenarios: Can seamlessly integrate Secure Boot, secure diagnosis, firmware verification, meeting automotive functional safety and cybersecurity requirements.

.

.

FOTA产品支持哪些芯片？