前言队列刷写利用RAM缓冲实现数据接收与Flash编程的硬件并行有效消除传统串行流程中的总线与存储等待时延。针对多ECU协同及主从级联场景下的会话超时与数据同步风险该方案通过动态挂起机制与严格的队列状态管理保障刷写稳定性。1 技术背景传统 Bootloader 刷写中数据下载Download与 Flash 编程Program多为严格串行须等一整块数据经 CAN、以太网等总线完全接收并校验后才能启动擦除与写入。高速总线等待 Flash 时空闲Flash 等待下一块时空闲形成“等待—忙碌”交替资源利用率低整体刷写时间被显著拉长。随着 ECU 程序存储从数百 KB 增至数 MB 甚至更大该问题在产线下线与售后 OTA 中愈发突出。队列刷写引入 RAM 缓冲队列将“接收块 N1”与“编程块 N”在时间轴上重叠以空间换时间。在 Flash 容量大或通信带宽相对有限时收益最为明显。这是嵌入式 Bootloader 中经典的高效刷写策略。知从青龙除pipeline外还在诊断传输层增加多槽接收队列以应对 UDS 连续多帧与 P2 应答约束下文将二者统称为“两层队列”。Figure 1传统刷写和队列刷写时序对比2 核方案运行注意事项知从科技可以为客户提供队列刷写方案以下内容为方案实施的注意点队列停滞并行度下降数据不同步块错乱或校验失败当单块编程时间持续大于传输时间缓冲槽位被占满诊断仪只能等待总时间接近串行甚至伴随挂起增多或超时。除“生效前提与调参”外应实测擦除段、传输段占用比避免在编程峰值阶段仍采用最短发送间隔。多缓冲切换时若条件不严谨或缺少块序号核对可能覆盖、错块编程最终校验失败。设计上应保证临界区保护、切换前多重状态检查、每块带序号且编程前核对。3 常见问题剖析在知从青龙队列刷写中以下五类问题在联调、压力刷写与量产回归测试中反复出现。它们并不孤立同一轮刷写中可能先后或叠加出现“响应超时”“仅主控失败”“从节点多包失败”等多种表现若仅从单一报文或单一阶段判断容易误判根因。3.1传输数据服务响应超时刷写进行到一定进度后诊断仪界面提示“响应超时”“未收到应答”或类似告警进度条长时间停在某一百分比不动。此时上位机可能仍显示“正在发送数据”给人以ECU仍在接收的错觉若在ECU侧抓取日志或CAN记录则往往能看到对传输数据服务的请求已被确认并反复回复“请求已正确接收—响应挂起”行业惯称NRC 0x78但在较长时间内等不到该请求对应的最终正响应传输数据服务的正常完成应答。从发生阶段看该问题并非均匀分布在整个刷写过程中而多集中在以下几类时刻Flash大面积擦除刚刚结束、即将开始或刚刚开始第一包数据传输时。擦除作业占用主循环时间极长若擦除结束后未立即恢复对诊断链路的调度首包传输数据极易撞上P2时限单包传输的数据长度明显大于常规块例如接近单帧或多帧上限导致单次入队、校验或后台预处理时间变长采用压缩格式下载时后台解压占用主循环且解压耗时随数据内容波动某些区段出现“突发慢处理”诊断仪配置为较短的发送间隔或较高的并发期望连续多帧传输数据之间的间隔小于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”时诊断仪发送块N1导致P2超时软件常在发出一块数据后暂时停止后台刷写主控任务直到确认下一帧诊断数据已进入通信队列再恢复后台并可能对队首请求回复挂起。该问题经排查后通常采用以下方案进行处理1在途诊断帧计数的严格配对从通信层分配接收缓冲开始计数到诊断层取走数据或接收失败回滚时减计数。任何超时、BusOff恢复、会话切换后应检查计数是否归零防止泄漏。2“等待下一帧”分支增加时间窗口在暂停后台刷写的状态下启动定时窗口内若检测到新帧进入通信队列按从节点策略恢复窗口到期仍无新帧则判定为普通刷写强制恢复后台任务与队列消费清除“等待”状态。3刷写模式配置分层产品配置应明确区分仅主控、仅某一从节点、主从联合等避免用单一全局变量贯穿所有刷写路径。文档与标定数据应说明各模式适用场景。4 知从青龙产品知从青龙BootLoader是由知从科技自主研发的程序刷新软件(BootLoader)。使用知从青龙BootLoader的控制器可以通过CAN、LIN、SPI等通信方式实现应用程序的更新功能。目前知从青龙BootLoader已支持NXP、Infineon、Renesas、ST等多家芯片并且支持多家整车厂程序刷新规范可提供定制开发服务。通常每家整车厂都有各自的程序刷新规范目前知从青龙BootLoader支持的整车厂程序刷新规范包括广汽、长安、上汽、一汽、东风商用车、东风、上海通用、吉利、奇瑞、上汽通用五菱、萨博、长城、北汽新能源等以上排名不分先后。IntroductionQueue-based flashing leverages RAM buffering to parallelize data reception and Flash programming, effectively eliminating bus and memory idle times inherent in traditional serial workflows. To mitigate session timeout and data synchronization risks in multi-ECU and master-slave topologies, the solution employs dynamic pending mechanisms and rigorous queue state management for robust performance.1 Technical BackgroundIn 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 N1 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>FIGURE 1 Timing Diagram: Traditional Flashing vs. Queue Flashing2 Implementation ConsiderationsZC 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 AnalysisIn 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.1TransferData Service Response TimeoutAfter 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: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.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.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.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 ECUs 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 CountermeasuresAfter investigation, the issue is typically addressed through the following measures:(1) Differentiating Response Strategy for Last Block vs. Intermediate BlocksFor 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 MechanismWhen 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.2Session Timeout During Multi-Slave or Master-Slave Combined FlashingWith 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 objects timeline; it does not automatically resolve session keep-alive, resource contention, and state switching across multiple objects timelines.Root Cause Analysis CountermeasuresAfter 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 SchedulingDuring 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 ObjectOperations 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 TimeoutUpon signature verification failure, first check whether an S3 timeoutoccurred 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 FlashingAnalysis 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 N1 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 CountermeasuresAfter investigation, the following solutions are typically implemented:(1) Strict Pairing of In-Flight Diagnostic Frame CountersCounting 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 BranchStart 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 ModesProduct 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.QingLongZC.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).——The End——作者FOTA工程师-林星妤校验市场部-纪姜奕点击进入知从官网https://www.shzckj.cn/
知从青龙队列刷写常见问题剖析
前言队列刷写利用RAM缓冲实现数据接收与Flash编程的硬件并行有效消除传统串行流程中的总线与存储等待时延。针对多ECU协同及主从级联场景下的会话超时与数据同步风险该方案通过动态挂起机制与严格的队列状态管理保障刷写稳定性。1 技术背景传统 Bootloader 刷写中数据下载Download与 Flash 编程Program多为严格串行须等一整块数据经 CAN、以太网等总线完全接收并校验后才能启动擦除与写入。高速总线等待 Flash 时空闲Flash 等待下一块时空闲形成“等待—忙碌”交替资源利用率低整体刷写时间被显著拉长。随着 ECU 程序存储从数百 KB 增至数 MB 甚至更大该问题在产线下线与售后 OTA 中愈发突出。队列刷写引入 RAM 缓冲队列将“接收块 N1”与“编程块 N”在时间轴上重叠以空间换时间。在 Flash 容量大或通信带宽相对有限时收益最为明显。这是嵌入式 Bootloader 中经典的高效刷写策略。知从青龙除pipeline外还在诊断传输层增加多槽接收队列以应对 UDS 连续多帧与 P2 应答约束下文将二者统称为“两层队列”。Figure 1传统刷写和队列刷写时序对比2 核方案运行注意事项知从科技可以为客户提供队列刷写方案以下内容为方案实施的注意点队列停滞并行度下降数据不同步块错乱或校验失败当单块编程时间持续大于传输时间缓冲槽位被占满诊断仪只能等待总时间接近串行甚至伴随挂起增多或超时。除“生效前提与调参”外应实测擦除段、传输段占用比避免在编程峰值阶段仍采用最短发送间隔。多缓冲切换时若条件不严谨或缺少块序号核对可能覆盖、错块编程最终校验失败。设计上应保证临界区保护、切换前多重状态检查、每块带序号且编程前核对。3 常见问题剖析在知从青龙队列刷写中以下五类问题在联调、压力刷写与量产回归测试中反复出现。它们并不孤立同一轮刷写中可能先后或叠加出现“响应超时”“仅主控失败”“从节点多包失败”等多种表现若仅从单一报文或单一阶段判断容易误判根因。3.1传输数据服务响应超时刷写进行到一定进度后诊断仪界面提示“响应超时”“未收到应答”或类似告警进度条长时间停在某一百分比不动。此时上位机可能仍显示“正在发送数据”给人以ECU仍在接收的错觉若在ECU侧抓取日志或CAN记录则往往能看到对传输数据服务的请求已被确认并反复回复“请求已正确接收—响应挂起”行业惯称NRC 0x78但在较长时间内等不到该请求对应的最终正响应传输数据服务的正常完成应答。从发生阶段看该问题并非均匀分布在整个刷写过程中而多集中在以下几类时刻Flash大面积擦除刚刚结束、即将开始或刚刚开始第一包数据传输时。擦除作业占用主循环时间极长若擦除结束后未立即恢复对诊断链路的调度首包传输数据极易撞上P2时限单包传输的数据长度明显大于常规块例如接近单帧或多帧上限导致单次入队、校验或后台预处理时间变长采用压缩格式下载时后台解压占用主循环且解压耗时随数据内容波动某些区段出现“突发慢处理”诊断仪配置为较短的发送间隔或较高的并发期望连续多帧传输数据之间的间隔小于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”时诊断仪发送块N1导致P2超时软件常在发出一块数据后暂时停止后台刷写主控任务直到确认下一帧诊断数据已进入通信队列再恢复后台并可能对队首请求回复挂起。该问题经排查后通常采用以下方案进行处理1在途诊断帧计数的严格配对从通信层分配接收缓冲开始计数到诊断层取走数据或接收失败回滚时减计数。任何超时、BusOff恢复、会话切换后应检查计数是否归零防止泄漏。2“等待下一帧”分支增加时间窗口在暂停后台刷写的状态下启动定时窗口内若检测到新帧进入通信队列按从节点策略恢复窗口到期仍无新帧则判定为普通刷写强制恢复后台任务与队列消费清除“等待”状态。3刷写模式配置分层产品配置应明确区分仅主控、仅某一从节点、主从联合等避免用单一全局变量贯穿所有刷写路径。文档与标定数据应说明各模式适用场景。4 知从青龙产品知从青龙BootLoader是由知从科技自主研发的程序刷新软件(BootLoader)。使用知从青龙BootLoader的控制器可以通过CAN、LIN、SPI等通信方式实现应用程序的更新功能。目前知从青龙BootLoader已支持NXP、Infineon、Renesas、ST等多家芯片并且支持多家整车厂程序刷新规范可提供定制开发服务。通常每家整车厂都有各自的程序刷新规范目前知从青龙BootLoader支持的整车厂程序刷新规范包括广汽、长安、上汽、一汽、东风商用车、东风、上海通用、吉利、奇瑞、上汽通用五菱、萨博、长城、北汽新能源等以上排名不分先后。IntroductionQueue-based flashing leverages RAM buffering to parallelize data reception and Flash programming, effectively eliminating bus and memory idle times inherent in traditional serial workflows. To mitigate session timeout and data synchronization risks in multi-ECU and master-slave topologies, the solution employs dynamic pending mechanisms and rigorous queue state management for robust performance.1 Technical BackgroundIn 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 N1 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>FIGURE 1 Timing Diagram: Traditional Flashing vs. Queue Flashing2 Implementation ConsiderationsZC 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 AnalysisIn 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.1TransferData Service Response TimeoutAfter 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: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.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.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.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 ECUs 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 CountermeasuresAfter investigation, the issue is typically addressed through the following measures:(1) Differentiating Response Strategy for Last Block vs. Intermediate BlocksFor 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 MechanismWhen 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.2Session Timeout During Multi-Slave or Master-Slave Combined FlashingWith 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 objects timeline; it does not automatically resolve session keep-alive, resource contention, and state switching across multiple objects timelines.Root Cause Analysis CountermeasuresAfter 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 SchedulingDuring 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 ObjectOperations 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 TimeoutUpon signature verification failure, first check whether an S3 timeoutoccurred 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 FlashingAnalysis 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 N1 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 CountermeasuresAfter investigation, the following solutions are typically implemented:(1) Strict Pairing of In-Flight Diagnostic Frame CountersCounting 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 BranchStart 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 ModesProduct 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.QingLongZC.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).——The End——作者FOTA工程师-林星妤校验市场部-纪姜奕点击进入知从官网https://www.shzckj.cn/
