Am 16.09.2002 23:41:34, schrieb Galen Seitz <[email protected]>:
>> Am 16.09.2002 21:54:51, schrieb Galen Seitz <[email protected]>:
>> >[email protected] said:
>> >> Within ISR interrups are disabled unless you reenable it (with
>> >> enablenested attribute).
>> >>
>> >> For non-IRS: Yes, there is an attribute 'critical' (read doc.txt)
>> >> which does as follows:
>> >>
>> >> funct:
>> >> push r2 ; save status
>> >> dint ; disable ints
>> >> ...pushes
>> >> .... funct body follows
>> >> ...pops
>> >> reti ; restore r2 and return.
>> >>
>> >
>> >Isn't there a potential problem with this? If an interrupt occurs between
>> >the push r2 and the dint, and the interrupt routine returns with interrupts
>> >disabled, interrupts will get reenabled by the reti. Or is this a case of
>> >"don't do that"?
>>
>> true, but there is not simple solution to that. you must first save r2/SR
>> before disabling the interrupts and you can't check after dint if an irq
>> switched it off, cause dint did it....
>>
>> so, you should not disable the GIE in an interrupt. however, you may
>> disable any individual interrupt sources through their respecitive IE bits.
>>
>
>I figured this was the case, but I'm new to the instruction set, so I
>thought I might have missed an atomic test and set capability.
>
>BTW, what instruction is typically used for a breakpoint? I don't see
>an SWI or TRAP instruction.
there isn't any :-o
TI sugest that you can use the unbonded, but present, pins P2.6 and P2.7 on
a F1121 for such a purpose. switch to output, enable IRQ, toggle P2OUT.6/7.
you can also generate key access violations ...
#define TRAP() __asm__ __volatile__ ("mov %0, %1"::"i"(0xa500|ACCVIFG),
"m"(FCTL3))
interrupt(NMI_VECTOR) nmi(void) {
FCTL3 = 0xa500; //ack irq
P1OUT++; //debug
IE1 |= ACCVIE; //must be last insn before reti!
}
int main(void) {
IE1 = ACCVIE;
...
TRAP();
...
}
the breakpoints you know from the debugging tools are "built-in" in the JTAG
hardware
and are not accessible from software.
chris
