More Problems with 5.0

[JimKueneman]

I have a large program using the 30F4013 on a custom CCA. I have had some problems with 4.8 and address traps (see the posts here over the last few months). I found a problem with parameter passing (again in a thread here) that was to be fixed in 5.0. I compiled my program in 5.0 and now it constantly throws traps. I show a splash screen and it keeps showing the start-up splash screen over and over. If I add code to the traps and add an infinite loop then it hangs proving that it is throwing a trap (without the loop an unhandled trap will reset program execution to $0000). Now for the difficult part. If I compile with ICD debugging enabled to try to understand what is happening the damn thing work perfectly....

How can I figure this out? I can't use 5.0 at all.....

Jim

[JimKueneman]

Figured it out buy comparing the listing files. The biggest difference was in the SPI_GCLD code so I commented out my Splash Image Code. Guess what. No more Address Traps. I will enter a ticket but maybe Janni or one of the other sharp coders here can see the problem. Here is the listing files for a much stripped down version of my code:

http://www.mustangpeak.net/dsPIC_mP_SPI ... ge_Bug.zip

One is the new version 5.0 and the other is from version 4.8 Beta.

The main thing to notice is there have been changes in the SPI_GCLD libraries that seem to be what the problem is.

UPDATE:

Narrowed it down. Version 5.0 has broken the SPI_Glcd_PartialImage function.

Jim

[srdjan]

Hi,

Figured it out buy comparing the listing files. The biggest difference was in the SPI_GCLD code so I commented out my Splash Image Code. Guess what. No more Address Traps. I will enter a ticket but maybe Janni or one of the other sharp coders here can see the problem. Here is the listing files for a much stripped down version of my code:

http://www.mustangpeak.net/dsPIC_mP_SPI ... ge_Bug.zip

One is the new version 5.0 and the other is from version 4.8 Beta.

The main thing to notice is there have been changes in the SPI_GCLD libraries that seem to be what the problem is.

UPDATE:

Narrowed it down. Version 5.0 has broken the SPI_Glcd_PartialImage function.

Jim

- SPI_Glcd_PartialImage works fine here.
It's probably some code combination making the problem.
We can't really debug it here without some sample code.
If you can't send the whole code, please, try to extract it and send us small sample code to reproduce the problem.

In the mean time you could try using the trap code bellow to debug your code.
Just add these routines to your code.
Start ICD debuger and place breakpoints on while true loops.
My bet is the address trap exception.
Once it stops you'll have PC of the instruction following the one that caused the trap in the W12:W13 registers.
Then take a look at .lst file to find the address and locate the error instruction.

Also send us the .lst file and PC you got from the exception handler, so we can try to figure out what is wrong here.

Code: Select all

procedure OscillatorFailTrap(); org 0x06;  // if oscillator fails, the code jumps here
  begin
    TRISD := 0;
    LATD  := 1;
    Delay_ms(1000);

    asm
      MOV [w15-36], w12 // PC low to W12
      MOV [w15-34], w13 // PC high to W13
    end;

    while (TRUE) do
      ;
  end;

procedure AddressTrap(); org 0x08;  // if the addressing mode is wrong, the code jumps here
  begin
    TRISD := 0;
    LATD  := 2;
    Delay_ms(1000);

    asm
      MOV [w15-36], w12 // PC low to W12
      MOV [w15-34], w13 // PC high to W13
    end;

    while True do
      ;
  end;

procedure StackErrorTrap(); org 0x0A; // stack overflow, underflow...
  begin
    TRISD := 0;
    LATD  := 3;
    Delay_ms(1000);
    
    asm
      MOV [w15-36], w12 // PC low to W12
      MOV [w15-34], w13 // PC high to W13
    end;
    
    while True do
      ;
  end;

procedure MathErrorTrap(); org 0x0C; // div by zero etc...
  begin
    TRISD := 0;
    LATD  := 4;
    Delay_ms(1000);

    asm
      MOV [w15-36], w12 // PC low to W12
      MOV [w15-34], w13 // PC high to W13
    end;

    while true do
    ;
  end;

[JimKueneman]

In the mean time you could try using the trap code bellow to debug your code.
Just add these routines to your code.
Start ICD debuger and place breakpoints on while true loops.
My bet is the address trap exception.
Once it stops you'll have PC of the instruction following the one that caused the trap in the W12:W13 registers.
Then take a look at .lst file to find the address and locate the error instruction.

I agree, it is. The problem is that if I run it through the debugger it won't crash. I pulsed a IO pin for different lengths of time for different traps and yes it is a Address Trap.

What I was thinking was an uninitialized variable that is getting set to 0 when running under the debugger?

I did send the code with ticket WRQ-668895. I commented out a LOT of the code in what I sent (only start-up calls are being used) so any issues of timers, etc are off the table with this one.

Jim