我注意到，Cortex Generic用户指南指出硬盘可以出现如下：
试图加载或存储到未对齐的地址
DA14580也是这样吗?如果是，什么被认为是对齐的?8位?16位?32位?
如果一个有16位对齐，我需要小心我如何定义结构或编译器适当填充我?
我如何使用编译器不会保护的C代码调用这样的错误?memcpy,指针?
嗨Brian，
我认为如果您使用了C代码，则不应对齐问题，因为C编译器将进行更正。如果您不需要进行对齐，但不应导致内存问题可能会有笨拙。
问候！PY
但是我总是可以通过删除已声明和实现(但未使用)的结构中的元素来导致错误。故障是由STRH指令触发的。图中显示结构(mds_data)位于一些arch_main代码的前面，如下所示:
rwip_rf 0x0008071c Data 0 rom_symdef.txtmds_data 0x00080768数据248 app.o（.bss）cs_area$$Base 0x00080860 Number 0 arch_main.o(cs_area)cs_table 0x00080860 Data 546 arch_main.o(cs_area)
使用该结构中未使用的元素将触发STRH指令的错误。有趣的是，我访问的代码(除了arch_main)都没有执行。我可以在arch_main while循环中放置一个断点，并通过该循环，但在应用程序代码中，通常先热(app.c中的app_init())的位置永远不会被击中。在出现硬故障之前，可能需要10秒左右的时间。
你好布莱恩,
你能共享结构定义吗？
是这里struct mds_data_tag.{unsigned char systemid [8];unsigned char mapryername [32];unsigned char modelnumber [32];unsigned char serialnumber [32];unsigned char firmwarerevision [32];无符号字符hardwareRevision [32];无符号字符softwareRevision [32];unsigned char pnpid [8];无符号字符continuaMajorVersion;无符号字符continuaMinorVersion;unsigned char numberofcertications;无符号短*证书;无符号短regStatus;未签名的Char Batteryvel;无符号char longeoftimedata;unsigned char agentcurrentime [8];毫无符号的长度;无符号短timeSyncMethod;无符号字符ahdCurrentTime [8];无符号短ahdAccuracy;unsigned short ahdtimesyncmethod;}；
代码中目前只使用结构开头的字符串。但是，我从来没有用到app_init()，所以这是一个有争议的问题。该错误是通过删除char pnpId[8]后的某些元素并保持'strings'集合相同而产生的。导致这种行为的一个例子是
struct mds_data_tag.{unsigned char systemid [8];unsigned char mapryername [32];unsigned char modelnumber [32];unsigned char serialnumber [32];unsigned char firmwarerevision [32];无符号字符hardwareRevision [32];无符号字符softwareRevision [32];unsigned char pnpid [8];无符号字符continuaMajorVersion;}；
布莱恩,
我会有兴趣听到你是否找到了这个解决方案。这一周似乎对话有点慢
我还没有找到解决方案，但我发现，每当将数组放在系统关键的东西(比如一个系统堆)之前时，往往会出现问题(硬故障)。我在地图上看过了。我在几个数组案例中都看到过这种情况。一个问题可能是，我正在最高的优化级别上运行，快要耗尽系统空间，以至于必须在优化模式下运行。如果我能让这些数组不在这些堆或系统数据的其他区域旁边，崩溃就会消失。还有另一个我们正在处理的数组，当它大于100字节时，它被放在非保留堆的前面。在这一点上我们得到了这个误差。在100字节时，映射发生了显著的变化，代码开始运行。我们仍然不能弄清楚，因为缓冲区只在一个区域使用，它非常简单。缺点是人们无法控制如何在内存中放置细节(…我也不想这样)。
我们有一些类似的问题。关于这个问题你有什么进展吗?
嗨yutaka，
对Cortex-M0处理器上的未对准访问没有支持。任何尝试执行未对齐的内存访问操作会导致硬故障异常。
以下链接可以找到更多信息。
http：//infocenter.arm.com/help/index.jsp？主题= / com.arm.doc.dui0497a / bab ...
由于MT_dialog
但是在我们的产品中，rwip_schedule()出现了Hard fault。Hard故障是由错误的参数引起的吗?
有很多原因可能会发生硬断层。
如何知道在rwip_schedule()期间会发生硬故障?您是否检查过PC，并且在处理器停止之前的地址(在硬故障处理程序调试实现中)对应于map文件中的rwip_schedule()函数?你指的是什么参数?rwip_schedule()正在调度由堆栈或应用程序接收的消息，并调用相应的处理程序，这有点不太可能是导致Hardfault_handler()发生的函数。
我检查了步骤执行。我检查了堆栈内存。我发现发生了细节的地址。
地址:0 x324ccLDRH R3，[R1，R3]
R1:0x00000003R3:0x0003E350
来自非法地址的CPU负载。
从映射文件。> ke_queue_extract 0x00032441 Thumb Code 0 rom_symdef.txt> ke_queue_insert 0x0003247f Thumb Code 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.0003274 d LR ke_task_handler_get0000000000000000 R0.00000000 R1.000817 a8 R400000000 R5.50000020 R600000004 R7200055 f3 LR patched_gapm_adv_op_sanity000805 e4 R400000000 R5.50000020 R600032181 LR ke_event_schedule50000000 R4.00032DD9 LR RWIP_Schedule.50000000 R4.20000671 lr main_func.000000000000000020006B1C.20005 c01
备注(来自MAP档案)ke_event_schedule 0x0003213d Thumb Code 0 rom_symdef.txtke_task_handler_get 0x000326EB Thumb代码0 rom_symdef.txt绝对rwip_schedule 0x00032dc9 Thumb Code 0main_func 0x2000058b Thumb Code 592 arch_main.o(.text)
我从你上传的图片中看到你一直通过堆栈追踪函数。当在硬盘或NMI中时，SDK存储在两个不同地址中的寄存器的最后值为0x81800和0x81850一个用于硬盘驱动器，另一个用于NMI。从那里，您可以找到代码点击硬盘的地址，而不会努力从堆栈中追踪。现在，据我所知，它追溯到系统不断使用的函数，以便安排事件。这种情况发生的最可能原因是数据损坏，也许是无效的处理程序指针或类似的东西。此外，如果您可以弄清楚发生这种情况时的任何条件，您可以找到导致应用程序中这种行为的原因，尝试查找此错误是否发生在某些特定模式中，或者在应用程序中执行特定操作时发生此错误。
嗨Brian，
我认为如果您使用了C代码，则不应对齐问题，因为C编译器将进行更正。如果您不需要进行对齐，但不应导致内存问题可能会有笨拙。
问候！
PY
但是我总是可以通过删除已声明和实现(但未使用)的结构中的元素来导致错误。故障是由STRH指令触发的。图中显示结构(mds_data)位于一些arch_main代码的前面，如下所示:
rwip_rf 0x0008071c Data 0 rom_symdef.txt
mds_data 0x00080768数据248 app.o（.bss）
cs_area$$Base 0x00080860 Number 0 arch_main.o(cs_area)
cs_table 0x00080860 Data 546 arch_main.o(cs_area)
使用该结构中未使用的元素将触发STRH指令的错误。有趣的是，我访问的代码(除了arch_main)都没有执行。我可以在arch_main while循环中放置一个断点，并通过该循环，但在应用程序代码中，通常先热(app.c中的app_init())的位置永远不会被击中。在出现硬故障之前，可能需要10秒左右的时间。
你好布莱恩,
你能共享结构定义吗？
是这里
struct mds_data_tag.
{
unsigned char systemid [8];
unsigned char mapryername [32];
unsigned char modelnumber [32];
unsigned char serialnumber [32];
unsigned char firmwarerevision [32];
无符号字符hardwareRevision [32];
无符号字符softwareRevision [32];
unsigned char pnpid [8];
无符号字符continuaMajorVersion;
无符号字符continuaMinorVersion;
unsigned char numberofcertications;
无符号短*证书;
无符号短regStatus;
未签名的Char Batteryvel;
无符号char longeoftimedata;
unsigned char agentcurrentime [8];
毫无符号的长度;
无符号短timeSyncMethod;
无符号字符ahdCurrentTime [8];
无符号短ahdAccuracy;
unsigned short ahdtimesyncmethod;
}；
代码中目前只使用结构开头的字符串。但是，我从来没有用到app_init()，所以这是一个有争议的问题。该错误是通过删除char pnpId[8]后的某些元素并保持'strings'集合相同而产生的。导致这种行为的一个例子是
struct mds_data_tag.
{
unsigned char systemid [8];
unsigned char mapryername [32];
unsigned char modelnumber [32];
unsigned char serialnumber [32];
unsigned char firmwarerevision [32];
无符号字符hardwareRevision [32];
无符号字符softwareRevision [32];
unsigned char pnpid [8];
无符号字符continuaMajorVersion;
}；
布莱恩,
我会有兴趣听到你是否找到了这个解决方案。这一周似乎对话有点慢
我还没有找到解决方案，但我发现，每当将数组放在系统关键的东西(比如一个系统堆)之前时，往往会出现问题(硬故障)。我在地图上看过了。我在几个数组案例中都看到过这种情况。一个问题可能是，我正在最高的优化级别上运行，快要耗尽系统空间，以至于必须在优化模式下运行。如果我能让这些数组不在这些堆或系统数据的其他区域旁边，崩溃就会消失。还有另一个我们正在处理的数组，当它大于100字节时，它被放在非保留堆的前面。在这一点上我们得到了这个误差。在100字节时，映射发生了显著的变化，代码开始运行。我们仍然不能弄清楚，因为缓冲区只在一个区域使用，它非常简单。缺点是人们无法控制如何在内存中放置细节(…我也不想这样)。
我们有一些类似的问题。
关于这个问题你有什么进展吗?
嗨yutaka，
对Cortex-M0处理器上的未对准访问没有支持。任何尝试执行未对齐的内存访问操作会导致硬故障异常。
以下链接可以找到更多信息。
http：//infocenter.arm.com/help/index.jsp？主题= / com.arm.doc.dui0497a / bab ...
由于MT_dialog
但是在我们的产品中，rwip_schedule()出现了Hard fault。
Hard故障是由错误的参数引起的吗?
嗨yutaka，
有很多原因可能会发生硬断层。
如何知道在rwip_schedule()期间会发生硬故障?您是否检查过PC，并且在处理器停止之前的地址(在硬故障处理程序调试实现中)对应于map文件中的rwip_schedule()函数?你指的是什么参数?rwip_schedule()正在调度由堆栈或应用程序接收的消息，并调用相应的处理程序，这有点不太可能是导致Hardfault_handler()发生的函数。
由于MT_dialog
我检查了步骤执行。
我检查了堆栈内存。
我发现发生了细节的地址。
地址:0 x324cc
LDRH R3，[R1，R3]
R1:0x00000003
R3:0x0003E350
来自非法地址的CPU负载。
从映射文件。
> ke_queue_extract 0x00032441 Thumb Code 0 rom_symdef.txt
> ke_queue_insert 0x0003247f Thumb Code 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.
0003274 d LR ke_task_handler_get
00000000
00000000 R0.
00000000 R1.
000817 a8 R4
00000000 R5.
50000020 R6
00000004 R7
200055 f3 LR patched_gapm_adv_op_sanity
000805 e4 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.
20005 c01
备注(来自MAP档案)
ke_event_schedule 0x0003213d Thumb Code 0 rom_symdef.txt
ke_task_handler_get 0x000326EB Thumb代码0 rom_symdef.txt绝对
rwip_schedule 0x00032dc9 Thumb Code 0
main_func 0x2000058b Thumb Code 592 arch_main.o(.text)
嗨yutaka，
我从你上传的图片中看到你一直通过堆栈追踪函数。当在硬盘或NMI中时，SDK存储在两个不同地址中的寄存器的最后值为0x81800和0x81850一个用于硬盘驱动器，另一个用于NMI。从那里，您可以找到代码点击硬盘的地址，而不会努力从堆栈中追踪。现在，据我所知，它追溯到系统不断使用的函数，以便安排事件。这种情况发生的最可能原因是数据损坏，也许是无效的处理程序指针或类似的东西。此外，如果您可以弄清楚发生这种情况时的任何条件，您可以找到导致应用程序中这种行为的原因，尝试查找此错误是否发生在某些特定模式中，或者在应用程序中执行特定操作时发生此错误。
由于MT_dialog