rts throws Address Error after PIT enable

[seagate]

This subroutine of TCP/IP stack in mcf 5223.c throws an exception when calling rts.  A7 points to the correct return address.

/*
 * Setup PIT Timer
 */
void
PIT_Timer_Init(uint8 PCSR, uint16 PMR)
{

 /* Set tic for timers */

 MCF_PIT0_PCSR  = (uint16)(MCF_PIT_PCSR_PRE(PCSR)); /* Divide system clock/2 by 2^PCSR */
 MCF_INTC0_ICR55 = MCF_INTC_ICR_IL(TIMER_NETWORK_LEVEL)|MCF_INTC_ICR_IP(TIMER_NETWORK_PRIORITY);
 MCF_INTC0_IMRH &= ~MCF_INTC_IMRH_MASK55;
 MCF_PIT0_PMR = PMR;      /* modulo count */
 MCF_PIT0_PCSR |= MCF_PIT_PCSR_OVW | MCF_PIT_PCSR_PIE |
                  MCF_PIT_PCSR_PIF | MCF_PIT_PCSR_RLD |
                  MCF_PIT_PCSR_EN;
}

Any ideas?

[mjbcswitzerland]

Hi

Check whether the same thing happens when the interrupt is not enabled (eg. skip the MCF_PIT0_PCSR write) - possibly (when debugging and stepping) the TICK fires and it is a problem with the interrupt handling rather than the RTS since the interrupt would occur (sort of) immediately.

Regards

Mark

[seagate]

Thanks for your reply.   It doesn't seem to call the isr.

If I skip the write in debug I get the exception on rts as before but if I rem the line out and reflash I get past it OK.  But how to enable the timer?

[mjbcswitzerland]

Hi

It may be that when debugging you are still executing the instruction to enable PIT and its interrupt (it is best to step in disassembler mode to be sure because the debugger can jump around about when source-level debugging). It does however sound as though the interrupt is not working correctly.

How have you configured the VBA and how have you entered the ISR in the vector base table?

Regards

Mark

[seagate]

Hi

Vector 0x77 (64+55) - PIT0 is listed as  _timer_isr.  The ISR is in Int_handlers.c as __interrupt__ void timer_isr(void) .  A breakpoint in there does not get activated.  Can't see anything wrong there but is there a way of seeing what's happening on a smaller scale?

[mjbcswitzerland · Accepted solution]

Hi

PIT0 indeed has vector 0x77. Make sure that the VBR is set to point to the location of the vector table (0x00000000 when in FLASH or 0x20000000 when in SRAM).

You could also analyse the exception that is being thrown (from somewhere) - there is a guide here: http://www.utasker.com/forum/index.php?topic=123.msg468#msg468

Regards

Mark

[seagate]

I think that is the answer.  Nothing to do with rts but the interrupt fires on the next instruction whatever it is.

The link you gave means I can now interpret the 'rubbish' address that appears on the cw stack after the exception - 0x41DC2000.  1DC=4*0x77 and at 0x00001DC is the address of the ISR.  The VBR, however, is set to 0x2000000 and 0x200001DC points to no code!

Now why this should be is another story and maybe should be another thread.  I am using cw 7.2.1 and the code I am trying to run is possibly written for an older version.   There is something different about the way parameters are passed.  During initiation the value 0x00000000 is loaded into A6 and then a sub called which takes its value from 4(A7) so the VBR gets written with a 'random' value 0x20000189, setting it to point to SRAM.

Further research required! 

Thanks a lot for the solution to my original problem

[mjbcswitzerland]

Hi

I believe that some basic settings were change between CW7.1 and CW7.2 since I heard of a similar problem with register passing.

1) You will probably find a file called mwerks.h somewhere being linked into the project (I think this goes back to when the software was called Hiware from Metrowerks before being taken over by Freescale) - there is a setting controlling passing return values:

#pragma pointers_in_A0

With this, subroutines will pass return pointers in A0 (they return non-pointers in D0). Without it both, pointers and non-pointers are returned in D0. The libraries linked must match the application file settings.

2) In the compiler options there is a setting to say whether subroutine parameters are passed via stack or registers (with registers the code is smaller and probably faster). Again the libraries used must match (the passing strategy can be see from their names).

3) Any assembler code used must match: Assembler code has no settings and an assembler file written for stack passing will fail when used together with C code compiled for register passing. Therefore look into the assembler (usually the setting of VBA is performed in assembler code) since this file may no longer be compatible with the project settings.

The following are typical assembler codes for setting VBA:

a) stack passing

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

b) register passing (passed via d0)

_mcf5xxx_wr_vbr:
   .long    0x4e7b0801                                                   // assembler code for movec d0,VBR
    nop
    rts   

c) when the assembler supportsMOVEC (also register passing)

mcf5xxx_wr_vbr:                                                          // sub-routine for access to VBR
        MOVEC.L D0, VBR
        rts   

Regards

Mark

[seagate]

CW 7.2 is only register passing and the code I have is definately using stack passing.  I have changed as many of the asm functions, including:

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

The interrupts now work OK but the program still crashes eventually.  My options now seem to be:

1.  Find more asm code that needs modifying. Not a trivial task I fear.

2.  Get an older version of CodeWarrior.  6.3 is still available.

3.  Put the lot in a shoebox in the 'too difficult' pile.

I'll post here again before going for option 3!

Thanks again.

[mjbcswitzerland]

Hi

There is normally only one asm file in the project so probably the required changes were adequate.

There could be other reasons for a later exception which are unreleated. You need to analyse each as they arrive.

You can also get complete working projects from various sources to save time and heart-ache.

Regards

Mark

http://www.utasker.com/

[seagate]

Hi again

I chased a lot of address errors .  It would hang halfway through sending text - maybe some buffer overflow?  Anyway these went away when I disabled the debug texts.  So now it would run without error but with no ethernet access.   Eventually I found another asm file 'chksum.s' which needed changing for register passing.

Result!