Very strange problem with PIC16F722 and BTFSC/BTFSS not working - Page 1
Forum section: electronics / projects

author: 8086
author_rank: Super Contributor
timestamp: November 22, 2011, 08:22:21 pm
content: 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:MAINBANKSEL PORTACLRF PORTABANKSEL ANSELACLRF ANSELABANKSEL TRISAMOVLW b'00000001' ;RA0 InputMOVWF TRISASTARTBTFSCPORTA,0CALLVOL_UPBTFSSPORTA,0CALLVOL_DOWNGOTOSTARTWhen 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.

author: amspire
author_rank: Super Contributor
timestamp: November 22, 2011, 11:44:01 pm
content: It is a long time since I looked at the PIC assembler, but don't you need a colon (":") after the label names?Code:MAIN:BANKSEL PORTACLRF PORTABANKSEL ANSELACLRF ANSELABANKSEL TRISAMOVLW b'00000001' ;RA0 InputMOVWF TRISASTART:BTFSCPORTA,0CALLVOL_UPBTFSSPORTA,0CALLVOL_DOWNGOTOSTARTVOL_UP:some code .....VOL_DOWN:some code ......

author: 8086
author_rank: Super Contributor
timestamp: November 22, 2011, 11:51:41 pm
content: No, labels don't need a colon. Any other ideas?

author: vk6zgo
author_rank: Super Contributor
timestamp: November 23, 2011, 12:32:28 am
content: 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

author: baljemmett
author_rank: Unknown
timestamp: November 23, 2011, 12:33:56 am
content: Quote from: 8086 on November 22, 2011, 08:22:21 pmAre you missing a BANKSEL PORTA there?

author: 8086
author_rank: Super Contributor
timestamp: November 23, 2011, 12:46:47 am
content: Quote from: baljemmett on November 23, 2011, 12:33:56 amYou'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.Quote from: vk6zgo on November 23, 2011, 12:32:28 amI was probing the trace while the whole board was populated so the input is definitely good.

author: 8086
author_rank: Super Contributor
timestamp: November 23, 2011, 01:18:18 am
content: 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!

author: NiHaoMike
author_rank: Super Contributor
timestamp: November 23, 2011, 02:11:03 am
content: 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.

author: baljemmett
author_rank: Unknown
timestamp: November 23, 2011, 12:21:37 pm
content: Quote from: 8086 on November 23, 2011, 01:18:18 amExcellent, glad to have helped!Quote from: NiHaoMike on November 23, 2011, 02:11:03 amThat'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!)