Post by thread:[PIC]: Table bug

I need some help here. Can anyone see a reason why the program might go off into never-neverland during this subroutine? The part is a 17C44. org 0x7E4 ;place routine here to prevent ;crossing page boundary ascii_con ;value to convert is in wreg movwf offset ;save wreg movlw HIGH (ascii_con1) ; movwf PCLATH ;initialize PC high latch movfp offset,wreg ;load offset back into wreg andlw 0x0F ;clear high nibble to prevent overflow addlw LOW (ascii_con1) ;add desired offset to PC low movwf PCL ;jump ascii_con1 retlw 0x30 ;0 retlw 0x31 ;1 retlw 0x32 ;2 retlw 0x33 ;3 retlw 0x34 ;4 retlw 0x35 ;5 retlw 0x36 ;6 retlw 0x37 ;7 retlw 0x38 ;8 retlw 0x39 ;9 retlw 0x41 ;a retlw 0x42 ;b retlw 0x43 ;c retlw 0x44 ;d retlw 0x45 ;e retlw 0x46 ;f We fill all unused program memory spaces with a GOTO Watchdog_timout statement. Using an emulator, we'll let the program run and, occasionally, we'll find the program in that timeout routine (the watchdog is disabled for debug reasons). The last thing in the stack is the Call ascii_con statement. Interrupts are disabled during the routine that calls ascii_con. I appreciate any help. Ryan -- http://www.piclist.com hint: To leave the PICList spam_OUTpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Dunno about 17C44, does this 16CXX solution apply? ascii_con sublw 10 skpnc addlw 7 addlw 58 return On Mon, 23 Oct 2000, Ryan Miller wrote: {Quote hidden}> Date: Mon, 23 Oct 2000 09:57:47 -0700 > From: Ryan Miller <.....frmillerKILLspam@spam@plix.com> > To: PICLISTKILLspamMITVMA.MIT.EDU > Subject: [PIC]: Table bug > > I need some help here. > > Can anyone see a reason why the program might go off into > never-neverland during this subroutine? The part is a 17C44. > > org 0x7E4 ;place routine here to prevent > ;crossing page boundary > > ascii_con ;value to convert is in wreg > movwf offset ;save wreg > movlw HIGH (ascii_con1) ; > movwf PCLATH ;initialize PC high latch > > movfp offset,wreg ;load offset back into wreg > andlw 0x0F ;clear high nibble to prevent overflow > addlw LOW (ascii_con1) ;add desired offset to PC low > movwf PCL ;jump > > ascii_con1 > retlw 0x30 ;0 > retlw 0x31 ;1 > retlw 0x32 ;2 > retlw 0x33 ;3 > retlw 0x34 ;4 > retlw 0x35 ;5 > retlw 0x36 ;6 > retlw 0x37 ;7 > retlw 0x38 ;8 > retlw 0x39 ;9 > retlw 0x41 ;a > retlw 0x42 ;b > retlw 0x43 ;c > retlw 0x44 ;d > retlw 0x45 ;e > retlw 0x46 ;f > > We fill all unused program memory spaces with a GOTO > Watchdog_timout statement. Using an emulator, we'll let the > program run and, occasionally, we'll find the program in > that timeout routine (the watchdog is disabled for debug > reasons). The last thing in the stack is the Call ascii_con > statement. Interrupts are disabled during the routine that > calls ascii_con. > > I appreciate any help. > > Ryan > > -- > http://www.piclist.com hint: To leave the PICList > .....piclist-unsubscribe-requestKILLspam.....mitvma.mit.edu > > > > -- http://www.piclist.com hint: To leave the PICList EraseMEpiclist-unsubscribe-requestspam_OUTTakeThisOuTmitvma.mit.edu

Hi, not really sure what is wrong with it, but as it intermittent, my guess is probably context saving during IRQ ? positive thats ok ? and that the var offset is not touched inside irq also ? Further a snippet that might help :) ( would perform the same function ) ; *********************************************************************** ; ; TX_ADD_HEX - Add two bytes of ASCII decimal (0-9, A-F) in out buffer from nibbles ; in W-reg ; NOTE uses TWO deep stack ( nested calls ) !! ; TX_ADD_HEX MOVWF Temp ; save byte temporarily SWAPF Temp,W CALL TX_ADD_NIBBLE ; first one MOVF Temp,W ; get back temp ; and add second one TX_ADD_NIBBLE ANDLW 0x0F ; mask out top nibble, preserv low nibble ADDLW 0xF6 ; add 246, to check if 0-9 or a-f, w=nibble+246 BTFSC STATUS,C ; if carry set then a-f ADDLW 0x07 ; carry set, then add 7, w=nibble+246+7 ( note nibble known to be a-f ) ADDLW 0x3A ; then finally add 58 to get 'proper' ascii ; 1) w = low(nibble+246+58) = 48+nibble ( if 0-9 ) ; 2) w = low(nibble+246+7+58) = 55+nibble ( if a-f ) CALL TX_ADD_BUFFER ; add it to tx buffer RETURN /Tony Tony Kübek, Flintab AB ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² E-mail: tony.kubekspam_OUTflintab.com ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² -- http://www.piclist.com hint: To leave the PICList @spam@piclist-unsubscribe-requestKILLspammitvma.mit.edu

