Shulou(Shulou.com)06/01 Report--

What this article shares with you is about the process of solving ARM unaligned operation anomalies. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

A very strange exception occurred while testing the MF firmware, with the following code:

CLR_DBG_Commands::Monitor_EraseMemory* cmd = (CLR_DBG_Commands::Monitor_EraseMemory*) msg- > masked payload; debug_printf ("EraseMemory addr=0xx len=%d\ r\ n", cmd- > m_address, cmd- > m_length)

When you specify the second line of code, you skip to the exception handler and exception No. 6 occurs (usage exception Usage Fault)

I am still a stranger to ARM, and I don't know how this problem can happen.

Before today, this line of code has been executed countless times without error, and the code of this function or related functions has not been modified recently, but a lot of other code has been modified yesterday.

1. Baidu looks for information.

The key point is the usage exception Usage Fault, which is used as the keyword search. Some data (http://www.docin.com/p-633872264.html) pointed out that usage exceptions include: execution of undefined instructions, misaligned operations, and division of zeros.

The front and back are obviously impossible, but the misalignment in the middle caught my attention. Because when you read the MFPK code, you see a lot of alignment design.

2Debug with Keil

Debug these two lines of code in Keil

0x080071DA 6A74 LDR R4, [R6 0x080072280x080071DE E9D41200 LDRD 0x080072280x080071DE E9D41200 LDRD 0x24] 1350: debug_printf ("EraseMemory addr=0xx len=%d\ r\ n", cmd- > m_address, cmd- > m_length); 1351: 0x080071DC A012 ADR R0, {pc} + 4; @ 0x080072280x080071DE E9D41200 LDRD R1Curr2, [R4JEO] 0x080071E2 F001FD93 BL.W debug_printf (0x08008D0C)

The line that throws the exception is 0x080071DE. The code is LDRD R1, R2, [R4 record0], to the effect that the data starting with R4, offset by # 0 is loaded into R1, and the next word is loaded into R2.

As you can see from the register, R4 is now 0x200006D2, which is half-word alignment rather than word alignment.

Strange, why does MDK compile a half-word alignment?

Go back to the msg- > m_payload of the first line of code, which is the key. Because it is 0x200006D2, if R4 does not have word alignment, then it must have something to do with this msg- > m_payload.

Let's see where msg- > m_payload is allocated!

3, searching for roots

You can see from the code that msg- > m_payload comes from msg- > m_payload = pThis- > m_receptionBuffer

And m_receptionBuffer 's statement

COM_HANDLE masks port; UINT8 m_receptionBuffer [2048]; UINT32 masks; UINT32 masks lastPacketSequence; WP_Controller m_controller

When you get here, you'll understand!

Because I changed typedef INT32 COM_HANDLE; to typedef INT16 COM_HANDLE yesterday.

The above is what the abnormal resolution process of ARM misalignment operation is like, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.