I am trying to chase down an occasional (once or twice a day) crash on a
PIC24H project. I'm using the AddressError function (below) to see where
the issue is.

  void (*getErrLoc(void))(void);  // Get Address Error Loc
  void (*errLoc)(void);           // Function Pointer
  void __attribute__((interrupt, no_auto_psv)) AddressError(void){
  // Trap address error
        errLoc=3DgetErrLoc();
        INTCON1bits.ADDRERR =3D 0;        //Clear the trap flag
//        while (1);
        Nop();
  }

I set a breakpoint on the Nop() so I can use the watch window to look at
errLoc. The watch window shows errLoc as 16 bit while the program memory
address space uses 23 bit addresses (including 0 in lsb since all
instructions are on even addresses). The program counter is 23 bits wide.
So, if errLoc is indeed the instruction that caused the address error, it
seems like it should be 24 bits wide. The watch window shows it as 16 bits
wide and will not let me change it. So, should it be 24 bits wide?

The watch window shows errLoc as being at address 0x3a74 and containing
0xa642. Looking in RAM at 0x3a74, I see 0xa642. In the next location
(0x3a76) I see 0x3a78.

Doing a search of the disassembly listing for 0xa642, I find one instance
at 0x1a642 as shown below:

1754:                  ENC_CS_IO =3D 0;
 1A642  A962E8     bclr.b 0x02e8,#3

This is in ReadMacReg() in the Ethernet code.

In HardwareProfile.h, I have the following:

	#define ENC_CS_IO			  (LATGbits.LATG3)

So, the chip select is being driven by LATG. Adding LATG to the watch
window, I see its address is 0x02e8, so the disassembly above looks ok.

I think a common cause of crashes is stack/heap collisions. To check for
that, I have some code I add to a lot of projects. It is shown below.

void FillHeapToStack(){
// For debug, fill the RAM area from the heap to the stack pointer. Look
at this area of ram later
// to see how much was used.
UINT32 count;
UINT32 *pHeap, *pWrite, FreeSpace;
  pHeap=3Dmalloc(4);		// allocate 4 bytes
  pWrite=3DpHeap;
  StackStart=3D(UINT32)&count;  // Use address of a local as sp value. save
these as globals
  StackStart-=3D16;             // subtract this to match what cpu register=
s
window shows
  HeapStart=3D(UINT32)pHeap;
  FreeSpace=3DStackStart-HeapStart;
  sprintf(StringBuf,"HP=3D0x%lx, SP=3D0x%lx,
FreeSpace=3D0x%lx",HeapStart,StackStart,FreeSpace);
  WriteLog(StringBuf);
  count=3DStackStart-HeapStart;		// how many bytes between the stack pointe=
r
and the heap
  count=3Dcount/4;		// count is now how many words
  while(count--){
    *pWrite++=3D0x41414141;	// put a readily identified number there
  }
  free(pHeap);
}

This was adapted from my PIC32 code, but I think it's about right for
PIC24H. Anyway, after the latest crash (halt on breakpoint in
AddressError), I looked through RAM for my 0x41 block to see if it had
been overwritten by the application. I still have a 0x41 block from 0x3e5a
through 0x3fb8, so it appears the heap and stack did not collide. Looking
back through the log, I see

HP=3D0x3e5a, SP=3D0x3fbc, FreeSpace=3D0x162

Based on this, it looks like only 4 more byes of stack were used!

So, ideas on how to solve this?

THANKS!

Harold




--=20
FCC Rules Updated Daily at http://www.hallikainen.com
Not sent from an iPhone.
--=20
http://www.piclist.com/techref/piclist PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist
.