m68k clock problem

[pigeon.nicolas at wanadoo.fr]

Hi John,

>Nicolas PIGEON wrote:
>> 
>> I still can't solve this problem, but I have some news. The
>>_CPU_ISR_install_raw_handler works OK,
>> I can see that the right address is writen in the clock exception
>>vector 
>>(_ISR_Handler),
>> and that the exception table is correctly updated with the address 
>>of
>>Clock_isr,
>> which calls rtems_clock_tick. The problem disappears when I disable
>>the Timer 
>>1 interruption
>> by removing the line:
>> m302.reg.imr |= RBIT_IMR_TIMER1
>> but of course, there's no clock after that. 
>> The interruption is raised precisely when the RTS instruction is
executed.
>>

>As Joel said the enabling of interrupts as a result of the first 
>context
>switch 
>most likely the source of the problem.

>If you have the GDB stub working you should be able to 'stepi' into the
>context 
>switch and see what is happening.


I'm using an external logic analyzer to monitor the signals, I don't use the GDB stub.
I'll try to explain what happens. Here's what I see on the logic analyzer (RAM=0x00000000, ROM=0x00100000):

00107d24: <_CPU_Context_switch>:
107d24:     moveal  %sp@(4),%a0          | OK, reads a value from the stack in RAM
                  movew  %sr,%d1                  | OK
                  andiw  #0x2fff,%d1               | to make sure that tracing is disabled, but it's the same with or without this line
                  moveml  %d1-%d7/%a2-%sp,%a0@      |OK, values are copied in RAM. The old stack pointer is 0xab60
                  moveal  %sp@(8), %a0         | OK, value copied from RAM
00107d36: <restore>:
107d36      moveml  %a0@,%d1-%d7/%a2-%sp  |values are copied from RAM, the new stack pointer is 0x146d0
                  andiw  #0x2fff,%d1               |disable tracing
                  movew  %d1, %sr                 | new status register

And now the problem comes... (Address bus=AB, data bus=DB):
AB=0x00107d28        DB=4e75               | the opcode of the RTS instruction is fetched
AB=0x00107d2a        DB=0000               | nothing in ROM here, but this 32 bits processor fetches the instructions two by two, so don't care
AB=0x000146ce        DB=7d28               | read a byte of the return address from the stack, it seems to be the lower byte of the instruction "movew %sr,%d1" in _CPU_Context_switch
And the exception seems to occur here, the processing begins...
AB=0x000146ca        DB=2000
AB=0x000146cc        DB=0010              | read a value from the stack
AB=0x00000024        DB=0010
AB=0x00000026        DB=0514              | read the exception vector n°9 in RAM (the clock interruption vector is n°137...), points to address 0x100514 (in ROM) where the unhandled exception handler resides (not the RTEMS one).
And then the exception is processed.......



>I assume you have a vector table at address 0 (VBR = 0). When you say 
>_CPU_ISR_install_raw_handler works ok, I assume the real vector table
>entry is 
>pointing to the _CPU_ISR_jump_table entry that creates the suitable
>stack frame 
>for _ISR_Handler.
>   VBR[256] -> _CPU_ISR_jump_table[256] -> _ISR_Handler
>and VBR = 0.

>The 68000 does not store the vector number in its default exception
>stack frame. 
>The _ISR_Handler routine expects this. Instead of extra code and paths
>in 
>_ISR_Handler, a 68000 has the extra redirection through the
>_CPU_ISR_jump_table.
>>
>> Please, I REALLY need some help, I have been stuck for a week now, 
>>and
>>my internship
>> will end soon... If you have any idea, don't hesitate !!!
>>


After a bunch of Ram dumps, It seems everything is OK there. Here's the situation before the system hangs (NB: 137 is the clock interrupt vector number):
VBR[137] ---> _CPU_ISR_jump_table[137]="movew #0x224,%sp at - ; jmp 107d4c" ---> _ISR_Handler (address=0x107d4c)

Moreover, _ISR_Vector_table[137]=address of Clock_isr

As you saw before, the processor never attempts to read the clock exception vector. I add some lines to the code so that it should print a * each time it enters the Clock_isr code, but I never saw that yet :-(


>The reasons for the interrupt failing can be summed with:
>1) The real vector table not being set up correctly.
>2) Invalid device programming thats generates a different exception 
>than
>the one 
>you have caught. For example on the 68302 you have a vector base
>register in the 
>SIM.


Interesting... I saw in the 68302 User's manual that the pin AVEC* can be used for autovectoring. It's not connected on my board, but it only seems to be useful when external interrupts are caught, and my interrupts line are not used. Could it be a problem?
By the way, could you tell more about the vector base register in the SIM? I found nothing about that...


>3) The stack is invalid and generates a bus error. In this case you 
>will
>get a 
>double bus error and the processor will halt.


Yeah, I used to see this a few weeks ago, but it doesn't look like a double bus error this time ! Here the processor doesn't halt but keeps on processing the exception (but the wrong one !!)


>I would catch every vector you can with a default handler and point to
>something 
>that shows what went off. The trace.c file in the BSP should help here.
>You need 
>to watch the MBAR vector location and make sure you leave this one
>alone. The 
>GDB stub has examples of what you need to do to catch all vectors.

>I hope this helps.


Yes it does, thank you for everything !! (but I think I'm gonna leave work late tonight :-()