Searching \ for '[SX]:Strange program behaviour' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/ubicom/devices.htm?key=sx
Search entire site for: 'Strange program behaviour'.

Exact match. Not showing close matches.
PICList Thread
'[SX]:Strange program behaviour'
2002\12\13@192926 by Jinx

face picon face
I've a program and circuit here

http://home.clear.net.nz/pages/joecolquitt/PIC2SX.html

that's got me stumped. As a newbie to SX it's possibly because
of something I don't know about them

The problem is that the program will trundle along quite happily
for a definite repeatable time, then stop. The time taken to stop
is shorter the fewer the pulses the SX is asked to put out

It will dependably output > 31,000 pulse/sec for 30+ seconds and
then stop. Or put out  > 3300 pulse/sec for 20 seconds and stop

However, at 62,500 pulse/sec it seems to run indefinitely. I haven't
determined at what pulse rate it does change behaviour, but I'm
not sure that would be helpful information

Any help would be appreciated, especially if it's something to do
with the way the SX is set up. I'm torn between a rogue timer (but
how ? - they're all shut off) or some kind of voltage build up that
eventually latches. The SX and TTL switching/propagation times
are getting quite close, and that may be some part of it. Perhaps
there are special remedial measures I couild take to improve
transition times

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2002\12\13@235340 by stanton54

picon face
I think you have a banking problem. Buff1-Buff8 are globals 08 through
0F which is OK. Then Buff9 is 10.
The line
       mov neg,buff9
means set neg (through W) to byte 0 in whichever bank is selected by the
upper FSR bits - which looks to be bank 0.
But if you set INDF to 10 then FSR is byte 0 of bank 1.
The rest of the variables are semi-directly addressed, so again they are
in bank 0 and inaccessible only semi-directly accessible.

The explanation of INDF and FSR in the 48/52 manual (pages 18 & 19) is a
little bit better, you might want to look at that.

Also, in one spot you set bit 4 of !RA which I think only has 4 bits on
the 18/20/28.

Jinx wrote:
>
> I've a program and circuit here
>
> http://home.clear.net.nz/pages/joecolquitt/PIC2SX.html
>
> that's got me stumped. As a newbie to SX it's possibly because
> of something I don't know about them
>
<snip>

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
[PIC]:,[SX]:,[AVR]: ->uP ONLY! [EE]:,[OT]: ->Other [BUY]:,[AD]: ->Ads

2002\12\14@004215 by stanton54

picon face
I just noticed something else. Your device word does not include an
oscillator selection. You need to use HS2 or HS3. I don't know what
assembler you are using but SASM doesn't seem to be able to figure it
out from the frequency.

stanton54 wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2002\12\14@004236 by Jinx

face picon face
----- Original Message -----
From: "stanton54" <spam_OUTstanton54TakeThisOuTspamEARTHLINK.NET>
To: <.....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU>
Sent: Saturday, December 14, 2002 5:50 PM
Subject: Re: [PICLIST] [SX]:Strange program behaviour


