HARDFAULTS从阅读/写作到未对齐的地址？

但我可以一直导致the error by removing an element in a structure that is deleclared and implemented (but not used). The fault is triggered by the STRH instruction. The map shows that the structure (mds_data) is placed just before some arch_main code as shown below:

rwip_rf 0x0008071c Data 0 rom_symdef.txt ABSOLUTE
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)

Playing with unused elements of that structure will trigger the error on the STRH instruction. Interestingly, none of the code I have access to (except arch_main) is executed. I can place a break point in the arch_main while loop and step through that loop but the place in the application code that normally gets hot first (app_init() in app.c) never gets hit. It can take up to 10 seconds or so before the hard fault appears.

是这里
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];
unsigned char continuaMajorVersion;
unsigned char continuaMinorVersion;
unsigned char numberofcertications;
无符号短*证书;
unsigned short regStatus;
未签名的Char Batteryvel;
无符号char longeoftimedata;
unsigned char agentcurrentime [8];
毫无符号的长度;
unsigned short timeSyncMethod;
unsigned char ahdCurrentTime[8];
unsigned short ahdAccuracy;
unsigned short ahdtimesyncmethod;
};

Only the strings at the start of the struct are currently used in code. However, I never get to app_init() so that is a moot point. The error is generated by removing certain elements after char pnpId[8] and keeping the set of 'strings' the same. An example that caused the behavior is

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];
unsigned char continuaMajorVersion;
};

I have not found solution but I have found that there tends to be trouble (hard faults) whenever an array is placed before something system-critical (like one of the system heaps). I have viewed this in the map. I have seen this rather consistently for several array cases. A problem may be that I am running at the highest optimization level and am on the verge of running out of system space to the point that I have to run in the optimized modes. If I can play in such a way that these arrays are not next to one of these heaps or other areas of system data, the crash goes away. There is another array that we were working with that was placed right before the non-retention heap when it was larger than 100 bytes. At that point we got that error. At 100 bytes the map shifted significantly and the code ran. We still can't figure it out as the buffer is used only in one area and it's pretty simple. The down side is one has no control over how things are placed in memory at that detail (...and I wouldn't want to have to either).