内容提要
引言
1.应用工程的编译目标为debug_RAM，将代码编译链接到SARM而非Flash
2.启动代码(startupcode)未对使用的SRAM进行ECC初始化
3.FlexNVM(EEE--EmulatedEEPROM)分区失败
4.RAM初始化时未关闭看门狗，导致看门狗超时复位
5.内部参考时钟(IRC)没有校准(trim)，导致系统和外设时钟误差过大
6.bootloader跳转导致APP程序启动或者时钟、外设初始化失败
7.使用调试器的半主机(semi-host)模式重定向printf()到debugconsole输出调试信息
8.外设模块冻结模式配置影响其功能配置失败
总结
引言在嵌入式MCU软件开发过程中，通常我们需要先通过调试器(Debugger,带程序下载(Flash/EEPROM擦除、编程和校验)功能)或者仿真器(Simulator，不带目标MCU编程功能)对所写代码的功能进行在线调试(online-debug)，验证确认其功能符号设计需求后，在发布编程文件--S19/HEX/BIN给生成部门通过离线编程器(Offline/Stand-aloneFlashProgrammer)进行批量编程。批量(MassProduction，简称MP)的产品正常工作时是不需要/也不能连接调试器或者仿真器的(一方面，调试器和仿真器价格高昂，成本不允许，另一方面，无法满足系统设计的产品重量和空间要求)，因此，我们开发的嵌入式MCU应用软件/程序必须保证其在拔掉调试器和编程器或仿真器后依然能够功能运行正常，即离线工作(Offline，也称作脱机工作)正常。在实际工作中，大家常常会遇到，开发阶段在线调试工作正常的代码，离线工作时却无法正常工作，这是为什么呢？本文就基于NXP的汽车级MCU(S32K1xx/KEA,S12(X),MaginiVS12Z和QorivvaMPC56/57xx系列)为例，给大家介绍这类问题的可能原因和具体解决办法，希望对大家有所帮助。1.应用工程的编译目标为debug_RAM，将代码编译链接到SARM而非Flash在嵌入式MCU的软件开发集成环境(IDE)中创建应用工程时，通常都会创建至少两个编译目标(buildtarget)和调试目标(debugtarget)，使用不同的连接文件，将编译结果分别编译链接到SRAM和Flash中。比如，在NXP的S32DSIDE中，创建S32K1xx系列MCU的应用工程时，就会自动创建Debug、Debug_RAM和Release三个编译目标，其差异和用途如下：Tips：a.由于S32DS是基于GNU的工具链，编译器(gcc)优化这一块目前还不是很完善，建议量产时还是使用Debug的编译目标，以保证编译结果能够正常运行；b.编译目标中工具链的调试信息等级(debuglevel)配置，只影响elf文件中包含调试信息的多少，不会影响最终生成的编程文件(S19/HEX/BIN)大小，因为编程文件中不包含任何调试信息；c.一个S32DS工程可以有多个编译目标，用户可以通过工程属性创建、配置不同的编译目标实现应用工程的个性化编译；Tips：关于S32DSIDE应用工程的编译目标配置和使用，请参考如下转载请注明：http://www.0431gb208.com/sjslczl/58.html
