mdk错误记录（持续更新）

今天药忘吃喽~ 2022-06-02 00:50 270阅读 0赞

1、 warning: \#61-D: integer operation result is out of range

由于编译器默认signed int即32位有符号整数类型,而1<<31实际为0x80000000,  
这样就有可能改写了符号位(最高位)  
依此类推,(2<<30),(3<<29)...等都会出现编译警告问题.  
解决办法为: ((unsigned int)1<<31),((unsigned int)2<<30),...

2、warning: \#3048-D: inline assembly not permitted when generating Thumb1 code

原文地址::[http://www.openedv.com/posts/list/0/55803.htm;jsessionid=BF32A849CB8EF733FEEC85010EBCE48C][http_www.openedv.com_posts_list_0_55803.htm_jsessionid_BF32A849CB8EF733FEEC85010EBCE48C]

void WFI\_SET(void)  
\{  
\_\_ASM volatile("wfi");  
\}  
//关闭所有中断  
void INTX\_DISABLE(void)  
\{  
\_\_ASM volatile("cpsid i");  
\}  
//开启所有中断  
void INTX\_ENABLE(void)  
\{  
\_\_ASM volatile("cpsie i");  
\}  
//设置栈顶地址  
//addr:栈顶地址  
\_\_asm void MSR\_MSP(u32 addr)  
\{  
MSR MSP, r0 //set Main Stack value  
BX r14  
\}

//===========修改如下就可以了==============//

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>01</code></td> 
   <td style="vertical-align:top;"><code>//THUMB指令不支持汇编内联</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>02</code></td> 
   <td style="vertical-align:top;"><code>//采用如下方法实现执行汇编指令WFI&nbsp;</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>07</code></td> 
   <td style="vertical-align:top;"><code>//关闭所有中断</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>08</code></td> 
   <td style="vertical-align:top;"><code>__asm&nbsp;</code><code>void</code>&nbsp;<code>INTX_DISABLE(</code><code>void</code><code>)</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>10</code></td> 
   <td style="vertical-align:top;"><code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>CPSID I;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>12</code></td> 
   <td style="vertical-align:top;"><code>//开启所有中断</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>13</code></td> 
   <td style="vertical-align:top;"><code>__asm&nbsp;</code><code>void</code>&nbsp;<code>INTX_ENABLE(</code><code>void</code><code>)</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>15</code></td> 
   <td style="vertical-align:top;"><code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>CPSIE I;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>17</code></td> 
   <td style="vertical-align:top;"><code>//设置栈顶地址</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td style="vertical-align:top;"><code>21</code></td> 
   <td style="vertical-align:top;"><code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>MSR MSP, r0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>//set Main Stack value</code></td> 
  </tr> 
 </tbody> 
</table>

3、提示查找不到AT91SAM9G45的驱动文件

我看了下在ARM的ATMEL的INC文件下有这颗芯片的文件，为什么找不到呢？

我猜想可能是由于我先安装的MDK，后安装的C51，由于版本或者软件本身的bug

导致的。重装MDK，解决。

4、const

以前一直用PIC和瑞萨，以为静态局部变量+const还是存贮在RAM里面，今天

分析了MDK的map文件，发现是存贮在ROM里面。

![aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDU0Njk1Nw][]

![aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDU1NTkxMA][]

![aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDYwMjE5OA][]

![aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDYwNzQxMg][]

5、字符串显示bug

以前一直习惯于用十六进制打印log，分析协议。最近在调试AT指令，改为字符输出log。

期间发现一个很奇怪的问题，下面这段代码如果单步执行没有问题，可以打印输出，全速执行就不行。

{        
            uint16_t    j=0;
            //delay_ms(50);
            TRACE_DEBUG("\r\nJZQ_AT_CMD_MYNETWRITE   %d  \r\n",hwSize);
            for(j=0;j<hwSize;j++){
                printf("%02X",pchBuffer[j]);
            }
            printf("\r\n");
        }

加上优化级别为0，也不行。但是其他地方的Log都正常啊，这是为什么呢？

经过前后的log输出，和改为16进制输出，最后得到结论，根本原因是字符串结束符问题。

前面的Log是直接打印的通信协议，是16进制，并咩有做格式化，同时由于log输出太快，这就导致

字符显示时候缓存里面有好几个log包，但是串口助手就当做一个字符串，但是这几个log包当中又正好包含

\\0，这个恰巧也是字符串结束符，因此字符显示时候当遇到\\0就认为字符串结束了，后面再有也不显示了。

如果换位16进制，后面是有打印的。

解决方法：

1）同时开启串口监视助手和串口调试助手，一个16进制显示，一个字符显示；

2）每个log输出后面都加延时；

3）过滤掉\\0结束符；

结合实际调试，我采用的1和3的方法，1是最笨的，但是查看Log真的头大；3需要有个log缓存，然后输出的

时候做过滤，但是实时性最高，不影响实际程序；不建议加延时，影响代码实时性。

6、如果提示下面这个信息，则可能是你的C文件有重名字的。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70][]

