Leon3 EDAC启用后程序崩溃求助：IU异常(tt=0x2B，数据存储错误)

Hey Lorenzo, let's break down what's happening here and figure out how to fix that post-initialization crash.

First, let's parse the GRMON error you got:

IU exception (tt = 0x2B, data store error)
0x40009acc: 81c3e008 retl <memmove+484>

That tt=0x2B is a Data Store Error, triggered specifically when the retl instruction tries to read the return address from the stack. This tells us the crash is directly tied to memory access after enabling EDAC read checks—most likely, the stack memory (where your initialization function's return address is stored) has invalid ECC parity that's being flagged by the EDAC logic you just turned on.

Here are the most likely causes and fixes to try:

1. Uninitialized ECC on Stack Memory #

When you enable EDAC read checking (MCFG3_R_bit_set), the SDRAM controller starts validating ECC parity for every read. If the stack region (where your initialization function's return address is stored) was written to before EDAC was enabled, it doesn't have valid ECC parity bits. When retl tries to read that address, the controller throws an error.

Fixes: #

• Pre-initialize the stack region with valid ECC before enabling EDAC read checks. You can do this either:
  • Via GRMON before running your program: Use the fill command to write to the stack address range (check your linker script for the stack start/end)
  • In your code, right before setting MCFG3_R_bit_set, add a loop that writes to the entire stack region (even just writing 0s will generate valid ECC)
• Verify your linker script confirms the stack is allocated in the SDRAM region covered by EDAC (if it's in SRAM without EDAC, this wouldn't be the issue, but your MCFG3_R_bit_set enables EDAC for SDRAM/SRAM, so it's still possible)

2. Incorrect Register Configuration Order #

Your current setup order is MCFG1 → MCFG2 → MCFG3, but the Leon3 SDRAM controller may require a specific sequence to avoid race conditions:

1. First enable I/O memory access (MCFG1_IE_bit_set)
2. Enable SDRAM controller (MCFG2_DE_bit_set) and RMW cycles
3. Wait for the SDRAM controller to stabilize (maybe add a small delay loop)
4. Finally enable EDAC read checks (MCFG3_R_bit_set)

If you enable EDAC checks before the SDRAM controller is fully ready, it might flag valid memory accesses as errors prematurely.

Fix: #

Adjust your initialization code to add a delay after setting MCFG2:

edac->MCFG1 = edac->MCFG1 | MCFG1_IE_bit_set;
edac->MCFG2 = edac->MCFG2 | MCFG2_RMW_bit_set | MCFG2_DE_bit_set;

// Add a short delay to let SDRAM controller stabilize
for (volatile int i = 0; i < 1000; i++);

edac->MCFG3 = edac->MCFG3 | MCFG3_R_bit_set;

3. Missing EDAC Error Interrupt Handler #

When an EDAC error is detected, the Leon3 will trigger an interrupt. If your system doesn't have an interrupt service routine (ISR) registered for this error, the CPU will fall into an unhandled trap and crash.

Fixes: #

• Add a minimal EDAC error ISR to your code. Even a simple handler that logs the error will prevent the crash:

  void edac_error_isr() {
      // Read EDAC status registers to clear the error
      volatile uint32_t status = edac->SDRSTAT;
      // Optionally print status via GRMON (if your debug UART is set up)
      printf("EDAC error detected: 0x%08X\n", status);
  }
  

• Update your interrupt vector table to map the EDAC interrupt number (check your GR-UT699/Leon3 manual for the correct vector) to this ISR.
• Use GRMON's show interrupts command after the crash to check if an EDAC interrupt was pending.

4. Test to Isolate the Crash Point #

To confirm the crash is tied to returning from the initialization function, modify your code to avoid returning immediately:

int edac_init() {
    // Your existing register setup code
    edac->MCFG1 = edac->MCFG1 | MCFG1_IE_bit_set;
    edac->MCFG2 = edac->MCFG2 | MCFG2_RMW_bit_set | MCFG2_DE_bit_set;
    edac->MCFG3 = edac->MCFG3 | MCFG3_R_bit_set;

    // Try printing here instead of returning
    printf("EDAC initialized successfully\n");
    while(1); // Halt to avoid returning
    return 0;
}

If this code runs and prints the message, the issue is definitely the stack's invalid ECC when returning. If it still crashes, the error is happening immediately after enabling EDAC, pointing to a problem with the SDRAM controller configuration itself.

Start with the stack ECC initialization and register order fix—those are the most common culprits in this scenario. Let me know if you need help digging deeper into any of these steps!

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