Interrupt vector not at the correct address debug?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Interrupt vector not at the correct address debug?

Jump to solution
1,116 Views
ispd
Contributor II

Hello,

 

I have compiled and linked the a proyect. I see that the Software Interruptor Vector ISR is at address 0000A600. When I debug the code all is ok until the interrupt occurs. I see that the prolog is executed ok but when it must branch to the ISR instead of this address 0000A600 I see that goes to 0x38XXXXXX address. Why is that? In the map file the virtual address is correct. Is the pemicro debugger changing the TBL? should I change the .mac pemicro script mpc55xx_booke macro somehow.

 

Thansk a lot and best regards,

 

ispd

Labels (1)
1 Solution
657 Views
KenH
Contributor II

Here is a probem I've recently had with old example projects and newer versions of the compiler. The newer version of the compilers are passing variables via Regester, some of the old example projects have hand-written assembly code that was written when the compliers were still defaulting to pass on the stack method. So your vector base address (and other asm functions) might not be getting set properly becuse of an error in the low-level assembly utilities.  (Anyway the assembly and compiler settings have to be compatible)

 

look for something like this

mcf5xxx_wr_vbr:
_mcf5xxx_wr_vbr:
    move.l    4(SP),D0
    .long   0x4e7b0801      /* movec d0,VBR */
    nop
    rts

 

and change it to this

 

mcf5xxx_wr_vbr:
_mcf5xxx_wr_vbr:
    //move.l    4(SP),D0
    .long   0x4e7b0801      /* movec d0,VBR */
    nop
    rts

View solution in original post

3 Replies
658 Views
KenH
Contributor II

Here is a probem I've recently had with old example projects and newer versions of the compiler. The newer version of the compilers are passing variables via Regester, some of the old example projects have hand-written assembly code that was written when the compliers were still defaulting to pass on the stack method. So your vector base address (and other asm functions) might not be getting set properly becuse of an error in the low-level assembly utilities.  (Anyway the assembly and compiler settings have to be compatible)

 

look for something like this

mcf5xxx_wr_vbr:
_mcf5xxx_wr_vbr:
    move.l    4(SP),D0
    .long   0x4e7b0801      /* movec d0,VBR */
    nop
    rts

 

and change it to this

 

mcf5xxx_wr_vbr:
_mcf5xxx_wr_vbr:
    //move.l    4(SP),D0
    .long   0x4e7b0801      /* movec d0,VBR */
    nop
    rts

657 Views
bob_ge
Contributor I

Ken,

 

Thank you so much for this tip.  I've been working on this problem all day and your explanation of the new compiler / old example code incompatability, and the fix for the bogus VBR address writes from the mcf5xxx_wr_vbr function was just what I was looking for.  Needless to say, the VBR register is now being loaded with the right address consistently.

 

Thanks for sharing!

 

Regards,

Bob 

0 Kudos
657 Views
FridgeFreezer
Senior Contributor I

There is also the checkbox for "register colouring" and "peephole" in Settings -> Code Generation -> ColdFire Processor, these can confuse the debugger.

0 Kudos