[讨论]

一个关于使用STM32F4芯片CCM RAM时的异常分析

2017-1-12 13:37:09 6109

0 前言有客户用STM32F427芯片，程序将CSTACK放在CCM RAM中，结果测试过一段时间的板子都出现了不能正常运行的情况。这个现象一度让我们怀疑是否是CCM RAM在测试过程中遭到了破坏，导致我们在解决问题的道路上浪费了不少时间。事实证明STM32的CCM RAM并没有那么脆弱，而解决问题时尽力从多个角度进行验证，不放过所有可能出问题的环节之心态更为重要。在具体讨论问题的原因之前，不妨先介绍一下STM32F4/STM32F3系列芯片上的CCM RAM。 CCM RAM介绍 ST的STM32F303, STM32F358, STM32F328, STM32F334系列和STM32F4的Advanced line系列芯片里都有CCM(Core Coupled Memory) RAM。但仔细看系统架构图会发现F3和F4的CCM RAM还是有不一样的地方。如下面是STM32F303和STM32F427的架构图： F3和F4的CCM RAM都只能被内核访问，DMA主设备没有连接到CCM RAM，所以不能访问它。从上图我们还能看到，对于F303的CCM RAM它连接到了数据总线和指令总线上，所以32F303的CCM RAM既可以放数据也可以执行代码。但32F427的CCM RAM只连接到了数据总线，所以F427的CCM RAM不能执行代码。这一点需要注意。数据和代码放在CCMRAM的好处是，访问和执行的速度更快。www.stmcu.com.cn网站上可以下载到AN4296的中文版本，这篇应用手册里详细说明了怎么从F303的CCM RAM里执行代码。在这里就不再赘述了。下面接着讲讲前面在32F427上遇到的异常问题。问题描述客户的产品做了一段时间的测试后发现一批板子全部出问题。客户方面进行分析后用了一段简单的点灯程序进行测试，发现当CSTACK放在不同的位置时程序表现不一样。CSTACK放在SRAM中时，工作正常，但放在CCM RAM中就不能正常运行。从这个现象看很像是CCM RAM出问题了，且恰好只有经过测试的板子有问题，其他板子都没有问题。测试过程拿到客户的板子和测试代码后很容易就重现了客户描述的现象。首先检查了客户测试代码中的link文件。发现link文件写的没错。【IAR环境】 /###ICF### Section handled by ICFeditor, don't touch! **/ /-Editor annotation file-/ /IcfEditorFile="$TOOLKIT_DIR$configideIcfEditorcortex_v1_0.xml" / /-Specials-/ define symbol__ICFEDIT_intvec_start__ = 0x08000000; /-Memory Regions-/ define symbol __ICFEDIT_region_ROM_start__= 0x08000000; define symbol__ICFEDIT_region_ROM_end__ = 0x081FFFFF; define symbol__ICFEDIT_region_RAM_start__ = 0x20000000; define symbol__ICFEDIT_region_RAM_end__ = 0x2002FFFF; define symbol__ICFEDIT_region_CCMRAM_start__ = 0x10000000; define symbol__ICFEDIT_region_CCMRAM_end__ = 0x1000FFFF; /-Sizes-/ define symbol__ICFEDIT_size_cstack__ = 0x400; define symbol __ICFEDIT_size_heap__= 0x200; /*** End of ICF editor section.###ICF###/ define memory mem with size = 4G; define region ROM_region = mem:[from__ICFEDIT_region_ROM_start__ to __ICFEDIT_region_ROM_end__]; define region RAM_region = mem:[from__ICFEDIT_region_RAM_start__ to __ICFEDIT_region_RAM_end__]; define region CCMRAM_region =mem:[from __ICFEDIT_region_CCMRAM_start__ to __ICFEDIT_region_CCMRAM_end__]; define block CSTACK with alignment =8, size = __ICFEDIT_size_cstack__ { }; define block HEAP with alignment =8, size = __ICFEDIT_size_heap__ { }; initialize by copy { readwrite }; do not initialize { section .noinit}; place at addressmem:__ICFEDIT_intvec_start__ { readonly section .intvec }; /place at addressmem:__ICFEDIT_region_CCMRAM_start__ { block CSTACK };/ place in CCMRAM_region {blockCSTACK}; place in ROM_region { readonly }; place in RAM_region { readwrite,block HEAP }; 首先定义一个CCMRAM_region,然后通过”place in CCMRAM_region{block CSTACK};” 声明将CSTACK放在CCM RAM中。但在接下来的测试中发现了一些新的现象。测试一：首先测试过程中发现板子连着ST-LINK在debug状态下时，能正常运行。只有断开ST-LINK,重新上电后就不能正常工作了。测试二：为了确认CCM RAM是不是真的坏了。另外写了一个程序，将CSTACK放在SRAM中，然后在程序运行的时候对CCM RAM地址空间进行遍历，对地址0x10000000 到0x1000FFFF空间逐次进行读写操作。发现程序正常运行，CCM RAM的读写正常。实验做到这里，基本可以确定CCM RAM没有损坏。但为什么CSTACK不能放到CCM RAM中呢？然后我们又做了第三个实验。测试三：对比拿到的坏板子的Optionbytes的值与默认值。逐个检测不同的位是否和问题相关。发现BFB2这位的状态会影响程序的运行。如果清除该位，即使将CSTACK放在CCM RAM中，程序也能正常运行。原因分析* 从上面的测试结果，发现问题跟Option bytes中的BFB2的状态有关。查询BFB2位的作用后搞清了问题的原因。我们先来说说BFB2做什么用。STM32F427的Flash支持双Bank. BFB2可以用来切换启动时从Bank2启动。我们来看看参考手册中的描述：如果想从Flash Bank2启动，必须将BFB2位置1。如果此时boot引脚的配置是从用户Flash启动，芯片将先从系统bootloader启动，然后跳转到Bank2执行。然后在应用笔记AN2606中，我们看到BFB2置1时的启动流程，发现了问题所在。见下图：当BFB2置1时，在跳转到用户代码（Bank2或者Bank1）之前，系统bootloader会检查栈顶的位置是否在SRAM区域，也就是检查是否落在0X20000000开头的地址。如果不是，就会一直停在bootloader中，不继续执行。这也就是我们前面看到的程序不能正常运行的原因。当将BFB2位清除后，问题马上解决了。而且对比当CSTACK设置在CCM RAM时还能正常工作的板子，发现这一位都是没有置1的。找到程序不能正常运行原因后，我们就从错误的方向回到正途，开始寻找Option bytes被修改的原因了。 1
2017-1-12 13:37:09　　评论淘帖0 举报相关推荐 • 如何使用STM32F4中的CCM内存 2445 • 你知道STM32F4中的CCM内存该如何使用？ 3873 • 如何正确的使用STM32F4中的CCM内存 6236 • MCU_STM32F4xx使用CCM RAM 11 • 使用STM32F4芯片验证SPI功能的问题分析 2163 • STM32F4 31 • STM32F4开发板STM32F4如何驱动外部SRAM芯片 2932 • STM32F4 简介 23 • 【STM32】STM32F4时钟系统 46 • 结合STM32F4关于CAN基本的信息描述 3973