AVR32 exception: Bus Data Error

Recently, I am facing a - to me - strange behavior in my embedded software.

What I got: Running a 32 bit AVR32 controller, starting the program from an external SDRAM, as the file size is too big to start it directly from the micro-controller flash. Due to the physical memory map, the memory areas are split between:

stack (start at 0x1000, length of 0xF000) ( < 0x1000 is protected by the MPU)

EBI SDRAM (start at 0xD0000000, length of 0x00400000).

---

What happens: Unfortunately I got an exception, which is not reproducible. Looking at my given stack trace, the following event irregular occurs:

Name: Bus error data fetch - Event source: Data bus - Stored Return Address: First non-completed instruction

Additionally, the stack pointer has a valid value, whereas the address where the exception occurs (last entry point for fetching instructions), points into the memory nirvana (e.g. 0x496e6372, something around 0x5..., 0x6....). I guess, this has to be the "First non-completed instruction", the manual is talking about. However, the line in my source code is always the same: accessing a member function from a data array via pointer.

      if(mSomeArray[i])
      {
         mSomeArray[i]->someFunction(); <-- Crash
      }

The thing is: adding or deleting other source code makes the event disappear and return again.

---

What I thought about: Something is corrupting my memory (mapping). What kinds of errors are possible for this?

• A buffer overflow?
• The SDRAM controller could be turned off, so it loses some data. That is not impossible, but rather improbably
• The stack is big enough, I already checked this with a watermark
• The Data Bus Rate and AVR clock are set correctly

---

How to solve this: More assert? Unfortunately I cannot debug this with AVRStudio. Anyone a hint or idea? Or am I missing something obvious?

---

Edit:

Mentioned approaches from users:

• Check for addresses of function pointer and array entries
• Overwrite of stack array
• Not properly written interrupts
• Not initialized pointers
• Check for array access via i at crash case
• use exception handler address for illegal memory access
• use snprintf instead of sprintf

---

Late appendix to the thread: the issue was a wrong array access (wrong index was set) in an old software module, that had nothing to do with my modules. I found this by accident, it was a curiosity that it didn't appear earlier and it took me quite a while to find the line of code. I mark the only given answer as correct solution.

Thank you all for your input.

Take care (of your software ;))

Here are some ideas:

1. Check 'i' to make sure it is within the array bounds.
2. Check the address of the function pointer that is about to be called. It should have an address within the SDRAM.
3. See if the chip has an exception handler address it will jump to when it accesses illegal memory. Once you are there, output some debug data
4. If your debugger allows, set a breakpoint on someFunction() when it is written. This would catch some other function when it overwrites the function pointer.