Scott Trappe

Cause of Access Error Exception with ColdFire 52230

Discussion created by Scott Trappe on May 8, 2012
Latest reply on May 9, 2012 by Mark Butcher

Hi,

      My project uses an MCF52230. I'm getting an Access Error Exception (vector = 2), I can't understand why this exception is being generated. Here is the ColdWarrior disassembly of the relevant code:

 

CALLING FUNCTION:

...

;  347:       memset(buf, 0, size);

0x0000002A  0x2F470008               move.l   d7,8(a7)
0x0000002E  0x42AF0004               clr.l    4(a7)
0x00000032  0x2E8C                   move.l   a4,(a7)
0x00000034  0x4EB900000000           jsr      _memset

 

CALLED FUNCTION:
;  409: void *memset (void *s, int c, unsigned n)

0x00000000                    _memset:
0x00000000  0x4E560000               link     a6,#0
0x00000004  0x2F0C                   move.l   a4,-(a7)
0x00000006  0x286E0008               movea.l  8(a6),a4
0x0000000A  0x242E000C               move.l   12(a6),d2
0x0000000E  0x222E0010               move.l   16(a6),d1      <<<==== Access Exception Reported Here

;  412:     unsigned char *sp = (unsigned char *)s;
0x00000012  0x204C                   movea.l  a4,a0

 

So what's happening is that the calling function (line 347) pushes three arguments on the stack and then does a JSR to memset(). memset immediately loads all three parameters from the stack into registers. The Access Error Exception is occuring on the "move.l 16(a6),d1", which is loading the third parameter ("n") into register D1. The fault status indicates an Operand Read access error, but I don't understand why. I set a breakpoint at the beginning of the exception handler and confirmed that the value in A6 at the time of the exception is valid; when I look at the stack all the memory locations are exactly what I would expect them to be; the registers A4 and D2 have been loaded with the appropriate arguments from the stack, while D1 has not (makes sense, since the exception is being reported on this instruction).

 

Memset is called dozens of times before this particular instance fails, many times from the same caller as in this instance. Worse, almost any change to the program will cause the exception to not happen. For example, I inserted a statement incrementing an otherwise unused global variable at the beginning of memset(); this compiled to an "addq.l #1,_globalvar" being generated at offset 0x6 (just before the movea.l). But with this change, I no longer get the access exception. I can put the assigment in another function entirely and that also has the same effect!  So somehow just changing the code layout in FLASH affects the error.

 

I read the ColdFire RM and the 52235RM carefully, but neither provide specifics on what conditions result in an Access Error Exception being generated, and nothing that directly relates to what is happening in this code. So I suspect the actual bug has nothing to do with memset(); but somehow it is manifesting in this error showing up here. This is the most "tangible", reproducible lead I have on the problem. Any suggestions as to what could cause the processor to generate this exception, or what else I should be looking for?

 

Thanks,

      Scott

Outcomes