Issues with recording #pragma pack ()

In the Cortex M0 platform to do development, encountered a tangled two or three days of the problem.
After the code has added PWM motor control, continue to do the USB composite device. In a good USB composite device, found that the original PWM motor control does not work, the first comparison of the module register settings, exactly the same, and then compare the code, in addition to the USB part,
No difference, then try to compare the bin file and the map file, and find the biggest difference between the two
One called the __EABI_UREAD4 function in UREAD.O and the __eabi_uwrite4 function of uwrite4.o;
And the other one does not call these two functions.
Finally, by careful comparison, the problem is locked in the following definition:
#pragma pack (1)
#pragma pack ()
With this definition, the code is fine, and without this definition, the code is in trouble.
After viewing it yourself, there is a definition of #pragma pack (1) in the FileSystem.h header file, and then there is a problem.
A description of the #pragma pack (n) found on the ARM official web site is as follows:
#pragma pack (n)
This pragma aligns members of a structure to the minimum of N and their natural alignment. Packed objects is read and written using unaligned accesses.
Show/hidesyntax
#pragma pack (n)
Where:
N
Is the alignment in bytes, valid alignment values being 1, 2, 4 and 8.
Show/hidedefault
The default is #pragma pack (8).
Show/hideexample
This example demonstrates what pack (2) Aligns integer variable B to a 2-byte boundary.
typedef struct
{
Char A;
int b;
S


#pragma pack (2)


typedef struct
{
Char A;
int b;
} SP;


S var = {0x11, 0x44444444};
SP Pvar = {0x11, 0x44444444};
The layout of S is as shown in Figure 1, while the layout of the SP are as shown in Figure 2. In Figure 2, x denotes one byte of padding.
Figure 1. Nonpacked structure S


Figure 2. Packed structure SP





As a result, we can see how packet is compressed and the effect on byte alignment.


The following information is found on another arm document:
These functions read and write 4-byte and 8-byte values at arbitrarily aligned addresses. An unaligned 2-byte
Value can always is read or written more efficiently using inline code.
int __aeabi_uread4 (void *address);
int __aeabi_uwrite4 (int value, void *address);


Presumably after the #pragma pack (1) in FileSystem.h, there was a problem with alignment, resulting in an error in data access.
If you remove the definition, you will be back to normal with 4-byte or 8-byte alignment.