我注意到，Cortex Generic用户指南指出硬盘可以出现如下：
一个尝试的加载或存储到未对齐的地址
这对DA14580是真的吗？如果是这样，被认为对齐的是什么？8位？16位？32位？
如果有一个有16位对齐，我需要小心如何定义结构或者编译器适用于我吗？
如何使用编译器无法保护的c - 代码来调用此类错误？memcpy，指针？
嗨Brian，
我认为如果您使用了C代码，则不应对齐问题，因为C编译器将进行更正。如果您不需要进行对齐，但不应导致内存问题可能会有笨拙。
问候！PY
但是，我可以通过删除已解释和实现（但未使用）的结构中的一个元素来始终如一地引起错误。故障由Strs指令触发。该地图显示，结构（MDS_DATA）位于某些ARCH_MAIN代码之前，如下所示：
RWIP_RF 0x0008071C数据0 rom_symdef.txt绝对mds_data 0x00080768数据248 app.o（.bss）CS_AREA $$基础0x00080860号0 ARCH_MAIN.O（CS_AREA）CS_Table 0x00080860数据546 Arch_main.o（cs_area）
使用该结构的未使用元素将触发STRH指令的错误。有趣的是，我没有执行访问（Arch_Main之外）的代码。我可以在Arch_main中放置一个断裂点，而循环和步骤通过该循环，但应用程序代码中通常最热门的位置（app_init（app.cit）从未被命中。出现硬故障之前，最多可能需要10秒左右。
你好Brian，
你能共享结构定义吗？
是这里struct mds_data_tag.{unsigned char systemid [8];unsigned char mapryername [32];unsigned char modelnumber [32];unsigned char serialnumber [32];unsigned char firmwarerevision [32];unsigned char hardwarerevision [32];unsigned char softwarerevision [32];unsigned char pnpid [8];无符号Char ContinuamaJorversion;无符号Char Continuaminorversion;unsigned char numberofcertications;无符号短*证书;unsigned short regstatus;未签名的Char Batteryvel;无符号char longeoftimedata;unsigned char agentcurrentime [8];毫无符号的长度;未签名的短时间;unsigned char ahdcurrenttimtimtime [8];毫无符号短期疾病;unsigned short ahdtimesyncmethod;};
仅在代码中仅使用STRUCT开始时的字符串。但是，我从未到达app_init（），以便是一个实用的点。通过在char pnpid [8]之后删除某些元素并保留一组“字符串”来生成错误。导致行为的示例是
struct mds_data_tag.{unsigned char systemid [8];unsigned char mapryername [32];unsigned char modelnumber [32];unsigned char serialnumber [32];unsigned char firmwarerevision [32];unsigned char hardwarerevision [32];unsigned char softwarerevision [32];unsigned char pnpid [8];无符号Char ContinuamaJorversion;};
布莱恩，
我会有兴趣听到你是否找到了这个解决方案。这一周似乎对话有点慢
我还没有找到解决方案，但我发现每当一个在系统关键的东西之前往往有阵列（如系统堆积）时往往会有麻烦（硬断层）。我在地图中看到了这一点。我已经看到了几个阵列案例相当一致。问题可能是我在最高的优化级别运行，并且我的临界在于我必须以优化模式运行的点。如果我可以以这样的方式发挥，即这些阵列不是这些堆或系统数据的其他领域之一，崩溃消失。还有另一个阵列，我们正在使用它在非保留堆大于100字节之前放置的数组。那时我们得到了那个错误。在100字节以100字节，地图显着移动，代码ran。当缓冲区仅在一个区域使用时，我们仍然无法弄清楚它，这很简单。下方是一个没有控制在该细节（......和我不想的情况下的内存中被放置在内存中。
我们有一些类似的问题。你有关于这个问题的进展吗？
嗨yutaka，
对Cortex-M0处理器上的未对准访问没有支持。任何尝试执行未对齐的内存访问操作会导致硬故障异常。
以下链接可以找到更多信息。
http：//infocenter.arm.com/help/index.jsp？主题= / com.arm.doc.dui0497a / bab ...
谢谢mt_dialog.
但在我们的产品的情况下，RWIP_Schedule（）中发生了硬故障。是否发生了错误的参数发生了？
有很多原因可能会发生硬断层。
您如何知道在RWIP_SCHEDULE（）期间发生的硬故障？您是否检查了PC，在Proccessor Stalls（硬盘处理程序调试实现中）之前的地址对应地图文件中的RWIP_SCHEDULE（）函数？您指的是什么参数？RWIP_Schedule（）正在安排堆栈或应用程序接收的消息，并调用相应的处理程序，这有点不太可能这是导致HardFault_Handler（）发生的函数。
我检查了一步执行。我检查了堆栈内存。我发现发生了细节的地址。
地址：0x324cc.LDRH R3，[R1，R3]
R1：0x00000003R3：0x0003E350.
来自非法地址的CPU负载。
从地图文件。> KE_QUEUE_EXTRACT 0x00032441拇指代码0 rom_symdef.txt绝对> ke_queue_insert 0x0003247F thumb代码0 rom_symdef.txt绝对> ke_task_init 0x0003256D thumb代码0 rom_symdef.txt绝对
地址（0x324cc）在Ke_queue_insert中。ke_queue_insert是否使用了哪个参数？我可以替换这种功能进行调试吗？
我分析了堆栈内存。地址（0x324cc）不是ke_queue_insert。可能是此地址是ke_task_handler_get的子例程。
堆栈内存00000000 R0.00000003 R100007C6A R2.0003E350 R300081004 R120003274D LR.000324CC0100000020006378 R4.0003274D LR KE_TASK_HANDLER_GET.0000000000000000 R0.00000000 R1000817A8 R4.00000000 R5.50000020 R6.00000004 R7.200055f3 lr patched_gapm_adv_op_sanity.000805E4 R400000000 R5.50000020 R6.00032181 LR KE_EVENT_SCHEDULE.50000000 R4.00032DD9 LR RWIP_Schedule.50000000 R4.20000671 lr main_func.000000000000000020006B1C.20005C01.
备注（来自地图文件）KE_EVENT_SCHEDULE 0x0003213D thumb代码0 rom_symdef.txt绝对ke_task_handler_get 0x000326EB Thumb代码0 rom_symdef.txt绝对Rwip_schedule 0x00032DC9拇指代码0 ROM_SYMDEF.txt绝对main_func 0x2000058b thumb代码592 arch_main.o（.text）
我从你上传的图片中看到你一直通过堆栈追踪函数。当在硬盘或NMI中时，SDK存储在两个不同地址中的寄存器的最后值为0x81800和0x81850一个用于硬盘驱动器，另一个用于NMI。从那里，您可以找到代码点击硬盘的地址，而不会努力从堆栈中追踪。现在，据我所知，它追溯到系统不断使用的函数，以便安排事件。最可能发生这种情况的原因是数据损坏，也许是无效的处理程序指针或类似的东西。此外，如果您可以弄清楚发生这种情况时的任何条件，您可以找到导致应用程序中这种行为的原因，尝试查找此错误是否发生在某些特定模式中，或者在应用程序中执行特定操作时发生此错误。
嗨Brian，
我认为如果您使用了C代码，则不应对齐问题，因为C编译器将进行更正。如果您不需要进行对齐，但不应导致内存问题可能会有笨拙。
问候！
PY
但是，我可以通过删除已解释和实现（但未使用）的结构中的一个元素来始终如一地引起错误。故障由Strs指令触发。该地图显示，结构（MDS_DATA）位于某些ARCH_MAIN代码之前，如下所示：
RWIP_RF 0x0008071C数据0 rom_symdef.txt绝对
mds_data 0x00080768数据248 app.o（.bss）
CS_AREA $$基础0x00080860号0 ARCH_MAIN.O（CS_AREA）
CS_Table 0x00080860数据546 Arch_main.o（cs_area）
使用该结构的未使用元素将触发STRH指令的错误。有趣的是，我没有执行访问（Arch_Main之外）的代码。我可以在Arch_main中放置一个断裂点，而循环和步骤通过该循环，但应用程序代码中通常最热门的位置（app_init（app.cit）从未被命中。出现硬故障之前，最多可能需要10秒左右。
你好Brian，
你能共享结构定义吗？
是这里
struct mds_data_tag.
{
unsigned char systemid [8];
unsigned char mapryername [32];
unsigned char modelnumber [32];
unsigned char serialnumber [32];
unsigned char firmwarerevision [32];
unsigned char hardwarerevision [32];
unsigned char softwarerevision [32];
unsigned char pnpid [8];
无符号Char ContinuamaJorversion;
无符号Char Continuaminorversion;
unsigned char numberofcertications;
无符号短*证书;
unsigned short regstatus;
未签名的Char Batteryvel;
无符号char longeoftimedata;
unsigned char agentcurrentime [8];
毫无符号的长度;
未签名的短时间;
unsigned char ahdcurrenttimtimtime [8];
毫无符号短期疾病;
unsigned short ahdtimesyncmethod;
};
仅在代码中仅使用STRUCT开始时的字符串。但是，我从未到达app_init（），以便是一个实用的点。通过在char pnpid [8]之后删除某些元素并保留一组“字符串”来生成错误。导致行为的示例是
struct mds_data_tag.
{
unsigned char systemid [8];
unsigned char mapryername [32];
unsigned char modelnumber [32];
unsigned char serialnumber [32];
unsigned char firmwarerevision [32];
unsigned char hardwarerevision [32];
unsigned char softwarerevision [32];
unsigned char pnpid [8];
无符号Char ContinuamaJorversion;
};
布莱恩，
我会有兴趣听到你是否找到了这个解决方案。这一周似乎对话有点慢
我还没有找到解决方案，但我发现每当一个在系统关键的东西之前往往有阵列（如系统堆积）时往往会有麻烦（硬断层）。我在地图中看到了这一点。我已经看到了几个阵列案例相当一致。问题可能是我在最高的优化级别运行，并且我的临界在于我必须以优化模式运行的点。如果我可以以这样的方式发挥，即这些阵列不是这些堆或系统数据的其他领域之一，崩溃消失。还有另一个阵列，我们正在使用它在非保留堆大于100字节之前放置的数组。那时我们得到了那个错误。在100字节以100字节，地图显着移动，代码ran。当缓冲区仅在一个区域使用时，我们仍然无法弄清楚它，这很简单。下方是一个没有控制在该细节（......和我不想的情况下的内存中被放置在内存中。
我们有一些类似的问题。
你有关于这个问题的进展吗？
嗨yutaka，
对Cortex-M0处理器上的未对准访问没有支持。任何尝试执行未对齐的内存访问操作会导致硬故障异常。
以下链接可以找到更多信息。
http：//infocenter.arm.com/help/index.jsp？主题= / com.arm.doc.dui0497a / bab ...
谢谢mt_dialog.
但在我们的产品的情况下，RWIP_Schedule（）中发生了硬故障。
是否发生了错误的参数发生了？
嗨yutaka，
有很多原因可能会发生硬断层。
您如何知道在RWIP_SCHEDULE（）期间发生的硬故障？您是否检查了PC，在Proccessor Stalls（硬盘处理程序调试实现中）之前的地址对应地图文件中的RWIP_SCHEDULE（）函数？您指的是什么参数？RWIP_Schedule（）正在安排堆栈或应用程序接收的消息，并调用相应的处理程序，这有点不太可能这是导致HardFault_Handler（）发生的函数。
谢谢mt_dialog.
我检查了一步执行。
我检查了堆栈内存。
我发现发生了细节的地址。
地址：0x324cc.
LDRH R3，[R1，R3]
R1：0x00000003
R3：0x0003E350.
来自非法地址的CPU负载。
从地图文件。
> KE_QUEUE_EXTRACT 0x00032441拇指代码0 rom_symdef.txt绝对
> ke_queue_insert 0x0003247F thumb代码0 rom_symdef.txt绝对
> ke_task_init 0x0003256D thumb代码0 rom_symdef.txt绝对
地址（0x324cc）在Ke_queue_insert中。
ke_queue_insert是否使用了哪个参数？
我可以替换这种功能进行调试吗？
我分析了堆栈内存。
地址（0x324cc）不是ke_queue_insert。
可能是此地址是ke_task_handler_get的子例程。
堆栈内存
00000000 R0.
00000003 R1
00007C6A R2.
0003E350 R3
00081004 R12
0003274D LR.
000324CC
01000000
20006378 R4.
0003274D LR KE_TASK_HANDLER_GET.
00000000
00000000 R0.
00000000 R1
000817A8 R4.
00000000 R5.
50000020 R6.
00000004 R7.
200055f3 lr patched_gapm_adv_op_sanity.
000805E4 R4
00000000 R5.
50000020 R6.
00032181 LR KE_EVENT_SCHEDULE.
50000000 R4.
00032DD9 LR RWIP_Schedule.
50000000 R4.
20000671 lr main_func.
00000000
00000000
20006B1C.
20005C01.
备注（来自地图文件）
KE_EVENT_SCHEDULE 0x0003213D thumb代码0 rom_symdef.txt绝对
ke_task_handler_get 0x000326EB Thumb代码0 rom_symdef.txt绝对
Rwip_schedule 0x00032DC9拇指代码0 ROM_SYMDEF.txt绝对
main_func 0x2000058b thumb代码592 arch_main.o（.text）
嗨yutaka，
我从你上传的图片中看到你一直通过堆栈追踪函数。当在硬盘或NMI中时，SDK存储在两个不同地址中的寄存器的最后值为0x81800和0x81850一个用于硬盘驱动器，另一个用于NMI。从那里，您可以找到代码点击硬盘的地址，而不会努力从堆栈中追踪。现在，据我所知，它追溯到系统不断使用的函数，以便安排事件。最可能发生这种情况的原因是数据损坏，也许是无效的处理程序指针或类似的东西。此外，如果您可以弄清楚发生这种情况时的任何条件，您可以找到导致应用程序中这种行为的原因，尝试查找此错误是否发生在某些特定模式中，或者在应用程序中执行特定操作时发生此错误。
谢谢mt_dialog.