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 ----- From: "Jinx" To: Sent: Friday, December 13, 2002 4:28 PM Subject: [SX]:Strange program behaviour > 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 > -- 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