RMW Problem?

[jpanhalt]

I am driving the Vdd for my GLCD with a pin on my PIC16F1519 at 5V and switching Vee (Vo) with another pin. Both pins are PortE, which also has MCLR on it. I go through a start-up sequence and shut-down sequence for Vdd and Vee (Vo).

Without the GLCD attached, the switching works perfectly. With the GLCD attached (PortB for data; PortD for controls), the sequence works fine at start-up. At shut down, Vdd hangs at approvimately 2.88V and Vo goes slightly positive. An indicator LED on RD1 (PortD,1) works as expected. I have tried PortA for the pins, with similar results, except at shut down there was a lot of noise on the Vdd line. PortE is Schmitt trigger; PortA is not. The GLCD "program" is just the initialization routine from Pommie. If I reset with MCLR, everything works just as I wanted.

Here is the code for turn-off:

Turn_OFF	
	BCF		b_Toggle
	BCF		b_ON_OFF			;clear ON flag	
	BSF		b_LCD_Vo			;turn off MAX851_high = off	
	DelayCy	(100*msecs)		;wait for Vo to rise
	DelayCy	(100*msecs)		;366mS needed at -4.139V
	DelayCy	(100*msecs)
	DelayCy	(100*msecs)	
	BCF		b_LCD_VDD			;turn off display VDD
	BCF		b_LED			;turn off indicator LED, safe to disconnect
	banksel	latE
	movlw	0x09
	movwf	latE
	movlb	0x00
	GOTO		LCD_Power			;

The manipulation to LatE was added to avoid read-modify-write problems. I also tried doing a corresponding move instruction with PortE. Those failed attempts were based on a short article by Michael Rigby-Jones on PicList. Basically, his message is that "mov" instructions do not go through the read-modify-right sequence.

What puzzles me most is the 2.88V seen on the Vdd after shutdown. That voltage was measured with an oscilloscope and is steady. My next step is to add a P-mosfet switch between the MCU pin for Vdd and the GLCD.

BTW, movlb is a new instruction to switch banks in the enhanced mid-range series.

Regards,

John

 

[Mike - K8LH]

Hi John,

Is there a chance the GLCD can be getting parasitic power from the data lines? Are you taking all of the data lines to '0' before the turn off sequence?

Regards, Mike

 

[jpanhalt]

That was one of my thoughts -- I needed something to explain the 1/2Vdd . I think they are low, but I am just now playing with some changes that will assure that.

John

 

[jpanhalt]

My changes did a lot. I forced PortB with clrf TrisB, clrf PortB at the very beginning of the turn off sequence. The "residual" voltage is now down to 1 volt and Vee is almost zero.

A little more hunting and a few bandaids should fix it. I may try using "mov" to rule out an RMW issue. If it is parasitic voltage on the pins, that would certainly be a "usual suspect" for causing that sort of problem.

I will give an update.

John

UPDATE: Problem is solved. Cleared out PortD the same way and voltage is now zero. I am assuming CLRF is not a RMW instruction. Edit: confirmed in Microchip document.

I understood the LCD is like a capacitor, so I had tried a pull-down resistor earlier today without success. It is another lesson.

Thanks for the help.

John

 

[Mike - K8LH]

I'm happy to hear you worked it out, John.

May I ask at what speed are you running the 16F1519? It affects the limits of your DelayCy() subsystem. For example, if you're running the 16F1519 at 16-MHz, the 327690 cycle upper delay limit for the (5 cycle loop) subsystem translates to a maximum delay of about 81 msecs. If needed, the DelayCy() subsystem variation below can provide much longer delays.

Regards, Mike

;******************************************************************
;
;  DelayCy() clock equate and delay operand multipliers
;
        radix   dec
clock   equ     4               ; clock frequency in Megahertz
usecs   equ     clock/4         ; cycles/microsecond multiplier
msecs   equ     usecs*1000      ; cycles/millisecond multiplier
;
;  5 cycle loop delay range 11..327690 cycles
;  6 cycle loop delay range 11..393226 cycles
;  7 cycle loop delay range 11..458762 cycles
;  8 cycle loop delay range 11..524298 cycles
;
loop    equ     8               ; select 5 to 8 cycle loop timing
;
;  K8LH DelayCy() macro generates four instructions for every
;  (loop * 65536 + 10) cycles in the delay.
;
DelayCy macro   delay           ; minimum 11 cycles
        local   cycles
        cycles = delay
    while cycles > (loop*65536+10)
        movlw   high((loop*65536-11)/loop)+1
        movwf   DelayHi
        movlw   low ((loop*65536-11)/loop)
        call    uDelay-((65536-11)%loop)
        cycles -= (loop*65536)
    endw
        movlw   high((cycles-11)/loop)+1
        movwf   DelayHi
        movlw   low ((cycles-11)/loop)
        call    uDelay-((cycles-11)%loop)
        endm

;******************************************************************
;  example code for simulation testing.
;
SimTest	DelayCy(500*msecs)	; <- put simulator PC here
	nop			; <- put simulator break point here

;******************************************************************
;  16 bit uDelay subroutine with adjustable 5..8 cycle loop time
;
	nop			; entry for (delay-11)%loop == 7  |B0
	nop			; entry for (delay-11)%loop == 6  |B0
	nop			; entry for (delay-11)%loop == 5  |B0
	nop			; entry for (delay-11)%loop == 4  |B0
	nop			; entry for (delay-11)%loop == 3  |B0
	nop			; entry for (delay-11)%loop == 2  |B0
	nop			; entry for (delay-11)%loop == 1  |B0
uDelay	addlw	-1		; subtract "loop" cycle time	  |B0
	skpc			; borrow? no, skip, else	  |B0
	decfsz	DelayHi,F	; done?  yes, skip, else	  |B0
	goto	uDelay+5-loop	; do another loop		  |B0
	return			;				  |B0
;

 

[jpanhalt]

I am running at 8 MHz, as I understand the real bottleneck is the GLCD, and 100 mS at that speed has not been a problem. I don't anticipate needing many delays in excess of that.

Right now, I am doing it X4 to allow the Vee to decay completely before stopping Vdd -- it takes 366 mS. That is a bit of over caution based on communication with New Haven Displays, my display vendor. I will either keep that, use a negative-voltage switch, or just ignore it once everything is up an running.

Things move slowly in my household. I spent a lot of time just trying to understand that chip and the display code I got from Pommie. The PK3 works well with the chip -- another learning curve. I thought it was going to be complicated, but it is as easy as my PicStart Plus to use, once you recognize the need to set the voltage source.

John