Re: Chipcon/8051 sanity check
- From: "FreeRTOS.org" <noemail@xxxxxxxxxxxxx>
- Date: Mon, 12 Mar 2007 22:39:23 GMT
"Jim Granville" <no.spam@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
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
0003CB C0 E0 PUSH A
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)
I have tried a single pin also. The problem occurs even without a write to
the port, hence I put in the test code to toggle the pin(s). This started
as a larger program and I gradually stripped things out expecting to find
the source of the problem, but having stripped out everything was left with
an empty loop and still a problem :-(
I have tried using timer 1 in place of timer 3 - same problem.
The errata states that timer interrupts originating from the 'sleep' timer
can be missed if the processor is in power mode 0 (which it is) but says
nothing about any other timers.
What has changed, is an absolute address 0xF200 is now in XSP(L) or
XSP(H) - do you _know_ where they are pointing ?
Not being in the office now I cannot check - but I know they are constant
within the loop (as would be expected from the assembly).
A free real time kernel for 8, 16 and 32bit systems.
An IEC 61508 compliant real time kernel for safety related systems.