A strange problem when compiling a KEIL project

wjroy11

A strange problem when compiling a KEIL project [Copy link]

 

A KEIL project of mine compiled and ran normally; I adjusted the order of files loaded in the project window, compiled and ran, and went directly to Hardfault. It stands to reason that the order of file compilation will not affect the final generated target file, and there should not be different running results. I don't understand where the problem lies. By comparison, it is found that the map files generated after compilation in the two cases are different. Everything else is the same. I don't know if anyone has encountered this problem. Please advise. The cause of the problem was found, which is a byte alignment problem. Two relatively large arrays are defined in the project, as follows: __attribute__((aligned(4))) uint8_t MMU_US_Data_Memory[US_CAPACITY]; uint8_t MMU_SD_Data_Memory[UD_CAPACITY]; When processing the contents of these two arrays, memcpy is used. During debugging, it is found that Hardfault often occurs at the memcpy location. During debugging, it is found that the first addresses of the above two arrays, MMU_US_Data_Memory and MMU_SD_Data_Memory, are not 4-byte aligned, so the two array definitions are changed to: __attribute__((aligned(4))) uint8_t US_Data_Memory[US_CAPACITY]; __attribute__((aligned(4))) uint8_t SD_Data_Memory[UD_CAPACITY]; Breakpoints are set at memcpy, and the first addresses of the two arrays are 4-byte aligned. The program continues to run without Hardfault. Then it is basically determined that the Hardfault is caused by the byte alignment problem. There are a few things I don't understand. Please ask: 1. Why is the array not byte aligned if __attribute__((aligned(4))) is not added? The array size I applied for is 16K. Is it related to the fact that the space I applied for is too large? 2. After the array is byte aligned, I tried to do this test: memcpy (US_Data_Memory+1, arrytest, 100); That is to say, the offset 1 is added to the byte-aligned US_Data_Memory array address, so the address where the data is copied in is definitely not byte aligned. At this time, the code does not report an error. Why? 3. In the debugging state, looking at the assembly code in the Disassembly window, the memcpy function corresponds to: __aeabi_memcpy(). I checked it online and found that this means a copy function that does not require byte alignment. If 4-byte alignment is required, the corresponding function is __aeabi_memcpy4(), but I don't see this function in the assembly window. I don't quite understand. 4. Why is it that after swapping the order of the two files, the first addresses of the two arrays are divisible by 4? Does the order of the compiled files affect the address of the array application? Please help explain the above four questions, thank you.

zhuzd

Set more breakpoints and debug. See where the program goes wrong. Find the problem.

wenyangzeng

When the order is different, sometimes the hardware is not initialized and enters a certain interrupt first, which will cause a crash.

常见泽1

Let's take a look at some specific examples.

wjroy11

wenyangzeng published on 2019-1-23 17:13 When the order is different, sometimes the hardware is not initialized and enters a certain interrupt first, of course it crashes.

My understanding is that the order is different, just when compiling, but the final linked hex or bin file should be the same. According to what you said, the hardware is not initialized. This statement is not appropriate. For example, when writing code, no one will deliberately put the initialization file at the top.

wjroy11

Common Ze 1 posted on 2019-1-23 17:16 Let's take a look at the specific example

The project is too big and not suitable for posting, so I just describe the problem and see if you have any ideas to provide

常见泽1

wjroy11 posted on 2019-1-23 17:22 The project is too large and not suitable for posting, so I will just describe the problem and see if you have any ideas to provide

Is it just to adjust the order of the C files in the project?

wjroy11

Common Ze 1 posted on 2019-1-23 17:25 Is it to change the order of the C files in the project?

Yes, just swap the order of the two files in the project, and the compilation can pass, but when running, the swapped project will hard fault. I use c++, and I swapped two cpp files.

wjroy11

I found a similar situation in another forum, which is very similar to what I encountered. I don't know if it is the same problem. I will study it. Link this http://bbs.21ic.com/icview-1197474-1-1.html

ddllxxrr

wenyangzeng posted on 2019-1-23 17:13 When the order is different, sometimes the hardware is not initialized and enters a certain interrupt first, of course, the computer crashes.

I strongly agree

tiankai001

wjroy11 posted on 2019-1-23 17:21 My understanding is that the order is different, just when compiling, but the final linked hex or bin file should be the same. According to what you said...

I think it has nothing to do with the order of files, because when compiling, the compiler will automatically compile each function according to the program flow. The main reason may be that there is a problem with a function, and when running before, this function was not run, so the problem was not exposed.

freebsder

Are there any global things in the two files A and B that are the same? Does the problem occur only when the two files A and B are exchanged, or will the problem occur when any two files are exchanged?

wjroy11

freebsder posted on 2019-1-24 00:10 Are there any global things in the two files AB that are the same? Does the problem occur only when the two files AB are exchanged, or will the problem occur when any two files are exchanged?

The problem only occurs when the two files AB are exchanged, and other files are not affected

wjroy11

tiankai001 posted on 2019-1-23 22:34 I think it has nothing to do with the order of the files, because when compiling, the compiler will automatically compile each function according to the program flow. The main reason may be that there is a...

The project has been used for a long time and no major bugs have been found, so it seems that there should be no situation where a function cannot be run.

freebsder

wjroy11 posted on 2019-1-24 09:11 There is only a problem when exchanging files AB, and other files are not affected

If possible, please send these two files for us to see.

wsmysyn

For C++, it may involve the execution order of constructors. . The execution order of constructors is different, and the hardware initialization will be in order. . For example, when initializing global objects, the order of constructor calls may be different. . You can initialize a serial port first to track the constructor calls of each object, and then you will know whether there is any difference in the order. .

wsmysyn

Simply talking about the phenomenon, it is not necessarily easy to locate it immediately. It is related to the specific project and code. I cannot provide it. You can only have an idea. You can check it out yourself. It is very likely related to the execution order of the constructor. You need to judge whether the objects used in the two files need to be kept in a certain order.

tiankai001

wsmysyn posted on 2019-1-24 09:33 Simply talking about the phenomenon may not be able to locate it all at once. It is related to the specific project and code. If you can't provide it, everyone will only have one idea. You can do it yourself...

I think your analysis is very reasonable

shipeng

Have you cleaned it and then compiled it?

wsmysyn

tiankai001 posted on 2019-1-24 09:40 I think your analysis is very reasonable

I encountered a similar problem to the one he mentioned before. When I first saw it, I felt that C language might not work, and thought it should be C++. He did say C++ I did it once before, the class code remained unchanged, but the location of object initialization was different, which caused problems.