Hi again, Just a thought, I'm not sure if this is different on the 17x series, but on 16x NEVER trust PCLATH, if you are doing manual pcl 'adjustment' never forget to ALSO set PCLATH. I think this macro could work: ;+++++ ; TABLE_JUMP Calculates an eventuntual table boundary crossing ; set's up the PCLATH register correctly ; Offset must be in w-reg, offset 0 jumps to the next instr. ; TABLE_JUMP MACRO MOVWF Table_Temp ; save wanted offset MOVLW LOW($+8) ; get low adress ( of first instr. after macro ) ADDWF Table_Temp,F ; add offset MOVLW HIGH($+6) ; get highest 5 bits ( of first instr. after macro ) BTFSC STATUS,C ; page crossed ? ( 256 byte ) ADDLW 0x01 ; Yes add one to high adress MOVWF PCLATH ; load high adress in latch MOVF Table_Temp,W ; get computed adress MOVWF PCL ; And jump ENDM Drawback, one dedicated byte of ram ( but trust me it's worth it :) ) /Tony Tony Kübek, Flintab AB ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² E-mail: KILLspamtony.kubekKILLspamflintab.com ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² -- http://www.piclist.com hint: To leave the PICList RemoveMEpiclist-unsubscribe-requestTakeThisOuTmitvma.mit.edu

Tony, Thanks for the pointer. Both you and Rich sent routines to perform the function differently. This is an old program that was written in the heat of the battle and not very elegant. Unfortunately, there are about three other table reads like this for other functions that will also occasionally lose it. I'm trying to understand why the read doesn't work sometimes (very rarely). In your other message you mention not to trust PCLATH. Can it change somehow after I load the high address byte in? Interrupts are disabled during this portion of the program. Thanks for your help. > {Original Message removed}

Hi, Ryan Miller wrote: -snip >occasionally lose it. I'm trying to understand why the read >doesn't work sometimes (very rarely). In your other message >you mention not to trust PCLATH. Can it change somehow after >I load the high address byte in? Interrupts are disabled >during this portion of the program. Yes, was abit stressed out last night, first I missed Your statement about irq disabled, then I also missed the portion where you set-up PCLATH. Netherless today I re-read Your message and still think that PCLATH could be the culprit. Maybe not directly in this routine, but after the call PCLATH contains the value of high(ascii_con1). The next call/goto or tablejump could then potentionally jump to never-never land. As far as I have learned ( the hard way :) ) messing with PCLATH at one place in Your program can break havoc on other portions. Therefore to be safe set PCLATH to high($) after the call to this routine and see what happens. Read the thread in August titled 'Paging issues', also the thread 'PCLATH lowest three bits ? never changes ?' in April, which was when I had the aha ! experience ;) ( available among others at keyzer list at: http://www.infosite.com/%7Ejkeyzer/piclist/index.html ) /Tony Tony Kübek, Flintab AB ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² E-mail: spamBeGonetony.kubekspamBeGoneflintab.com ²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²²² -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:"

>> As far as I have learned ( the hard way :) ) messing with PCLATH at one place in Your program can break havoc on other portions. Therefore to be safe set PCLATH to high($) after the call to this routine and see what happens. << It helps to have a consistant strategy for dealing with PCLATH throughout your whole program. I use the following rules, which seem to work well for me: 1 - Individual modules aren't allowed to cross page boundaries. I make sure this happens automatically by creating a separate linker section for each page. There are occasional exceptions which so far have all been large data module (tables, etc.). 2 - The high bits of PCLATH are always set to the page of the current module. This means CALLs and GOTOs within a module can always be done in one instruction without setting PCLATH first. 3 - PCLATH is always set before a CALL or GOTO to a label outside the current module. 4 - PCLATH is always reset to the current address after return from an external subroutine. This method is made easier by using macros for external subroutine CALLs and GOTOs. I have GCALL (global call) for calling an external subroutine. This sets PCLATH, calls the routine, then resets PCLATH. The GJUMP macro works similarly for jumping to an external label. ***************************************************************** Olin Lathrop, embedded systems consultant in Devens Massachusetts (978) 772-3129, TakeThisOuTolinEraseMEspam_OUTcognivis.com, http://www.cognivis.com -- http://www.piclist.com hint: PICList Posts must start with ONE topic: "[PIC]:","[SX]:","[AVR]:" =uP ONLY! "[EE]:","[OT]:" =Other "[BUY]:","[AD]:" =Ads