Very strange problem with PIC16F722 and BTFSC/BTFSS not working

[8086]

I'm really confused.

I have an LDR circuit that generates ~0.1v when dark, and ~2.9v when light (this is a 3.3v circuit). These levels have been verified with an oscilloscope and there is very little noise.

The output from this circuit goes directly to RA0 on a PIC16F722.

I have the following code:

Code: [Select]

MAIN
BANKSEL PORTA
CLRF PORTA
BANKSEL ANSELA
CLRF ANSELA
BANKSEL TRISA
MOVLW b'00000001' ;RA0 Input
MOVWF TRISA

START

BTFSC PORTA,0
CALL VOL_UP
BTFSS PORTA,0
CALL VOL_DOWN
GOTO START
When I debug with my Pickit 3,  can see in the watch that the input is valid, but the code doesn't call the subroutines. In fact the code doesn't seem to do anything whatever the input is!

Can anyone shed some light on this? I'm totally confused by it.

[amspire]

It is a long time since I looked at the PIC assembler, but don't you need a colon (":") after the label names?

Code: [Select]

MAIN:
BANKSEL PORTA
CLRF PORTA
BANKSEL ANSELA
CLRF ANSELA
BANKSEL TRISA
MOVLW b'00000001' ;RA0 Input
MOVWF TRISA

START:

BTFSC PORTA,0
CALL VOL_UP
BTFSS PORTA,0
CALL VOL_DOWN
GOTO START

VOL_UP:
       some code .....

VOL_DOWN:
       some code ......


[8086]

No, labels don't need a colon. Any other ideas?

[vk6zgo]

I'm an analog person,not a PIC person,but I have three questions:

Did you measure the LDR circuit voltages with it connected to the RA0 input to the PIC,or just standalone?

Have you tried a logic signal from some source other than the LDR?

Have you tried configuring another R port as an input?
( I vaguely remember an article in a mag where they had a similar problem,so they changed to another input & all was well).

VK6ZGO

[baljemmett]

Code: [Select]

MOVWF TRISA

START

BTFSC PORTA,0

When I debug with my Pickit 3,  can see in the watch that the input is valid, but the code doesn't call the subroutines. In fact the code doesn't seem to do anything whatever the input is!

Are you missing a BANKSEL PORTA there?

[8086]

Code: [Select]

MOVWF TRISA

START

BTFSC PORTA,0

When I debug with my Pickit 3,  can see in the watch that the input is valid, but the code doesn't call the subroutines. In fact the code doesn't seem to do anything whatever the input is!

Are you missing a BANKSEL PORTA there?

You're right! This could be it. I can't try it till later, but that would probably explain it. I would have set RP0 and RP1 manually as I don't usually use banksel but I just copied the init routine from the datasheet. That's what I get for being lazy. 

I'm an analog person,not a PIC person,but I have three questions:

Did you measure the LDR circuit voltages with it connected to the RA0 input to the PIC,or just standalone?

Have you tried a logic signal from some source other than the LDR?

Have you tried configuring another R port as an input?
( I vaguely remember an article in a mag where they had a similar problem,so they changed to another input & all was well).

VK6ZGO

I was probing the trace while the whole board was populated so the input is definitely good.

[8086]

I just tried baljemmett's solution, and now it works perfectly. Thanks to you.

It also explains my previous thread about why my output was behaving as if it was open drain. I was actually setting the pin as an input when I thought I was setting it high, and as an output when I thought I was setting it low. So the high-z state of the input plus the pull-up resistors, and the pulling low when set as an output, combined to make it look like the output was working.

D'oh!

[NiHaoMike]

Setting pins as inputs is actually a trick to emulate open drain logic. So it was working as intended.

I'm surprised the assembler doesn't try to keep track and issue warnings if there might be a register access outside of the current bank. In a convoluted program with "grasshopper" execution flow, it's very easy to miss a path.

[baljemmett]

I just tried baljemmett's solution, and now it works perfectly. Thanks to you.

Excellent, glad to have helped! 

I'm surprised the assembler doesn't try to keep track and issue warnings if there might be a register access outside of the current bank. In a convoluted program with "grasshopper" execution flow, it's very easy to miss a path.

That's probably why it doesn't try to keep track.  It wouldn't be too tricky to, say, keep track of which bank selection bits are definitely known before a goto or call drops you elsewhere in the code -- but then trying to work out where the PC will end up after a write to PCLATH/PCL could be a lot harder, for instance.  So it might end up just deciding it has no idea at all what the bank selection bits might be at any given point and issuing a "access to register outside bank 0, ensure selection bits are correct" warning -- which is, from memory, what the Microchip assembler does by default!

(NB: that warning is rather pointless as it doesn't account for the possibility that the bank selection bits are set for one of the other banks when you access a register in bank 0.  Which is exactly what was happening here, of course!)