调试器能成功连上芯片，并不代表就能把数据稳稳当当地写进Flash里。在TRACE32环境下，Flash烧录要怎么配置，以及烧录过程中如果Flash算法加载失败了又该怎么去排查，关键是把几个方面对应好：目标芯片的连接是不是稳定、Flash的地址范围有没有写对、算法运行时占用的那一段RAM有没有冲突、时钟和总线的配置是不是正确，还有要烧进去的那个文件它的格式和装载地址能不能匹配上。根据Lauterbach的资料，TRACE32支持通过内存映射的方式来编程Flash，它既提供了现成的脚本和编程算法，也可以直接用命令或者脚本来执行烧录操作。

　　一、TRACE32 Flash烧录怎么配置

　　在TRACE32里配置Flash烧录的时候，不要一上来就直接用DATA.LOAD命令去加载文件；应该先把CPU停住，确认内存映射能够被正常读取，还要保证Flash所在的区域和算法将要运行的RAM区域之间不会发生地址上的重叠。

　　1、先把目标芯片连接好

　　打开TRACE32之后，要把跟这颗芯片对应的CPU脚本先加载进来，再运行SYStem.Up或者项目脚本里面已经写好的那些连接命令；接着要确认目标板已经进入了可以被调试的状态，比如程序计数器、各个寄存器，还有内存窗口的内容都能被正常读到，如果这一步的连接就不太稳定，后面那些操作Flash的命令也很容易跟着出问题。

　　2、确认好Flash的地址范围

　　需要根据芯片的数据手册或者链接文件，把Flash的起始地址、总容量、扇区的划分方式，还有启动区域具体在哪个位置，这些都弄清楚；比如常见的应用固件会被放在0x08000000这样的地址上面，那么脚本里声明Flash范围的时候，就要保证它跟真实的芯片情况是一致的，一旦地址写错了，后面擦除和编程的动作就会跑到错误的区域里去。

　　3、把Flash算法加载进RAM

　　Flash的编程算法通常要放到目标芯片的RAM里面才能跑起来，所以脚本里就得指定好算法文件用哪一个、Flash是什么类型、Flash的地址范围是多少，还有算法运行时要占用哪一段RAM；这里尤其要检查一下分配给算法的那段RAM是不是真的存在并且可写，容量够不够大，更不能跟应用程序的数据段、堆栈或者缓存区域撞在一块儿。

　　4、按顺序执行擦除和写入

　　等上面的配置都完成以后，再依次执行擦除、编程和校验的操作；比较常见的顺序是先对Flash进行解锁或者初始化，然后把目标扇区擦干净，接着把elf、hex或者bin格式的文件加载到对应的地址上，最后再做一次校验；不同类型的文件，加载时用的命令还有地址参数也要跟着变化，特别是bin文件，一定要把装载地址写清楚。

　　二、TRACE32 Flash算法加载失败怎么排查

　　Flash算法加载失败的时候，不能只盯着最后跳出来的那一行错误信息看；TRACE32的Flash算法是在目标CPU上运行的，按照Lauterbach支持文章里的说明，假如算法在执行途中被意外打断了，就会报出像是“FLASH algorithm did not execute completely”这样的提示，常见的原因包括看门狗复位、数据缓存没有关掉、算法被下载下来的文件给覆盖了、Flash的时钟或者总线配置有误，还有算法文件本身跟芯片不匹配等等。

　　1、检查算法运行的那段RAM

　　最先要看的是脚本里给算法分配的那块RAM地址，在芯片上是不是真实存在的，有没有被初始化好，会不会被MPU、MMU或者某些安全配置给限制住访问；我们可以先在Memory窗口里往那段RAM区域手动写一些数据再读回来，确认调试器能够正常访问这块空间。

　　2、检查是不是被应用文件给覆盖了

　　万一elf文件里面也有数据段被映射到了算法要用的那块RAM上，那么当应用固件下载下去的时候，就很可能把已经加载好的Flash算法给冲掉；Lauterbach的建议是，可以先用Data.LOAD.auto命令加上/NoCODE参数，然后去查看symbol.List.MAP来检查装载之后的映射情况，如果确实冲突了，就要让应用程序只下载到Flash的目标范围里，把算法的RAM区给避开。

　　3、记得把看门狗和数据缓存关掉

　　在烧录的整个过程中，CPU需要安安稳稳地执行算法，要是看门狗还在跑，算法就可能中途被复位信号打断；而如果数据缓存是开着的，也有可能让写入或者校验的结果变得不正常，所以在脚本里面，应该在Flash操作开始之前就把看门狗给关上，必要的时候也要把DCache一并关掉。

　　4、检查Flash的时钟和总线设置

　　不论是那种外挂在QSPI、OSPI上的Flash，还是芯片里自带的Flash，都得依赖正确的时钟、引脚的配置，还有总线控制器的设置才能正常工作；如果初始化脚本没有对Flash控制器做配置，就算算法成功加载了，也可能根本擦不动或者写不进去，碰到擦除失败、写入超时这类情况，就要回到芯片初始化脚本里，去检查时钟源、分频系数还有控制器的那些寄存器。

　　三、TRACE32 Flash烧录结果怎么复核

　　烧录动作执行完之后，不能光看到命令窗口里显示成功就觉得没问题了；在实际项目里面，还得再去确认文件到底被写到了正确的地址上、启动的相关配置有没有弄对，以及校验的结果是不是真的通过了。

　　1、核对一遍加载的地址

　　要把Map文件或者链接脚本打开，检查一下应用的入口地址、向量表、启动头这些是不是都跟Flash的地址对得上；特别是碰到多核芯片、Bootloader加App这种多级结构，或者是从外部Flash启动的项目，地址千万不能光靠猜。

　　2、再跑一次校验命令

　　烧录以后可以再用verify命令过一遍，或者直接把Flash里的内容读出来，跟原始文件做个对比；如果校验没有通过，就要先判断到底是写入这一步本来就失败了，还是文件的偏移量、字节序，又或是擦除的范围哪里没有弄对。

　　3、让芯片复位后跑起来看看

　　可以执行一次System.Reset，或者直接断掉电再重新上电，让芯片从真实的启动路径去运行；光是在调试器里Load完后能跑，并不代表Flash的整条启动链路都已经没问题了。

　　4、把烧录用的脚本保存好

　　Flash的配置、算法文件的路径、目标地址、文件路径，还有那些初始化的命令，都应该写进cmm脚本里面去，不要每次都是靠手动去点菜单来烧录，那样操作很难复现，以后想要排查因为版本差异带来的问题也不好定位。

　　总结

　　关于在TRACE32里面Flash烧录该怎样配置，以及Flash算法加载不成功的时候该怎么排查，处理起来的顺序一般是这样：先把目标连接稳当，接着确认好Flash的地址范围，再把算法运行时需要的那段RAM配置好，最后才去执行擦除、写入和校验这些动作；遇到算法加载失败的情况，要重点去查RAM地址的冲突、看门狗是不是还在起作用、缓存有没有被关掉、Flash时钟总线的配置，还有算法文件跟目标芯片匹不匹配，等到这些流程都用脚本固定下来之后，烧录的问题再出现时就更容易被复现，定位起来也会快很多。