{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2002\12\14@004243 by Jinx

face picon face
(Sorry for other unedited message - hit Send instead of Reply)

> I think you have a banking problem. Buff1-Buff8 are globals 08
> through 0F which is OK. Then Buff9 is 10

Makes sense, and that's something I'll have another look at.
However, because the program seemingly works for quite a
while in at least some cases, I figured the compiler was sorting
out the RAM and banking. Feasible ?

Can you offer an explanation why the s/w and/or h/w would take
a definite time to fail ? And not fail above a certain pulse rate ?
That's what's got me. If there was such a basic error, then the
program should fail very quickly, possibly on the first iteration

> The line
>  mov neg,buff9
> means set neg (through W) to byte 0 in whichever bank is selected
> by the upper FSR bits - which looks to be bank 0.
> But if you set INDF to 10 then FSR is byte 0 of bank 1

Yes, understood

> Also, in one spot you set bit 4 of !RA which I think only has 4 bits on
> the 18/20/28.

That was a last-minute addition (which of course made no difference)
I just tried setting RTCC explicitly as an input, even though it already is

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2002\12\14@012437 by Jinx

face picon face
> I just noticed something else. Your device word does not include
> an oscillator selection. You need to use HS2 or HS3. I don't know
> what assembler you are using but SASM doesn't seem to be able
> to figure it out from the frequency

I'm using SX-Blitz / SX-Key with this. AFAICT

        device SX18L, turbo,stackx_optionx,bor42
        reset start
        freq 50_000_000

is enough / acceptable for this program. It's apparent looking at
pulse widths on the scope that the SX is indeed running the code
at 50MIPS

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2002\12\14@024805 by pearl62

picon face
While there's nothing glaringly wrong with yo code, there are a few things
that could cause problems, but it is hard to say which one...

Your memory allocation 'should' work, but it is far too simple and will soon
cause problems, if it is not already. Let me explain... The addresses from
$00-0F are global, so should be used sparingly. Those are global registers,
which means they can be directly addressed, and so do not depend on the
current value of the FSR. Assigning these as a buffer is ok, but kinda
wasteful.

The rest of the memory map for the SX is broken up into 8 banks of 16
registers, starting at addresses $10, $30, $50, $70, $90, $B0, $D0 and $F0.
These may seem strange, but in the internal architecture, the registers at
addresses $00-0F are made global by being shadowed accross $20, $40, $60,
$80, $A0, $C0, and $E0.

So, simply incrementing the FSR and then writing the value into the next
register gets you into trouble when you pass FSR = $1F. Or when trying to
write to memory allocated at $20, $40, $60, $80, $A0, $C0, or $E0. With FSR
= $20, writing to INDF puts the value into $00, which is strange as this is
the address of INDF itself! I'm not sure what would happen in this case.
Writing to $21 (really $01) will just write to the RTCC, and writing to $22
(really $02) writes to the PC, which is effectively the same as doing a JMP.
At this point you will have jumped to an address in memory being the value
you were intending to buffer!

You are currently only allocating up to $1E by my count, so you should still
be ok, however, you should be mindful of how you are allocating your
resources.

Here some macros I have used in the SX-Key environment in the past to
properly handle the banks, and increment or decrement pointers to buffers
properly to span banks.


;***************************************************************************
******
; Macro: _bank
; Sets the bank appropriately for all revisions of SX.
;
; This is required since the bank instruction has only a 3-bit operand, it
cannot
; be used to access all 16 banks of the SX48/52. For this reason FSR.4 (for
SX48/52BD/ES)
; or FSR.7 (SX48/52bd production release) needs to be set appropriately,
depending
; on the bank address being accessed. This macro fixes this.
;
; So, instead of using the bank instruction to switch between banks, use
_bank instead.
;
;***************************************************************************
******
_bank macro 1
bank \1

IFDEF SX48_52
  IFDEF SX48_52_ES
    IF \1 & %00010000  ;SX48BD/ES and SX52BD/ES (engineering sample) bank
instruction
 setb fsr.4  ;modifies FSR bits 5,6 and 7. FSR.4 needs to be set by
software.
    ENDIF
  ELSE
    IF \1 & %10000000  ;SX48BD and SX52BD (production release) bank
instruction
 setb fsr.7  ;modifies FSR bits 4,5 and 6. FSR.7 needs to be set by
software.
    ELSE
 clrb fsr.7
    ENDIF
  ENDIF
ENDIF
endm


;***************************************************************************
**************
; INCP/DECP macros for incrementing/decrementing pointers to RAM
;***************************************************************************
**************
INCP macro 1
 inc \1
IFNDEF SX48_52
 setb \1.4  ; If SX18 or SX28, keep bit 4 of the pointer = 1
ENDIF    ; to jump from $1f to $30, etc.
endm

DECP macro 1
IFDEF SX48_52
 dec \1
ELSE
 clrb \1.4  ; If SX18 or SX28, forces rollover to next bank
 dec \1  ; if it rolls over.  (Skips banks with bit 4 = 0)
 setb \1.4  ; Eg:  $30 --> $20 --> $1f --> $1f
ENDIF    ; AND: $31 --> $21 --> $20 --> $30
endm



Then functions like bufferInit, bufferPush and bufferPop shown below were
used...

;---------------------------------------------------------------------------
---
;VP: 62-byte buffer
; Subroutine:  Initialize the buffer.
; INPUTS:  None
; OUTPUTS:
;   - buffer[0] = NUL
;   - pushIndex->buffer[0]
;   - popIndex->buffer[0]
; CHANGES: buffer[0], pushIndex, popIndex
;---------------------------------------------------------------------------
---
bufferInit
_bank buffer
mov w,#buffer
mov pushIndex,w  ; set up indexes into the buffer
mov popIndex,w  ; pointers must point to #buffer.
clr buffer + 0  ; clear the first location in the buffer.
retp
;---------------------------------------------------------------------------
---
;VP: 62-byte buffer
; Subroutine:  Store W in buffer[pushIndex++]
; INPUTS:  data to store in W
; OUTPUTS: data stored in buffer[pushIndex++]
; CHANGES: localTemp1,pushIndex,buffer[pushIndex]
;---------------------------------------------------------------------------
---
bufferPush
mov localTemp1,w
_bank buffer
mov fsr,pushIndex
mov indf,localTemp1
_bank buffer
INCP pushIndex  ; Smart-Increment of the pointer to RAM
retp
;---------------------------------------------------------------------------
---
;VP: 62-byte buffer
; Subroutine:  Retrieve data in buffer[popIndex++]
; INPUTS:  popIndex
; OUTPUTS: data stored in buffer[popIndex] in W register
; CHANGES: popIndex
;---------------------------------------------------------------------------
---
bufferPop
_bank buffer
mov fsr,popIndex
mov w,indf
_bank buffer
INCP popIndex  ; Smart-Increment of the pointer to RAM
retp
;---------------------------------------------------------------------------
---


Also...

I notice that you're writing a 1 to RA.5, with the comment "RTCC pulled
low...". RTCC is a dedicated input pin, and has nothing to do with port A,
so setting this does nothing.

The device directives need to specifiy the OSC gain, ie. LP1, LP2, XT1, XT2,
HS1, HS2 or HS3. The SX datasheet explains what these are for. For 50MHz
operation, you will require HS2 or HS3 to operate reliably.

I hope this helps. While I don't see any specific failures (without
debugging the code), there are some standard practices which you are not
using that may haunt you.

