Re: Chipcon/8051 sanity check

FreeRTOS.org wrote:

<snips>

000201 0E INC R6
x = c;
000202 EE MOV A,R6
000203 90 F2 00 MOV DPTR,#0xF200
000206 F0 MOVX @DPTR,A
000207 80 F8 SJMP 0x0201


00020C 85 10 82 MOV DPL,XSP(L)
00020F 85 11 83 MOV DPH,XSP(H)
000212 E0 MOVX A,@DPTR
000213 24 01 ADD A,#0x01
000215 F0 MOVX @DPTR,A
000216 80 F4 SJMP 0x020C



If I disable and enable interrupts around the line where c is incremented I find that the clean square wave returns and timer interrupts are no longer missed, so I was postulating that an interrupt occurring between the sequential access of the two XSPbytes might have been causing some corruption within the ISR, but the code generated for the interrupt is as follows:

T3_IRQ_C:
0003CB C0 E0 PUSH A
P1=~P1;
0003CD E5 90 MOV A,P1
0003CF F4 CPL A
0003D0 F5 90 MOV P1,A
TIMIF = 0;
0003D2 75 D8 00 MOV TIMIF,#0x00

0003D5 D0 E0 POP A
0003D7 32 RETI

Either there is something seriously amiss or I have done something too dumb for me to see.

Something is amiss. A 7 line, 1ms INT _should_ be competely 'dont care' to any 'outside' code, provided that code does not
a) mess with the timer registers
b) fire other interrupts, or disable interrupts


From a test viewpoint, I'd normally toggle a single pin, than a whole port, and choose a pin that is not interrupt allocated.
(just in case you have another INT firing from P1 toggling, for example)

What has changed, is an absolute address 0xF200 is now in XSP(L) or XSP(H) - do you _know_ where they are pointing ?

The other change, is you added a XDATA read, where prior loop was only write. Of, course that _should_ not make any difference at all.... :)

-jg



.

Relevant Pages

  • Re: Chipcon/8051 sanity check
    ... If I disable and enable interrupts around the line where c is incremented ... I find that the clean square wave returns and timer interrupts are no ... I have tried a single pin also. ... An IEC 61508 compliant real time kernel for safety related systems. ...
    (comp.arch.embedded)
  • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
    ... I think in case of PIC mode, interrupts ... Yes it's probably virtual wire. ... This will make sure that even in virtual wire mode, timer interrupts ...
    (Linux-Kernel)
  • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
    ... I think in case of PIC mode, interrupts ... Yes it's probably virtual wire. ... This will make sure that even in virtual wire mode, timer interrupts ...
    (Linux-Kernel)
  • Re: [PATCH] kexec: force x86_64 arches to boot kdump kernels on boot cpu
    ... I think in case of PIC mode, interrupts ... Yes it's probably virtual wire. ... Here we read the apic id of crashing cpu and program IOAPIC accordingly. ... This will make sure that even in virtual wire mode, timer interrupts ...
    (Linux-Kernel)
  • Re: Clock Problem?
    ... cat /proc/interrupts ... the timer interrupts. ... OK, your timer interrupts are occurring at 500Hz, while your kernel thinks ... that they are occuring at 250Hz. ...
    (alt.os.linux.suse)