如何解决读取物理地址代码中的MISRA 2004 11.3违规问题？

Alright, let's break down why your code is triggering this violation and how to fix it properly: MISRA 2004 Rule 11.3 strictly prohibits converting integer types directly to pointer types—which is exactly what you’re doing when casting 0x00003DD2 (a raw integer address) to tm_uint8*. MISRA enforces this to avoid undefined behavior and ensure type safety, but embedded systems need to access fixed hardware addresses, so we have compliant workarounds.

Here are the most practical, MISRA-friendly solutions:

1. Use Compiler-Specific Memory Mapping Extensions #

Most embedded compilers (Keil, IAR, GCC with extensions) offer built-in syntax to map variables directly to physical addresses without manual pointer casts. This is the cleanest approach since it lets the compiler handle address mapping safely.

For example, using the __at keyword (common in 8/16-bit embedded compilers):

// Map variables directly to your target hardware addresses
#define REG_3DD2 (*((tm_uint8 __at 0x00003DD2)))
#define REG_3DD3 (*((tm_uint8 __at 0x00003DD3)))
#define REG_3DD4 (*((tm_uint8 __at 0x00003DD4)))

tm_uint8 read(tm_uint8* data) {
    data[0] = REG_3DD2;
    data[1] = REG_3DD3;
    data[2] = REG_3DD4;
    return 0; // Add a valid return value—your function declared tm_uint8 but had no return
}

If you’re using GCC, you can use the section attribute (pair this with a linker script that reserves the target addresses):

// Declare variables in a custom section
tm_uint8 reg_3dd2 __attribute__((section(".hw_regs"))) = 0;
tm_uint8 reg_3dd3 __attribute__((section(".hw_regs"))) = 0;
tm_uint8 reg_3dd4 __attribute__((section(".hw_regs"))) = 0;

// Then in your linker script, map .hw_regs to start at 0x00003DD2

2. Use const volatile Pointers with a Documented Deviation #

If your compiler doesn’t support address mapping extensions, define const volatile pointers to the hardware addresses. The volatile is non-negotiable here—it prevents the compiler from optimizing away critical register reads (hardware values can change outside your code’s control).

// Define pointers to the hardware addresses
const volatile tm_uint8 * const REG_3DD2 = (const volatile tm_uint8 *)0x00003DD2;
const volatile tm_uint8 * const REG_3DD3 = (const volatile tm_uint8 *)0x00003DD3;
const volatile tm_uint8 * const REG_3DD4 = (const volatile tm_uint8 *)0x00003DD4;

tm_uint8 read(tm_uint8* data) {
    data[0] = *REG_3DD2;
    data[1] = *REG_3DD3;
    data[2] = *REG_3DD4;
    return 0; // Fix the missing return value
}

Since this still uses an integer-to-pointer cast, you’ll need to request a deviation from your MISRA compliance team. This is fully acceptable in embedded systems—just document that this cast is necessary to access fixed hardware registers, which is a legitimate exception to Rule 11.3.

3. Use uintptr_t for Explicit, Type-Safe Casting #

For an extra layer of compliance, use uintptr_t (from <stdint.h>) as an intermediate type. This is a standard integer type designed specifically to hold pointer values, making the cast more explicit and MISRA-friendly:

#include <stdint.h>

const volatile tm_uint8 * const REG_3DD2 = (const volatile tm_uint8 *)(uintptr_t)0x00003DD2;
const volatile tm_uint8 * const REG_3DD3 = (const volatile tm_uint8 *)(uintptr_t)0x00003DD3;
const volatile tm_uint8 * const REG_3DD4 = (const volatile tm_uint8 *)(uintptr_t)0x00003DD4;

tm_uint8 read(tm_uint8* data) {
    data[0] = *REG_3DD2;
    data[1] = *REG_3DD3;
    data[2] = *REG_3DD4;
    return 0;
}

Quick Critical Notes: #

• Fix the Return Value: Your original function declares a return type of tm_uint8 but has no return statement—this will trigger a compile warning, so add a valid return value (like 0 for success, or an error code if applicable).
• Never Skip volatile: Hardware registers can change value independently of your code, so volatile forces the compiler to read the register every time, instead of caching a stale value.

内容的提问来源于stack exchange，提问作者Ankit Shah