1.问题出现描述当前公司有项目需要移植到英飞凌TLE的芯片(Cortex-M3内核)上我在开发和调试BOOT和APP跳转的时候发现经常出现上一次还能正常跳转的程序突然代码没变又不行了偶发现象我重复了多次操作流程发现和keil烧录程序(Jlink)后是否有重新上电有关那么问题就出在芯片的外设寄存器问题就很诡异了假如重新上电后我APP接收指令软复位到BOOTBOOT接收程序包并写入到Flash后执行热跳转操作都正常(及跳转到APP区域的flash起始地址)寄存器方面也和芯片原厂的FAE进行了沟通但并没有给出明确的答复因为离开了debug(keil刷写状态)反而正常他们也觉得无伤大雅确实是有道理的但是每次刷写完程序芯片的状态不确定这是很容易让人得到错误的反馈从而浪费很多时间在Bug排查所以接下来开始排查问题之前不熟悉的小伙伴先了解一下BOOT和APP。2.BOOT和APP(主程序)简介BOOT负责在离线情况下通过CAN、LIN、UART、其他总线都可以实现信息传输通过私有定义的协议或者行业规范如常见的OTA升级规范来将主程序(APP进行擦除和编程操作)。下面是一个假想的更新流程、我们的也大致是按照这个来的(收包、校验、状态机、flash驱动、中断向量)当然这个BOOT并非原厂芯片固件中就有的(一般各家公司喜欢自己根据协议自己开发)大家熟知的Bootloader(如STM32 C8T6启蒙芯片中可以用boot进行串口烧录)它是原厂出厂就已经写入了芯片固定的flash区域(有的芯片是可以去修改有的是禁止修改的)需要去核对芯片手册。3.问题分析3.1芯片上下电复位相关那我就从芯片的SWD调试引脚开始查起这个芯片引出了单独的Reset引脚Jlink在烧录完成后会拉低这个引脚(这个拉低的时间我查了很多资料但是没有查到这个时间是否会因为每个芯片不一样拉低时间写在JLINK芯片支持包中有大佬可以解释一下)3.2检测Reset引脚拉低波形根据现象我示波器监测keil调用J-Link驱动刷写后拉低Reset引脚时间异常的短(有效低电平只有300-400ns)没错就是纳秒3.3我再尝试使用J-Flash来刷写程序那么我首先想到的是J-FLASH工具去加载编译文件.hex这下发现J-flash刷写完成后足足拉低了20ms(与keil的300-400ns不一致)3.4芯片手册翻阅(Reset引脚对拉低信号的要求)芯片手册也证实了我的想法(拉低信号起码得超过500ns)几轮刷写芯片结果概览如下:4.方法解决思路4.1先询问技术支持对于这种情况技术支持给到的有效信息非常少所以只能作罢。4.2寻找方法完成刷写后拉低操作直接寻找方法在keil烧录完成之后直接使用脚本或配置让Jlink主动的拉低20ms4.3查阅Jlink官方API支持文档JLinkSettings.ini通过下面配置加载脚本ScriptFile.\ResetPin20ms.JLinkScript脚本使用 SEGGER 提供的物理引脚 APIint OnDisconnectTarget(void) { JLINK_TIF_ActivateTargetReset(); JLINK_SYS_Sleep(20); JLINK_TIF_ReleaseTargetReset(); return 0; }这里选择OnDisconnectTarget()因为它在下载会话结束时执行并且不要求返回时 CPU 处于 Halt。不能覆盖ResetTarget()因为它在建立连接和下载前也会调用覆盖后会破坏芯片的器件专用复位流程造成Failed to halt CPU。验证方法下载成功后JLinkLog.txt应出现Programming Done. Verify OK. Application running ... OnDisconnectTarget: nRESET low for 20 ms OnDisconnectTarget: nRESET released同时使用示波器测量 MCU 的 nRESET 引脚应看到约 20 ms 的低电平脉冲。J-Link nRESET、MCU RESET 必须实际连接并共地板端需要正常上拉。5.成功(调试框成功运行)