前言
想写这篇文章的起因是因为有客户在使用 CCM RAM 的过程中遇到了问题。客户用的是 STM32F427 芯片，程序将 CSTACK放在 CCM RAM 中，结果测试过一段时间的板子都出现了不能正常运行的情况。这个现象一度让我们怀疑是否是 CCM RAM在测试过程中遭到了破坏，也导致我们在解决问题的道路上浪费了不少时间。事实证明我们的 CCM RAM 并没有那么脆弱，而解决问题时多从多个角度进行验证，不要放过所有的出问题的可能性也很重要。出问题的原因我会在本文中进行解释。但在具体讨论这个问题之前，我想先介绍一下 STM32F427 这款芯片上的 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 所以不能访问 CCM RAM。但是从上图我们还能看到，对于 F303 的 CCM RAM 它连接到了数据总线和指令总线上，所以 F303 的 CCM RAM 既可以放数据也可以执行代码。但是 F427 的 CCM RAM 只连接到了数据总线，所以 F427 的 CCM RAM 不能执行代码。这一点需要注意。
数据和代码放在 CCM RAM 的好处是，访问和执行的速度更快。在这里，我就不再赘述了。下面就来讲讲前面在F427 上遇到的问题。


客户问题描述
客户的问题是在做了一段时间的测试后出现的。 一批板子全部出问题。客户方面进行分析后用了一段简单的点灯程序进行测试，发现当 CSTACK 放在不同的位置时程序表现不一样。CSTACK 放在 SRAM 中时，工作正常，但放在 CCM RAM中就不能正常运行。从这个现象看很像是 CCM RAM 出问题了，而恰好只有经过测试的板子有问题，其他板子全部没有问题。


测试过程
拿到客户的板子和测试代码后很容易就重现了客户描述的现象。
首先检查了客户测试代码中的 link 文件。发现 link 文件写的没错。

1. /*###ICF### Section handled by ICF editor, don't touch! ****/
   
2. /*-Editor annotation file-*/
   
3. /* IcfEditorFile="$TOOLKIT_DIR$\config\ide\IcfEditor\cortex_v1_0.xml" */
   
4. /*-Specials-*/
   
5. define symbol __ICFEDIT_intvec_start__ = 0x08000000;
   
6. /*-Memory Regions-*/
   
7. define symbol __ICFEDIT_region_ROM_start__ = 0x08000000;
   
8. define symbol __ICFEDIT_region_ROM_end__ = 0x081FFFFF;
   
9. define symbol __ICFEDIT_region_RAM_start__ = 0x20000000;
   
10. define symbol __ICFEDIT_region_RAM_end__ = 0x2002FFFF;
    
11. define symbol __ICFEDIT_region_CCMRAM_start__ = 0x10000000;
    
12. define symbol __ICFEDIT_region_CCMRAM_end__ = 0x1000FFFF;
    
13. /*-Sizes-*/
    
14. define symbol __ICFEDIT_size_cstack__ = 0x400;
    
15. define symbol __ICFEDIT_size_heap__ = 0x200;
    
16. /**** End of ICF editor section. ###ICF###*/
    
17. define memory mem with size = 4G;
    
18. define region ROM_region = mem:[from __ICFEDIT_region_ROM_start__ to
    
19. __ICFEDIT_region_ROM_end__];
    
20. define region RAM_region = mem:[from __ICFEDIT_region_RAM_start__ to
    
21. __ICFEDIT_region_RAM_end__];
    
22. define region CCMRAM_region = mem:[from __ICFEDIT_region_CCMRAM_start__ to
    
23. __ICFEDIT_region_CCMRAM_end__];
    
24. define block CSTACK with alignment = 8, size = __ICFEDIT_size_cstack__ { };
    
25. define block HEAP with alignment = 8, size = __ICFEDIT_size_heap__ { };
    
26. initialize by copy { readwrite };
    
27. do not initialize { section .noinit };
    
28. place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };
    
29. /*place at address mem:__ICFEDIT_region_CCMRAM_start__ { block CSTACK };*/
    
30. place in CCMRAM_region {block CSTACK};
    
31. place in ROM_region { readonly };
    
32. 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 中，然后在程序运行的时候对 CCMRAM 地址空间进行遍历，对地址 0x10000000 到 0x1000FFFF 空间逐次进行读写操作。发现程序正常运行，CCM RAM 的读写正常。
实验做到这里，基本可以确定 CCM RAM 没有损坏。但为什么 CSTACK 不能放到 CCM RAM 中呢？
然后我们又做了第三个实验。
测试三：
对比拿到的坏板子的 Option bytes 的值与默认值。逐个检测不同的位是否和问题相关。发现 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 被修改的原因了。