7、“窥孔优化”惹的祸

有段代码这样写的：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 1][]

测试中发现有类似“死机”的现象，最后追到是上面那段代码while(1)里面死循环，原因就是局部优化的问题，pchBuffer和hwSize

前面加volatile解决。

8、没有用到的变量影响

代码如下：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 2][]

其中tServiceProtocolLoginProcess变量没有用到，测试中发现如果优化级别O0则正常，如果是O3，则在某些情况下会“死机”，最后定位到程序跑到：

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3][]

然后我就把没有用到的变量屏蔽掉，问题解决；

然后给大家一个忠告：mdk armcc编译器不要把O3和 optimize for time 同时打开，armclang编译器则没有问题。

9、非对齐访问问题

在调试m0+内核时候，发现进入HardFault\_Handler。最后追到是

![20190809110606218.png][]

再往下看：

![20190809110656533.png][]

这个逻辑一直在用，而且在407,103等上面都跑的正常。

再追，用断言判断指针是否为空指针：

assert\_param((&(ptRoutingTableItem->ptNext)));

发现指针都飞空。这就奇怪了，把地址打印出来，发现有非对齐指针，难道因为这个？

原定定义为：

static uint8\_t s\_chRoutingTableBuffer\[50\*sizeof(routing\_table\_t)\];

修改为：

static uint32\_t s\_chRoutingTableBuffer\[(50\*sizeof(routing\_table\_t))>>2\];

发现正常了。。。。。欲哭无泪啊！

[http_www.openedv.com_posts_list_0_55803.htm_jsessionid_BF32A849CB8EF733FEEC85010EBCE48C]: http://www.openedv.com/posts/list/0/55803.htm;jsessionid=BF32A849CB8EF733FEEC85010EBCE48C
[aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDU0Njk1Nw]: /images/20220602/d273b8358b7b47a5b66e8b6eb732f42e.png
[aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDU1NTkxMA]: /images/20220602/c258c77beb1041f2964bdacfc75b09c6.png
[aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDYwMjE5OA]: /images/20220602/6ebfb85ef0ff4a9d84f2c5889a80ca7c.png
[aHR0cHM6Ly9pbWctYmxvZy5jc2RuLm5ldC8yMDE4MDMxNjE1MDYwNzQxMg]: /images/20220602/30575800fab94fe29d8592ea0e372843.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70]: /images/20220602/54a1fc06a68744bd9dc7a510697a5e62.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 1]: /images/20220602/931660fe450f42f8acb1bdc790e24a92.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 2]: /images/20220602/b37e20deb81c434db82a834c095273b0.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3d1aGVueW91eXV5b3V5dQ_size_16_color_FFFFFF_t_70 3]: /images/20220602/3e7ec3b9f5d1429487c7c36ea3f7ee15.png
[20190809110606218.png]: /images/20220602/ffc7db25bed14995a9aef47758923256.png
[20190809110656533.png]: /images/20220602/a15b61c470cb44d0b944583e6c40b216.png