Thumb Mode Function Address Discrepancies in Keil uVision Debugging

Thumb Mode Function Address Representation in Keil uVision Linker Map

In ARM architectures, particularly when dealing with Thumb mode execution, function addresses often include a Least Significant Bit (LSB) set to 1 to indicate Thumb mode. This is a fundamental aspect of ARM’s Thumb instruction set, which allows for more compact code by using 16-bit instructions instead of the standard 32-bit ARM instructions. However, the representation of these addresses can vary between different toolchains and debugging environments, leading to potential confusion.

In Keil uVision5 with ARMCC v5.06, the linker map file generated during compilation displays function addresses with the LSB set, indicating Thumb mode. For example, if the function main() is located at address 0x540, the linker map will show this address as 0x541. This is consistent with the ARM architecture’s requirement for Thumb mode function pointers. However, this behavior contrasts with GCC, which typically displays the 2-byte aligned address (0x540 in this case) in its linker map.

The discrepancy arises because Keil uVision5 adheres strictly to the ARM architecture’s specification for Thumb mode function pointers, where the LSB must be set to 1 to indicate Thumb mode. This is crucial for the correct execution of Thumb code, as the processor uses this bit to determine the instruction set to use when branching to the function. GCC, on the other hand, may display the aligned address in the linker map, but it still generates the correct Thumb mode address when the function pointer is used in the code.

Debugger Watch Window Address Misalignment in Keil uVision

During debugging in Keil uVision5, another layer of complexity is introduced when observing function addresses in the watch window. When a function pointer is accessed by name in the watch window (e.g., some_var = main), the value assigned to some_var is the 2-byte aligned address (0x540) rather than the Thumb mode address (0x541). This behavior is specific to the Keil uVision debugger and can lead to confusion, especially when comparing the values in the watch window with those in the linker map or the actual function pointers used in the code.

The reason for this discrepancy lies in how the Keil uVision debugger interprets function names in the watch window. The debugger appears to strip the LSB when displaying the address, even though the actual function pointer used in the code will have the LSB set. This is likely a design choice to simplify the display of addresses in the watch window, but it can be misleading if the user is not aware of this behavior.

Resolving Thumb Mode Address Discrepancies in Keil uVision

To address the discrepancies between the linker map, function pointers, and the debugger watch window in Keil uVision5, several steps can be taken to ensure consistency and clarity:

1. Understanding the Linker Map Representation: Recognize that the linker map in Keil uVision5 will display Thumb mode function addresses with the LSB set. This is the correct representation according to the ARM architecture, and it should be expected when working with Thumb code. When comparing the linker map with other toolchains like GCC, be aware that GCC may display the aligned address, but the actual function pointer will still have the LSB set when used in the code.

2. Debugger Watch Window Interpretation: When using the Keil uVision debugger, be aware that the watch window will display the 2-byte aligned address when a function name is used. This is a debugger-specific behavior and does not reflect the actual function pointer value used in the code. To verify the correct Thumb mode address, use the function pointer directly in the code and observe its value in the watch window.

3. Verifying Function Pointers in Code: To ensure that the correct Thumb mode address is being used, explicitly cast the function pointer to a uint32_t and observe its value. For example:

   uint32_t thumb_address = (uint32_t)main;
   

   This will show the correct Thumb mode address (0x541) in the watch window, confirming that the function pointer is correctly set.

4. Compiler and Linker Settings: While there is no direct setting in Keil uVision5 to change the address display in the linker map, understanding the behavior and ensuring that the correct Thumb mode addresses are used in the code will prevent any issues. If necessary, consult the ARMCC documentation for any advanced settings that might affect address representation.

5. Cross-Toolchain Consistency: When working with multiple toolchains (e.g., Keil uVision and GCC), ensure that the team is aware of the differences in address representation. Documenting these differences and establishing a consistent approach to handling Thumb mode addresses can prevent confusion and errors in the development process.

By following these steps, developers can effectively manage the representation of Thumb mode function addresses in Keil uVision5, ensuring that the correct addresses are used in both the code and the debugging process. This understanding is crucial for maintaining the integrity of the firmware and avoiding subtle bugs that can arise from incorrect function pointer usage.

