Arch_Main.c中有一个错误
CS_Table当前声明为UInt8_t数组，因此具有对齐1。但是，在引导期间，存在将16位数据存储到此缓冲区中的存储指令。
我碰巧在我的应用程序中有变量，当我查看.map文件时，使CS_Table获得一个奇怪的地址。然后在引导期间执行硬盘处理程序。
在我改变__Attribute __（（第（“cs_area”），zero_init））到__Attribute __（（“cs_area”），zero_init，对齐（2））），它再次运行良好。
关键词：
设备：
谢谢JoacimWe，我会把它重新归还给SW团队。BR JE_DIALOG.
嗨Joacimwe，
ZERO_INIT区域将在引导期间完全初始化为全零，因此存储操作不会在当时的CS_TABLE上发生。
在我测试的时候，在ZERO_INIT区域中分配的全局变量在零_INIT区域中分配的全局变量将不会导致硬盘重新执行：
NOTALIGNED 0x200090F0数据3 ARCH_MAIN.O（CS_AREA）
NOTALIGNED2 0x200090F3数据8 ARCH_MAIN.O（CS_AREA）
因此，我猜硬盘无法通过存储cs_table而不是引起的，而是由访问其他全局变量引起的，其地址受CS_Table启动地址影响。
您是否可以帮助您上传您的分散加载文件和输出的地图文件来检查？
谢谢！
你好。这些是重现的步骤：
1.解压缩DA14580_581_SDK_3.0.8.0.zip。
2.在Keil中打开项目template_581.uvproj。
3.在DA14580_CONFIG中设置最大连接到8.H：
/ *最大用户连接* /
#define ble_connection_max_user 8.
4.在app_template_proj.c中将以下代码添加到app_init_func（）：
静态挥发性Char Buf [1357];
buf [0] = 0;
5.按Build（F7）。
6.配置正确的SW调试器并在DA14581上开始调试（我使用devkit基本）。
7.您现在将达到hardfault_handlerc。
从生成的.map文件中提取的相关部分：
init.s 0x00000000号0 init.o绝对
Retention_mem_area0 0x00080328第28节UART2.O（RETENTE_MEM_AREA0）
UART2_ENV 0x00080328数据28 UART2.O（RETENT_MEM_AREA0）
.bss 0x00080908第188节GPIO.O（.bss）
.bss 0x000809c4第1365节app_template_proj.o（.bss）
Buf 0x000809cc数据1357 app_template_proj.o（.bss）
CS_AREA 0x00080F19第120节ACH_MAIN.O（CS_AREA）
heap_msg_area 0x00080f94第6252节jump_table.o（heap_msg_area）
Retention_mem_area0 0x00082800第36节APP_SEC.O（RETETING_MEM_AREA0）
在这里，您可以看到，CS_AREA放在奇数地址。如果我开始调试并在Arch_main中设置一个断点并通过每个代码行踩下，当下一行是“RWIP_INIT（错误）;”我按“步骤”，调用硬盘处理程序。
（忽略通常会将设备角色设置为中央的事实，以使8个连接合理，因为在调用app_configuration_func之前调用硬盘处理程序）。
尊敬的顾客，
感谢您的详细信息。
We’ve reproduced this issue and we get to know the root cause is the section cs_area is assigned with an odd start address following the bss region of app_template_proj.o, so during the initialization of cs_area, the 16 bits access offences the 0x00080f18 address belonging to another bss region. So, yes, your judge is right.
0x00080908 0x000000BC零RW 630 .bss gpio.o
0x000809C4 0x00000555零RW 1431 .bss app_template_proj.o
0x00080f19 0x00000078 Zero RW 117 CS_AREA ARCH_MAIN.O
0x00080f91 0x00000003垫
0x00080f94 0x0000186c zer rw 288 heap_msg_area jump_table.o
0x00082800 0x00000024 ZERO RW 1373 RETENT_MEM_AREA0 APP_SEC.O
我们还确认您的修复是此错误的最佳方式。
因为CS_AREA是来自地址方面的第一个部分，而下面的明确定义的部分eAP_ENV_AREA，则将通过链接器自动填充heap_msg_area和heap_db_area，如果我们可以确保CS_AREA的开始地址对齐，则此BUG可以确定地固定。
再次感谢您的发现！
我们将在下一个版本SDK版本中添加以下修复。
#ifndef __da14581__
#if（ble_connection_max_user> 4）
volatile uint8_t cs_table [em_ble_cs_count_user * reg_ble_em_cs_size] __attribute __（（部分（“cs_area”），zero_init，对齐（4）））;
＃万一
＃别的
#if（ble_connection_max_user> 1）
volatile uint8_t cs_table [（ble_connection_max + 2）* reg_ble_em_wpb_size * 2] __属性__（（部分（“cs_area”），zero_init，对齐（4）））;
＃万一
＃万一