{Original Message removed}

2002\12\14@044540 by Jinx

face picon face
> You are currently only allocating up to $1E by my count, so you
> should still be ok, however, you should be mindful of how you are
> allocating your resources

FSR is set to run between 08 and 1E and is reset on every loop
iteration. Which in some cases is over 1000 times before the
program stops for the mystery reason. This seems to be safely
within the bank's RAM limits

For other programs it may be necessary to look at how RAM is
managed, but I feel for the limited RAM this program needs what
is in place is OK. With all due respect to your opinion (and that's
not a politician's "due respect" - appreciate the help you and
Stanston are offering)

> I notice that you're writing a 1 to RA.5, with the comment "RTCC
> pulled low...". RTCC is a dedicated input pin, and has nothing to
> do with port A, so setting this does nothing

As noted in a previous post, sheer desperation to try anything

> The device directives need to specifiy the OSC gain, ie. LP1,
> LP2, XT1, XT2, HS1, HS2 or HS3. The SX datasheet explains
> what these are for. For 50MHz operation, you will require HS2
> or HS3 to operate reliably

It's not shown in the circuit diagram but the SXs are running on an
external 50MHz oscillator module. I believe that OSC settings don't
matter as there's no drive required. If there was a 50MHz crystal
on OSC1 OSC2 instead I'd have to give an OSCXT5 directive

The 50_000_000 directive is for debugging

> I hope this helps. While I don't see any specific failures (without
> debugging the code)

Well, when I find out what's going, that'll make two of us

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

2002\12\14@114851 by pearl62

picon face
In regards to the 50MHz drive issue... Even with an external crystal
oscillator, the internal drive still needs to be specified. At 50MHz, you
may not notice a problem, but for reliability it is required, and even the
oscillator manafacturers themselves even recommend having that gain present.
I cannot remember the exact reasons, but at higher frequencies, the chip
would not even run without having HS3 specified. As an example, when we were
testing 100MHz (the only choice you have for an oscillator at these
freqencies is external), HS3 was absolutely required.

Have you tried enabling the watchdog timer? You could then test the PD and
TO bits immediately in the reset vector to see what got you there. In your
loop, you then add the instruction CLR !WDT to keep reseting the watchdog.
If for any reason your code ends up outside of that loop, then you will end
being reset. At least you could try to recover, and that would at least tell
you that the code is jumping into the weeds somewhere.

Cheers,
Stephen
{Original Message removed}

2002\12\14@161253 by Jinx

face picon face
> testing 100MHz (the only choice you have for an oscillator at
> these freqencies is external), HS3 was absolutely required

"Crystal-Max" is ticked in Device panel, which is the highest drive

> Have you tried enabling the watchdog timer? You could then test

> you that the code is jumping into the weeds somewhere.

I noticed last night that the program doesn't actually stop. It just
appears to on the scope. When it's putting out 30,000+ pps the
trace on the scope is quite bright because of the pulse density.
When the program "stops" what actually happens is that the
spacing between the pulses goes from 0.0319ms to 4.756ms.
The pulses themselves remain at 60ns. This wasn't apparent
until I used a digital scope, which showed triggering, so I turned
the brightness right up on the analogue scope and adjusted its
trigger. It's still not a definitive answer though - it's unclear whether
the PIC is generating wonky data or the SX is making its own.
What I hope to do in the next couple of days is upgrade my logic
analyser to at least 50MHz so I can get a better idea of what data
is being presented to the SX. Then I'll have a culprit

Thanks for the SRC file

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics

More... (looser matching)
- Last day of these posts
- In 2002 , 2003 only
- Today
- New search...