我注意到，Cortex Generic用户指南指出，硬故障可能会出现如下情况:
试图加载或存储到未对齐的地址
DA14580也是这样吗?如果是，什么被认为是对齐的?8位?16位?32位?
如果一个有16位对齐，我需要小心我如何定义结构或编译器适当填充我?
我如何使用编译器不会保护的C代码调用这样的错误?memcpy,指针?
你好布莱恩,
我认为如果你使用C代码，不应该有对齐问题，因为C编译器会做纠正。如果不注意对齐，可能会有多功能，但不会导致内存问题。
的问候!PY
但是我总是可以通过删除已声明和实现(但未使用)的结构中的元素来导致错误。故障是由STRH指令触发的。图中显示结构(mds_data)位于一些arch_main代码的前面，如下所示:
rwip_rf 0x0008071c Data 0 rom_symdef.txtmds_data 0x00080768 Data 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｛无符号字符systemId [8];无符号字符manufacturerName [32];无符号字符modelNumber [32]无符号字符serialNumber [32];无符号字符firmwareRevision [32];无符号字符hardwareRevision [32];无符号字符softwareRevision [32];无符号字符pnpId [8];无符号字符continuaMajorVersion;无符号字符continuaMinorVersion;无符号字符numberOfCertifications;无符号短*确实的事情;无符号短regStatus;无符号字符batteryLevel;无符号字符lengthOfTimeData;无符号字符agentCurrentTime [8];无符号长精度;无符号短timeSyncMethod;无符号字符ahdCurrentTime [8];无符号短ahdAccuracy;无符号短ahdTimeSyncMethod;}；
代码中目前只使用结构开头的字符串。但是，我从来没有用到app_init()，所以这是一个有争议的问题。该错误是通过删除char pnpId[8]后的某些元素并保持'strings'集合相同而产生的。导致这种行为的一个例子是
struct mds_data_tag｛无符号字符systemId [8];无符号字符manufacturerName [32];无符号字符modelNumber [32]无符号字符serialNumber [32];无符号字符firmwareRevision [32];无符号字符hardwareRevision [32];无符号字符softwareRevision [32];无符号字符pnpId [8];无符号字符continuaMajorVersion;}；
布莱恩,
我很想知道你能不能找到解决办法。这个星期Dialog的进度似乎有点慢
我还没有找到解决方案，但我发现，每当将数组放在系统关键的东西(比如一个系统堆)之前时，往往会出现问题(硬故障)。我在地图上看过了。我在几个数组案例中都看到过这种情况。一个问题可能是，我正在最高的优化级别上运行，快要耗尽系统空间，以至于必须在优化模式下运行。如果我能让这些数组不在这些堆或系统数据的其他区域旁边，崩溃就会消失。还有另一个我们正在处理的数组，当它大于100字节时，它被放在非保留堆的前面。在这一点上我们得到了这个误差。在100字节时，映射发生了显著的变化，代码开始运行。我们仍然不能弄清楚，因为缓冲区只在一个区域使用，它非常简单。缺点是人们无法控制如何在内存中放置细节(…我也不想这样)。
我们有类似的问题。关于这个问题你有什么进展吗?
嗨Yutaka,
在Cortex-M0处理器上不支持非对齐访问。任何执行未对齐内存访问操作的尝试都会导致硬故障异常。
更多信息可以在下面的链接中找到。
http://infocenter.arm.com/help/index.jsp?topic=/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 Code 0 rom_symdef.txt
地址(0x324CC)在ke_queue_insert中。ke_queue_insert使用哪个参数?我可以将此函数替换为调试吗?
我分析了堆栈内存。地址(0x324CC)不是ke_queue_insert。这个地址可能是ke_task_handler_get的子例程。
栈内存00000000 R000000003 R100007 R2 c6a0003年e350 R300081004 R120003274 d LR000324 cc的电脑0100000020006378 R40003274 d LR ke_task_handler_get0000000000000000 R000000000 R1000817 a8 R400000000 R550000020 R600000004 R7200055 f3 LR patched_gapm_adv_op_sanity000805 e4 R400000000 R550000020 R600032181 LR ke_event_schedule50000000 R400032 dd9 LR rwip_schedule50000000 R420000671 LR main_func000000000000000020006 b1c20005 c01
备注(来自MAP档案)ke_event_schedule 0x0003213d Thumb Code 0 rom_symdef.txtke_task_handler_get 0x000326eb Thumb Code 0 rom_symdef.txtrwip_schedule 0x00032dc9 Thumb Code 0main_func 0x2000058b Thumb Code 592 arch_main.o(.text)
我从你上传的图片中看到，你一直在通过堆栈跟踪函数。当硬件故障或NMI时，SDK将寄存器的最后值存储在两个不同的地址中，分别是0x81800和0x81850，一个用于硬件故障，另一个用于NMI。在那里，您可以找到您的代码遇到硬错误的地址，而无需从堆栈进行任何跟踪。现在，就我所知的硬错误命中，它可以追溯到系统为了安排事件而经常使用的函数。发生这种情况的最可能的原因是数据损坏，可能是一个无效的处理程序指针或类似的东西。此外，如果您能找出这种情况发生时的任何条件，您就可以找到在应用程序中导致这种行为的原因，尝试找出这种错误是否在特定模式中发生，或者在应用程序执行特定操作时发生。
你好布莱恩,
我认为如果你使用C代码，不应该有对齐问题，因为C编译器会做纠正。如果不注意对齐，可能会有多功能，但不会导致内存问题。
的问候!
PY
但是我总是可以通过删除已声明和实现(但未使用)的结构中的元素来导致错误。故障是由STRH指令触发的。图中显示结构(mds_data)位于一些arch_main代码的前面，如下所示:
rwip_rf 0x0008071c Data 0 rom_symdef.txt
mds_data 0x00080768 Data 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
｛
无符号字符systemId [8];
无符号字符manufacturerName [32];
无符号字符modelNumber [32]
无符号字符serialNumber [32];
无符号字符firmwareRevision [32];
无符号字符hardwareRevision [32];
无符号字符softwareRevision [32];
无符号字符pnpId [8];
无符号字符continuaMajorVersion;
无符号字符continuaMinorVersion;
无符号字符numberOfCertifications;
无符号短*确实的事情;
无符号短regStatus;
无符号字符batteryLevel;
无符号字符lengthOfTimeData;
无符号字符agentCurrentTime [8];
无符号长精度;
无符号短timeSyncMethod;
无符号字符ahdCurrentTime [8];
无符号短ahdAccuracy;
无符号短ahdTimeSyncMethod;
}；
代码中目前只使用结构开头的字符串。但是，我从来没有用到app_init()，所以这是一个有争议的问题。该错误是通过删除char pnpId[8]后的某些元素并保持'strings'集合相同而产生的。导致这种行为的一个例子是
struct mds_data_tag
｛
无符号字符systemId [8];
无符号字符manufacturerName [32];
无符号字符modelNumber [32]
无符号字符serialNumber [32];
无符号字符firmwareRevision [32];
无符号字符hardwareRevision [32];
无符号字符softwareRevision [32];
无符号字符pnpId [8];
无符号字符continuaMajorVersion;
}；
布莱恩,
我很想知道你能不能找到解决办法。这个星期Dialog的进度似乎有点慢
我还没有找到解决方案，但我发现，每当将数组放在系统关键的东西(比如一个系统堆)之前时，往往会出现问题(硬故障)。我在地图上看过了。我在几个数组案例中都看到过这种情况。一个问题可能是，我正在最高的优化级别上运行，快要耗尽系统空间，以至于必须在优化模式下运行。如果我能让这些数组不在这些堆或系统数据的其他区域旁边，崩溃就会消失。还有另一个我们正在处理的数组，当它大于100字节时，它被放在非保留堆的前面。在这一点上我们得到了这个误差。在100字节时，映射发生了显著的变化，代码开始运行。我们仍然不能弄清楚，因为缓冲区只在一个区域使用，它非常简单。缺点是人们无法控制如何在内存中放置细节(…我也不想这样)。
我们有类似的问题。
关于这个问题你有什么进展吗?
嗨Yutaka,
在Cortex-M0处理器上不支持非对齐访问。任何执行未对齐内存访问操作的尝试都会导致硬故障异常。
更多信息可以在下面的链接中找到。
http://infocenter.arm.com/help/index.jsp?topic=/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 Code 0 rom_symdef.txt
地址(0x324CC)在ke_queue_insert中。
ke_queue_insert使用哪个参数?
我可以将此函数替换为调试吗?
我分析了堆栈内存。
地址(0x324CC)不是ke_queue_insert。
这个地址可能是ke_task_handler_get的子例程。
栈内存
00000000 R0
00000003 R1
00007 R2 c6a
0003年e350 R3
00081004 R12
0003274 d LR
000324 cc的电脑
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
00032 dd9 LR rwip_schedule
50000000 R4
20000671 LR main_func
00000000
00000000
20006 b1c
20005 c01
备注(来自MAP档案)
ke_event_schedule 0x0003213d Thumb Code 0 rom_symdef.txt
ke_task_handler_get 0x000326eb Thumb Code 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