m68k clock problem
pigeon.nicolas at wanadoo.fr
pigeon.nicolas at wanadoo.fr
Mon May 26 12:26:28 UTC 2003
>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
>> and that the exception table is correctly updated with the address
>> which calls rtems_clock_tick. The problem disappears when I disable
>> 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
>As Joel said the enabling of interrupts as a result of the first
>most likely the source of the problem.
>If you have the GDB stub working you should be able to 'stepi' into the
>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):
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
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=0x000146cc DB=0010 | read a value from the stack
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
>pointing to the _CPU_ISR_jump_table entry that creates the suitable
> VBR -> _CPU_ISR_jump_table -> _ISR_Handler
>and VBR = 0.
>The 68000 does not store the vector number in its default exception
>The _ISR_Handler routine expects this. Instead of extra code and paths
>_ISR_Handler, a 68000 has the extra redirection through the
>> Please, I REALLY need some help, I have been stuck for a week now,
>> 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 ---> _CPU_ISR_jump_table="movew #0x224,%sp at - ; jmp 107d4c" ---> _ISR_Handler (address=0x107d4c)
Moreover, _ISR_Vector_table=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
>you have caught. For example on the 68302 you have a vector base
>register in the
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
>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
>that shows what went off. The trace.c file in the BSP should help here.
>to watch the MBAR vector location and make sure you leave this one
>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 :-()
More information about the users