Detailed Analysis of Thumb Mode Address Handling

To further understand the nuances of Thumb mode address handling in Keil uVision5, it is important to delve into the specifics of how the ARM architecture and the Keil toolchain interact. The ARM architecture defines that Thumb mode function pointers must have the LSB set to 1. This is a hardware requirement that ensures the processor correctly interprets the instruction set when branching to the function.

In the context of the Keil uVision5 toolchain, the ARMCC compiler and linker work together to generate the correct Thumb mode addresses. The linker map file, which is generated during the linking phase of the build process, reflects these addresses with the LSB set. This is a direct result of the linker’s adherence to the ARM architecture’s specifications.

However, the Keil uVision debugger, which is responsible for displaying and interacting with the code during the debugging process, may not always reflect these addresses in the same way. The watch window, in particular, appears to strip the LSB when displaying function addresses, leading to the observed discrepancy. This behavior is likely intended to simplify the display of addresses, but it can be misleading if not properly understood.

To further complicate matters, the behavior of the debugger may vary depending on the specific version of Keil uVision and the ARMCC compiler being used. It is therefore important to consult the documentation for the specific versions of the tools being used and to test the behavior in the actual development environment.

Practical Implications of Thumb Mode Address Discrepancies

The discrepancies in Thumb mode address representation between the linker map, function pointers, and the debugger watch window can have practical implications for firmware development. One of the most significant implications is the potential for confusion when debugging code that relies on function pointers. If a developer is not aware of the debugger’s behavior, they may incorrectly assume that the function pointer is not being set correctly, leading to unnecessary debugging efforts.

Additionally, when working with multiple toolchains, the differences in address representation can lead to inconsistencies in the development process. For example, if a team is using both Keil uVision and GCC, they may encounter different representations of the same function address, leading to potential misunderstandings and errors.

To mitigate these issues, it is important to establish clear guidelines for handling Thumb mode addresses in the development process. This includes documenting the behavior of the tools being used, ensuring that all team members are aware of these behaviors, and establishing consistent practices for verifying function pointers in the code.

Best Practices for Handling Thumb Mode Addresses

To ensure consistent and correct handling of Thumb mode addresses in Keil uVision5, the following best practices are recommended:

1. Document Toolchain Behavior: Clearly document the behavior of the Keil uVision5 toolchain, including the representation of Thumb mode addresses in the linker map and the debugger watch window. This documentation should be shared with all team members to ensure a common understanding.

2. Verify Function Pointers in Code: Always verify the correct Thumb mode address by explicitly casting the function pointer to a uint32_t and observing its value in the watch window. This ensures that the correct address is being used, regardless of how it is displayed in the debugger.

3. Consistent Cross-Toolchain Practices: When working with multiple toolchains, establish consistent practices for handling Thumb mode addresses. This includes using the same methods for verifying function pointers and ensuring that all team members are aware of the differences in address representation.

4. Regular Testing and Validation: Regularly test and validate the behavior of function pointers in the development environment. This includes testing with different versions of the toolchain and ensuring that the correct Thumb mode addresses are used in all cases.

5. Consult Toolchain Documentation: Always consult the documentation for the specific versions of the Keil uVision5 toolchain being used. This includes the ARMCC compiler and linker documentation, as well as the Keil uVision debugger documentation.

By following these best practices, developers can ensure that Thumb mode addresses are handled correctly and consistently in Keil uVision5, reducing the potential for confusion and errors in the development process.

Conclusion

Understanding the representation of Thumb mode function addresses in Keil uVision5 is crucial for effective firmware development on ARM architectures. The discrepancies between the linker map, function pointers, and the debugger watch window can lead to confusion, but with a clear understanding of the toolchain’s behavior and the implementation of best practices, these issues can be effectively managed.

By documenting toolchain behavior, verifying function pointers in code, establishing consistent cross-toolchain practices, regularly testing and validating, and consulting toolchain documentation, developers can ensure that Thumb mode addresses are handled correctly and consistently. This understanding is essential for maintaining the integrity of the firmware and avoiding subtle bugs that can arise from incorrect function pointer usage.