ScratchPad Corruption vs Settimer - 28X1

A

AlanT

New Member
Hi All

As a relative novice in 28X1 programming I've been having a problem with apparent memory corruption. However, when I cut away the code, I was left with the fact that using the "settimer 65380" command to set the timer to tick at 100Hz, leads to the data in scratchpad byte 15 being altered unexpectedly.

I've read through the manual several times, but can see no reason for this to happen.

I've included a blank "interrupt:" service subroutine, and disabled interrupts anyway with the "setintoff" command, and the "setintflags off" commands.

Any ideas ?
 
hippy

hippy

Ex-Staff (retired)
Staff member
No idea. You can post your code so others can see exactly what you are doing and can check if they see the same issues occur. Code trimmed to the bare minimum to demonstrate the problem which doesn't rely on hardware connections others don't have is the best.
 
Technical

Technical

Technical Support
Staff member
This replies with the correct value $55 for us:

Code: 
put 15,$55
main:
settimer 65380
pause 5000
get 15,b1
debug
goto main
Are you mixing up put/get (scratchpad) with peek/poke (sfr), if so byte 15 will definitely be changing - as peeking 15 will be the timer low byte....
 
A

AlanT

New Member
Re Scratchpad byte 15 - Short Code

Hi All, thanks for the replies so far. Yes peek & poke do look very suspicious, as the value in byte 15 of scratchpad does look exactly like the timer running. But I haven't used peek or poke at all, anywhere. See this code. I started with a reasonably large program which first showed the problem. I had re-assigned scratchpad locations for the storage of DS18B20 sensors. I was displaying their values as a summary, but one of the unattached sensors was giving a changing value. I then stripped that program down more and more until I had just one very small display subroutine left, and I could write a fixed value to byte 15, then display it and see it changing.

I thought I might have a faulty PIC, so I wrote a memory test program, but it passed every pattern I could think of. Then I went back to the original code to see what else was different between the two programs. I took out the timer command and found the "corruption" stopped. I then put the timer command into the smaller memory test program, and it failed. I've cut it down to just the first part, but it shows the issue.

I'm using the bog-standard hardware of a 28X1 project board with the 2x16 LCD display and calendar chip. It's powered by 4 rechargeable batteries.

I can only assume I'm doing something daft, but as usual with debugging - I can't see what it is.

All help appreciated

Alan
Code: 
;*********************************************************************
;;
; Memory Test Program
;
; Alan Tresadern, 14th January 2008
;
; For PICAXE 28X1 Project Board with LCD Display & Clock Module
;
;
;********************************************************************
;
; Tests Scratchpad Memory 0-127
;
;***********************************************************************
;
; set picaxe type for compiler
;
    #picaxe 28x1
;
;*******************************************************************
;
;
;
; ***** following memory tests pass until settimer command is included
; then fails immediately on the first test *****
;
; other tests have shown address 15 (at least) is changed by timer activity
;
;
    settimer 65380                    ;timer ticks at 100Hz / 10ms period
;
mem_test:
    b3=0            ;loop count for test
;
; initialise and clear display
;
    pause 500
    i2cslave $c6,i2cslow,i2cbyte            ;set the i2c device as the display
;
mem_loop:
;
    inc b3
;
    writei2c 0,(254,1,255)                ;clear display
    pause 10
;
; indicate progress - loop number
;
    writei2c 0,(b3," ",255)
    pause 10
;
    inc b3
;
;
; indicate progress - test 1
;
    writei2c 0,("1 ",255)
    pause 10
;
; write pattern to scratchpad
;
    b0=0
    b1=$a5
    do
        put b0,b1
        inc b0
    loop until b0>127
;
; read back pattern
;
    b0=0
    do
        get b0,b1
        if b1 <> $a5 then
            writei2c 0,("1F ",255)
            stop
        endif
        inc b0
    loop until b0>127
;
; further tests, not needed to demonstrate problem...
;
    goto mem_loop
 
Last edited by a moderator:
B

BCJKiwi

Senior Member
Well I don't have an LCD hooked up so ran the following code 3 code snippets with output to terminal. As far as I can see this code would all do what your code does.

There is no problem with any of the three with or without the settimer line.

Code: 
#picaxe 28x1
settimer 65380 ;timer ticks at 100Hz / 10ms period
;
mem_loop:
; write pattern to scratchpad
#rem
b0=0  'memory location
b1=$a5  'data to write 
for b0 = 0 to 127
sertxd (#b0,"  ")
put b0,b1 'put $a5 (dec 165) in location 0
get b0,b2 ; read back pattern
sertxd (#b2,cr,lf)
next ' loop until reach end of memory locations
#endrem
;
#rem
b0=0  'memory location
b1=$a5  'data to write 
do while b0 < 128
sertxd (#b0,"  ")
put b0,b1 'put $a5 (dec 165) in location 0
get b0,b2 ; read back pattern
sertxd (#b2,cr,lf)
inc b0
loop ' loop until reach end of memory locations
#endrem
;
b0=0  'memory location
b1=$a5  'data to write 
do 
sertxd (#b0,"  ")
put b0,b1 'put $a5 (dec 165) in location 0
get b0,b2 ; read back pattern
sertxd (#b2,cr,lf)
inc b0
loop while b0 < 128 ' loop until reach end of memory locations
;
stop
All I got from your original code (after changing the output to the terminal but not changing anything else) was;
1
1
1F

From all three code snippets above, you get the memory address and it's contents form 0 through 127
e.g.
0 165
1 165
.
.
.
126 165
127 165
 
Last edited:
A

AlanT

New Member
Hi Kiwi

Thanks for trying to reproduce the problem !

I have a suspicion again that my PIC is faulty, but perhaps another reason you haven't seen the problem is that the change to the memory takes a little time - whether or not it is the timer which is doing it. Therefore a write and immediate read are unlikely to "catch" the problem. Note that my routine writes the whole memory before reading back.

The later sections also wrote the address as data, and then the inverse address as data, both writing the whole pattern before reading back. B3 was used to offset the data by 1 each complete cycle of the memory tests, so if it was left running it would eventually write every data value to every address.

A further thought from early discussion is that the use of debug may well change things, as it uses the timer at some level.

I plan to buy another PIC ( I need a spare anyway), so that will be very interesting.

I presume the selection of memory within the PIC can't be influenced by anything wrong on the project board (dry joint, micro-short etc).

It seems the problem could be due to selecting the wrong bank of memory for the timer or scratchpad ?

Cheers

Alan
 
Technical

Technical

Technical Support
Staff member
We have repeated the error here so it does indeed look like an obscure issue in the firmware or compiler that we will have to look at. Thnaks for bringing it to our attention.
The workaround is to not use scratchpad byte 15 when timer is enabled. No other bytes are likely to be affected.
 
A

AlanT

New Member
I'm afraid it's worse than that - I've written a more comprehensive memory test, and I think you'll find bytes 15 and 79 are both altered by the timer running. The test can be made to pass by slowing down the timer, but that's just because the write and read occurs before the timer ticks.

I've attached the code, (I think):
 

Attachments

R

retepsnikrep

Senior Member
Hi

Any update on if this error has been corrected? I'm using the scratchpad Ram for extensive data logging and i'm using the timer as well :(

Regards
 
You must log in or register to reply here.
Top