一、片内RAM用完了？

2 Q" R( E/ w) Q
* w" z# {$ G4 h& ?曾有两个不同的STM32用户反馈了相似的问题，他们在对STM32F7Cube库里的工程例程进行编译时，发现了一个令人很不解的事。编译的结果提示芯片内的RAM几乎都耗光了。但以他们对工程基本功能的了解，按理说不应该那样，想知道是怎么回事。
' S$ h5 K# `2 c6 H
# K3 g% @+ o6 B
具体情况是这样的：他们先在STM32CubeF7的固件库里打开了一个有关lwip应用的工程示例。比如下面目录处的一个工程，使用ARM MDK进行编译。

! H* I1 j( H' \4 k$ D( e
4 T/ j; v! {. G& [\STM32Cube_FW_F7_V1.15.0\Projects\STM32746G-Discovery\Applications\LwIP\LwIP_HTTP_Server_Netconn_RTOS\MDK-ARM。
( z0 ~" q( w1 j3 q
- P& N' f) ]% M9 _( m
( Y( C& A! c4 l结果发现编译结果提示片内RAM的空间已经基本用完了。但感觉应该用不了那么多RAM内存。客户还想添加自己的其它用户程序，还需使用RAM呢。

9 M# w" ?2 Q4 I$ w
打开相应软件工程，使用ARM MDK进行编译，发现编译结果跟客户反馈的一致。
" e: b  k; W5 g$ x7 R6 C0 d
3 P' U, ]" r% M6 L
5 `2 K8 g4 M* n1 A1 _+ k/ i

0 L* T3 r0 {+ b  U. V
从编译结果来看，感觉RAM真的被用去了320多K，那RAM用到哪里去了呢？打开对应的MAP文件进一步查看，可得到如下数据。

  X' e) o; t6 l* ^7 e0 C4 e: s9 t1 j


9 O/ m1 e* U: a- ^& _5 h. _
先看看芯片内部RAM情况。目前使用的芯片是STM32F746NG，查看其数据手册可知其内部系统RAM容量为320KB【1KB=1024B】,分别由如下三块RAM区域组成，各区域容量及地址范围如下：

% B! M  w2 ]0 L' A- s1 d


- y& f: ?5 L- v6 H* l: a
结合编译结果和上面数据信息来看，貌似RAM真的用完了。既然这样，只好硬着头皮继续查看MAP文件的其它细节,看看RAM到底消耗在哪些地方去了。后来发现在某个地址段有个巨大的PAD补丁填充区。

* S5 n9 T. j! M; a  A) Y, ^
+ O( k( s9 U6 m  H


6 C0 T" N. i: S- ]8 n即从0x2000fd08到0x2004bfff这段区域，共246,520Bytes【即上图黄色区域所指】。
$ r: R! O, E3 m7 b- ^; J
! v0 g+ q/ v7 r/ K1 J
一般来讲，代码编译后产生的PAD补丁块往往是因为地址对齐方面的原因导致的一些不便使用的零散内存碎片，正常来讲，这些补丁块不会大面积的集中在一起。

: h- D. ^1 E% @' u
比如使用下面结构体变量的时候会插入padding.
6 m& N" `" o5 L4 }) B
  B+ @. O0 [( J+ `9 t$ p

6 t4 ~, }) f! f& O8 V) w
# q2 {! R8 d. I5 d% v
但这里提示的补丁块也太大了，高达200多KB而且是连续空间！感觉是哪里误会了。从分析来看，初步判断这个PAD区间应该还是可以被用户使用的。于是尝试在现有代码里随意增加一块16KB的RAM有效使用量，编译一切正常，编译后显示的内存用量结果跟之前几乎一模一样，依然显示RAM用完了。
$ ?; o, b3 A. h# I: ^& w

: b( ?/ y2 {2 T+ m. F但通过查看MAP文件，可以发现上面提到的那个大补丁块空间也随之减小了16KB。显然，RAM并非真正用完了，只是编译器把它当作类似对齐原因导致的补丁块了。现在问题是，怎么会被编译器误判成这么大的一个补丁块呢？
# u' r3 i7 J! F+ G9 U6 P
5 L% |5 |  c4 f. `
9 f% M' f) b$ V3 {& q* |进一步查看MAP和部分代码源文件，我们可以发现有一块RAM区域，即芯片内的SRAM2区域被用户使用attribute关键字自行做了内存使用分配了，即这块内存空间不是交给编译器安排的。【下图中绿色方框内的内存分配】

, }6 S4 t* W. ?5 q) O* X
) t3 R2 F) t9 h' ?& Z( e


& R8 [6 Q4 b5 v结合上面的分析，那个巨大的pad区域正是经编译器分配使用到的RAM空间的末尾地址开始到SRAM2起始地址【0X2004C000】之前的那段空间。
0 W+ {4 _& K* ]
( o" l; W) L; U. W) A
4 u, ?! ?# ~: P! J这里让人想到一个地方，那就是MDK IDE选项配置中Target配置的这个地方：

$ q, w/ W3 T8 O, e2 U1 r
- i9 @) b2 J) c

7 F9 S* T8 v% _& L2 H
这里片内RAM配置是这样的，意味着从0x20000000到0x2004ffff的全部RAM空间交由编译器分配管理。

" P  M" B( s7 ]: |# K) q) }( K

. {1 F% E8 N; \2 }9 G  ~- }* a

而在实际应用代码中，编译器从0x20000000开始分配内存，而SRAM2区域则由用户自行安排使用的。这样的话，经编译器所分配所用到的RAM内存末尾到0x2004BFFF这段未用区域被视为了pad区域。看来只是误会一场。


: R$ P" f5 z( d8 ^9 c" `1 l+ ]那如何消除这个误会呢？我们可以将上面的内存配置项稍微修改下，让SRAM2区域不再让编译器分配管理，这样就避免了编译器分配的内存末尾到SRAM2区域起始地址的这段空间被视为补丁区。像下面一样修改：
; i% Q1 _8 H  f. \7 U& A, T
7 K: ~5 |0 U$ Q! @, {% B7 l3 ?/ c

7 H+ N: H: U" K" |; K) _6 Z
7 D, ~0 w9 R1 j+ f& E
2 X# W, u' P0 B! ?& G; X3 o# j这样修改后再做编译，结果如下，不再给人RAM都用光的感觉了，只用到70多KB的片内RAM。


6 y1 s: A) R8 d" [, K4 B6 z8 ]


2 f* R& O/ t4 n3 c二、Flash编程算法用不了？

' s# `; l- X% }8 {3 [
用人使用STM32F7开发产品，发现编译时找不到合适的Flash算法文件，或者MDK自带的现有FLM文件用不了。具体情况是这样的：
# ?# N: D; \" @0 l3 n
5 }! `' H7 @0 J3 f: c  F2 \, i" Z
0 t! H5 h$ u; S5 I8 ?! e5 U有人使用STM32F750V8开发产品，编译完毕后欲进行下载调试，结果没法完成程序下载，提示FLASH下载错误。
5 J' v* _- r: r& ?! d/ ]

2 \& I6 W8 `% p0 c/ ~+ v
- j" @1 G" d, p4 v

检查了各个配置后，怀疑FLASH算法文件是否有问题。
0 Z. C6 z' V1 w% A
# @6 ~( w/ T) Q  [  n7 J& }
3 X' _3 u/ v/ v- J" L1 O7 A2 ]1 F打开MDK选项配置里flash_download的编程配置页面，那里已经添加了相关FLASH编程算法文件。


) ]! s  Y% O: `9 q: J; M


不过，如果使用STM32芯片做过开发的人可能比较容易发现有个地方有点刺眼，就是起始地址那个地方。用过STM32F0/F1/F4等系列的人可能比较容易发现，那个FLASH起始地址一般是在0x8000000这个地方，这里却是0x00200000。我们再看看MDK选项配置有关内存分配的那个地方，如下图所示：


5 G4 k! c" z: G4 }
- Y* B& H7 z' Y5 s1 {* B# u
$ }$ F/ h3 z' o8 H
/ e; n$ x) _# I1 s这里的片内FLASH默认起始地址却是0x8000000。显然这里跟FLASH编程算法文件的起始地址定义不一致，初步判断应该是这个地方导致的问题。

7 R; F; t* o- W% p
到此，我们有必要看看STM32F7的相关技术手册了关于内部FLASH地址分配的内容。下图是STM32F750片内主从外设及总线的框架图，对于片内FLASH，CPU可以有两条总线通路访问它，一条是通过AXIM接口，经过AXI-AHB桥以64位总线访问，另一条是通过ITCM接口，经过片内ART加速器后访问它。【如下图所示】
0 z) P) F) O) C6 U/ v' e+ G" g2 `
8 z) G" G: J3 R- ^) |
/ M/ W- F0 Z& o1 e$ [


( G  z! O" n! R  o2 i3 C我们通过进一步查看手册，可以得知CPU访问该FLASH区域时因使用不同总线接口而安排了不同的地址访问区域。



1 N2 Q) y  ^2 X, r4 V
5 q* a! [/ A; d
) l0 L* Z  x; P从上面表格可以清楚地看到，CPU从不同接口访问FLASH时其对应地址是不一样的。通过AXIM接口访问内部flash的起始地址为0x08000000,通过ITCM接口访问内部flash的起始地址是0x00200000.
. R/ S  H" U. O
; I* `4 D6 a8 `  X
结合到上面案例，MDK选项配置中Target页面的片内FLASH地址安排与Flash算法定义的地址不一致导致程序下载失败。那么,我们可以将二者的地址及大小调整得一致，具体根据实际开发需求来调整，即根据你希望CPU通过哪个接口来访问FLASH来做相应调整。
4 K. y, s; A0 p/ Q' @# I' [, G$ ~

/ t. A0 z5 m5 p/ q' x( I) u1、如果希望走ITCM接口来访问，我们就将Target页面的FLASH存储起始地址与FLASH算法文件定义的起始地址都设置为0x00200000，如下图所示：

7 U7 i9 E& J( R! I1 m6 F. ?. F2 O

: I9 M9 `9 @+ _0 a7 B
, k2 a9 Z3 A9 A) r! P) h
1 a( C2 o. e- P* Q; v3 M2 r9 k4 y4 z2、如果希望走AXIM接口来访问，我们就将FLASH算法文件定义的起始地址与Target页面定义得一致，这里就是0x08000000.
/ {- [" W6 c; w+ L0 e! _1 [; z

基于MDK提供的FLASH算法文件我们可以直接修改其起始地址及大小。
2 G* k# u: \3 `( }6 o: p7 g

5 M) l+ V& o2 C/ P比如，如果刚加载进来的算法文件是基于ITCM接口的地址定义，如下图所示。
3 Q% _: h! {$ V9 l/ U



; A1 {7 i/ F0 w- E, |4 B
4 }. R& U# f" K) O4 v我们可以直接基于上面算法文件参数进行起始地址修改，即修改椭圆里的起始地址数据，修改完毕后点击下方的OK按钮即可。操作如下图所示：
( b- s! T* c" i


8 v2 e% b8 O- G& ~* l
$ [$ [. {3 K) M7 [. Z* P
; B. w4 J, ~. F1 ~- k' |【注：我所用ARM MDK版本为5.28。】
7 q) T% O" |" i) `! ]# p+ x; K

& g7 S( z$ l$ r+ c基于修改后的配置，再进行编译后即可进行下载调试。
, o( X2 B9 P) t  o- I9 g" e8 Z

' S0 ^* D: A) E( V


; i; b, `6 w4 w3 E8 X1 @& s  [

学习一下。