The bug in SX48/52?

Staryi

I find the strange work of the SX48 and SX52 MCU's.
This is a simple program for demonstration this bug:

DEVICE  PINS52,OSCHS2
IRC_CAL IRC_SLOW
FREQ 5000000 ; May be any
offset = 0x004 ; May be other (0x004..0x700..)
RESET start
 org 0x0a
R0 ds 1 ; 
R1 ds 1 ;
watch R0,8,udec
 org 0
 jmp @serv
start page main
 jmp main
 
org offset+2
serv reti

main
 Mov RTCC,#19
 Mov !option,#10001000b ; RTCC start
 jmp @Work
 org offset+0x800
Work
 nop
 clr R0
 Mov R1,#200
:loop nop
 nop
 inc R0
 djnz R1,:loop
 nop
break
 jmp $-1
 end

The value of R0 in breakpoint must be 200. Ok?
But it is 201! Why?
When I move "Work" in other program memory address (nor offset + 0x800), all work fine.
When disabled RTCC interrupt, this works fine too.

Bean

I must admit I have no idea what you are trying to do with this program ?
You need to condense the code to the absolute minimum that still causes the problem.

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

Staryi

I "condensed" code as soon as possible. This routine only for demonstrate this bug. The idea is that inc and dec operation my work abnormally, when interrupt is caused.
Not everything, but only if the main program and interrupt service routine are on defined distance in program memory space (this distance is near 0x800).

The main program (Work) has two counters - R0 and R1. The R1 is cycle counter, the start value is 200 (as example). R0 is independent counter, = 0 before cycle, and increment every loop.
The interrupt service routine (serv) is dummy, and caused by RTCC rollover every 256 MCU clocks.
The value of R1 after cycle must be equal R0 before it, i.e. 200, not so?
But in this program conditions it is 201!
If the Work routine is on other distance relativelly serv routine, all works ok.

Bean

Does it work if you run the code at 4 MHz instead of 50 MHz ? I'm thinking it may be related to the known read-modify-write problem.

One problem is that the SX52 is obsolete and I'm not sure if I have an SX52 protoboard. Does the problem occur on the SX48 ?

Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

Staryi

This problem occur at any frequency. I check 1 MHz to 20 MHz, with SX-Key or without it.
On SX48 (0547 prod.) this problem occur too.

Bean

How did you check it without the SX-Key ?
It seems to be a debugger issue to me.
Bean.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com

Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com

There are only two guaranteed ways to become weathy.
Spend less than you make.
Make more than you spend.
·

Staryi

This show the bug without debugger. RA.0 stay high when debug is detected. Used internal RC-oscillator at 32 kHz

; Demonstrate the inc/dec bug without debugger
; Need one LED connected from RA.0 to GND 
; (whis current limiter resistor, of course)
; When right work, must be one short LED flash after reset
; When this bug occur, the LED stay light.
; Use internal clock oscillator at 32 kHz.
 
DEVICE  SX48,OSC32KHZ
IRC_CAL IRC_SLOW
 
RESET start

 
        org 0x0a
R0      ds 1 ; checked counter
R1      ds 1 ; cycle counter

 
        org 0
; Interrupt service routine (dummy)
        nop
        nop
        reti
 
start   page main
        jmp main

 
 
main
        mov W,#0x1f  ; DDIR_W mode
        mov M,W  ;
        Mov !RA,#11111110b ; RA.0 for output
        Mov RA,#1  ; The LED is light
        Mov RTCC,#19
        Mov !option,#10001000b ; RTCC start
        jmp @Work
 
        org 0x800
; The critically routine
Work
        nop
        clr R0
        Mov R1,#200
:loop   nop
        nop
        inc R0
        djnz R1,:loop
        mov W,#200  ; Check R0 value (here must be 200)
        xor W,R0  ; Is equal?
        snz   ; Skip if not equal
         clrb RA.0  ; Switch off LED, if equal (bug not detected)
; If not equal, the LED stay light (bug detected)
:q      nop
        jmp :q  ; The end (empty unlimited loop)
 end

Staryi

Bean, I find the interesting thing. This bug is occurs only at 20 MHz and lower! On 50 or 40 Mhz this bug not detected. On 30 - sometimes. On 20 and lower - always!
This is one more version of bug demo program. It counts errors, and shows errcnt on RA.(0..3).

; Demonstrate the inc/dec bug without debugger (next version)
; Need 4 LED connected from RA.(0..3) to GND 
; (whis current limiter resistor, of course)
; When right work, LEDs don't light
; When this bug occur, the LEDs shows 4 bits of error counter
; Use internal clock oscillator at 32 kHz.
 
DEVICE  SX48,OSC32KHZ
;DEVICE  SX48,OSCHS3

;FREQ 20000000 ; May be any from 32 kHz up to 20 MHz - uncomment if work with debugger
IRC_CAL IRC_SLOW
 
RESET start
        org 0x0a
count1  ds 1 ; Two counters
count2  ds 1 ;
errcnt  ds 1 ; error counter
 
        org 0
; Interrupt service routine (very dummy)
        reti
 
start   page main
        jmp main
main
        mov W,#0x1f  ; DDIR_W mode
        mov M,W      ;
        Mov !RA,#11110000b ; RA.(0..3) for output
        clr errcnt   ; errcnt = 0
        Mov RTCC,#0
        Mov !option,#10001000b ; RTCC start
        jmp @Work
 
        org 0x800

; Critically routine
Work    clr count1    ; count1 = count2 = 0
        clr count2    ;
:loop   inc count1    ; Counters increment
        inc count2    ;
;if is no bug, count1 and count2 must be equal here
        nop           ; for odd loop clocks (9)
        mov W,count1  ; Compare counters
        xor W,count2  ;
        snz           ;
         jmp :loop    ; Infinite loop if equal
        inc errcnt    ; if not - count errors
        Mov RA,errcnt ; Show errcnt
        jmp Work  ; Repeat
 
        end