PIC read IO pin using BTFSS not doing a thing

[bd139]

Banging my head on something for an hour now. Any help appreciated. I've got a PIC10F320 set up to replace a few complex and over-priced discrete logic ICs in a design. This has two switches attached to it and an LED at the moment. Both the switches are momentary and are connected to RA<1:0>. LED is connected to RA2. Before I dig too deep into replicating the logic, which is going to be replicated with a ladder logic type main loop, I wanted to check the pin read/write was working so am adding some glue code to turn the LED on and off with the switch state.

Unfortunately bugger all is happening.

As part of the set up I have:

1. cleared ANSEL.
2. set TRISA RA<1:0> to 1 and RA2 to 0
3. Disabled WPUEN in OPTION_REG
4. set WPUA RA<1:0> to 1.
5. Verified there is a pull up voltage present on those pins with a DMM

I wrote a little loop with delay to flash the LED. That works fine.

However if I do this, nothing happens. Have I missed something? Am I doing something stupid?

Code: [Select]

main00
    btfss   PORTA, RA0
    call    ledon
    call    ledoff
    goto main00
set up code is:

Code: [Select]

    ; set up analogue pins -----------------------------------------------------
    clrf    ANSELA
    ; set up digital pins ------------------------------------------------------
    movlw   b'00000011' ; RA<1:0> as key inputs
    movwf   TRISA ; set port direction
    ; set weak pull ups on key pins --------------------------------------------
    bcf     OPTION_REG, 7 ; Clear WPUEN to allow WPU to work
    movlw   b'00000011' ; Set pull ups on RA<1:0> key inputs
    movwf   WPUA ; set pull-up status
    ; set default output state -------------------------------------------------
    clrf    PORTA ; disable all bits on PORTA

Any help appreciated.

[Buriedcode]

As a check on the internal oscillator, maybe first try just to blink an LED. I realise your current prog is already fairly simple, but it's still worth the 3 minutes to check.

[nfmax]

TRISA & PORTA are in different banks. On a PIC, it's always a banking problem

[Buriedcode]

TRISA & PORTA are in different banks. On a PIC, it's always a banking problem

IIRC the PIC10Fxxx only has one bank

[nfmax]

TRISA & PORTA are in different banks. On a PIC, it's always a banking problem

IIRC the PIC10Fxxx only has one bank

...except when it isn't a banking problem 
What is the value of RA0? It should be the bit number of the pin the switch is connected to.

[JPortici]

I always try to avoid doing these operations on PORTx.  They should work but they never do for me
I always buffer the input (maybe double buffer to be sure i'm getting the current state)

Code: [Select]

MOVF PORTA,W
MOVF PORTA,Wand then perform the operation on the buffer

[ggchab]

"ledoff" always called after "ledon". So, led never stays on

[JPortici]

"ledoff" always called after "ledon". So, led never stays on

and that, too i focused on the BTFSS...

[Buriedcode]

"ledoff" always called after "ledon". So, led never stays on

nailed it.  I vaguely remember making the same mistake a couple of decades ago

[ggchab]

I already made the same mistake 

[Ian.M]

I think BD139 has already eliminated this by checking the actual input pin voltages with a DMM, but there's another trap for the unwary (especially anyone playing along at home on a Microchip demo board powered from their PICkit 3).

Disconnect the programmer!

Most Microchip programmer/debuggers have pulldowns on ICSPDAT and ICSPCLK (typ. 4.7K), which are pins RA0 and RA1 on a PIC10F320.   Weak pullups  are implemented as low current saturated MOSFETs with a saturation current of between 25uA and 300uA, between the I/O pin and Vdd, which gives you at best 1.4V (and more probably <1V) at the pin when driving a 4.7K load so if you don't disconnect the programmer, the pin will almost certainly permanently read low.

[bd139]

Thanks everyone. Solved it.

The issue was ledoff was always called after ledon 

Told you it was a stupid error. Big thanks to ggchab!  Have changed it to the following and it's working:

Code: [Select]

main00
    btfss   PORTA, RA1
    call    ledon
    btfsc   PORTA, RA1
    call    ledoff
    goto main00

I'm going to replace this with pin change interrupts later which I've done a hundred times before. Just the simple stupid cases always elude me

Some replies to other posts:

1. Programmer was disconnected. I noticed that if the programmer was still connected, it knocked the pull-ups to 500mV anyway. This is really inconvenient but that's the price of using a really small PIC.
2. Internal osc is fine. I already did a simple LED flasher as mentioned in the original post. This also pointed out the WDT was enabled as it wasn't flashing consistently pointing to a reset.
3. TRISA is in bank 0. There's only bank 0 on this tiny little PIC.

Edit: I might actually be lazy here and use a 16F628A as a target then backport it to the 10F320. The pull ups on the pins mean I have a physical step in the debug/fix cycle which is annoying.

[Ian.M]

When dealing with low pin count PICs, an extender cable for the ICSP connector with an inline DPST switch to isolate ICSPDAT and ICSPCLK is very useful.

The 4.7K pulldowns are required for debug mode (for PICs that support that).  When Microchip introduced the PICkit 2, it didn't have them (black button model) then, instead of making them a requirement for the target, they modded the design to include them (red button model), and ever since (as they added them to newer programmer/debugger designs), using the ICSP pins for input on a PIC connected to a programmer/debugger has been problematic.   I believe the PICkit 4 hardware has the option to turn the pulldowns off, but I don't know if MPLAB supports that yet.   Historically, its usually taken the MPLAB team over a year to fully support the capabilities of new debugger hardware . . .. . .

Personally, I'd look at PIC12F1xxx parts - the physical size of the DFN packaged ones isn't much larger than the PIC10F32x devices and the extra two pins so you can dedicate the ICSP pins avoid a lot of trouble.  If you go for a PIC12F1501,, the chances are that you can use its two CLC modules to implement much or all of your logic function in hardware . . . .

[bd139]

That's a good idea with the extender cable. I'm currently using a carrier board and breadboard for this prototype so it's easy enough to chuck one inline.

Thanks for the info. That clears up some debug stuff nicely. Also brings me round to actually getting this code working on a 16f628A might be easier as I can use the debugger with that without pin allocation problems. If I had the debugger available I could have stepped through this one!  I'll wrap anything device / platform specific in subroutines.

[TomS_]

Thanks everyone. Solved it.

The issue was ledoff was always called after ledon 

I think one of the best quotes I have ever read when it came to writing code was something along the lines of: "the machine follows your instructions, not your intentions". 

[bd139]

Yes indeed. I’m actually technically a programmer by profession. You wouldn’t think it looking at that cock up 

[KL27x]

When dealing with low pin count PICs, an extender cable for the ICSP connector with an inline DPST switch to isolate ICSPDAT and ICSPCLK is very useful.

At one point I did a lot of work with small pin count devices with PK2. I did a mod to my dev PK2, but it was internal and automatic. 2x SSR which closed only when high voltage detected on the MCLR line. I used a zener and a resistor to detect high/Vpp voltage, and a micro would then energize/close the SSRs. When high voltage was no longer detected for some discrete amount of time (say on order of like 50mS) the SSRs would turn back off/open.
Externally, I routed out a couple wires to a tiny piece of PCB soldered to the case as a solder jumper manual override, to make it work like default PK2. In case you wanted to use debugger or manual/automatic OSCCAL restore feature or the logic analyzer thing.

[bd139]

Well this PK3 is dead now. Just blew the fucker up. That's the third one now. Bloody things are made of butter.

[KL27x]

That's the third one now.

I have read sometimes they can die due to firmware corruption and can be restored by reflashing. I've done it (out of desperation; it in fact turned out to be a different problem), so I know the complete firmware image is out there, somewhere. It's also on my computer, somewhere; if you want it I can probably find it. FWIW, I have several PK3 and all are working fine.... other than the Sure Electronics clone which never worked.

I want to say: hold the button down while plugging it into the USB port and with the software open. It might do something.

I also want to say, if you are programming in assembly, there is no use of a debugger. The PK3 has pretty much zero advantage over the PK2 unless you need PK3 for device compatability or high speed debugger. So... if i were you, I'd also have/obtain a PK2. Sometimes it's just as good or better. It can save you countless hours of waiting and rebooting and clicking on dialog boxes. Some people have zero issues with the PK3, but if you're on your third one, you are not one of them. The only advantage of using PK3 for programming a 10F in assembly would be if you're using MPLAB X and want the thing to automatically program when you recompile/assemble. So you will end up with a couple extra mouseclicks or keyboard strokes, in that case. (Someone may point out you can setup PK2 software to automatically program when it detects a change in HEX; but IME this is buggy. It works fine until your code fails to compile/assemble... in which case you have to set it up, again. And when writing new code, you are going to have that happen pretty much nonstop.)

Well, for the really old baseline stuff, which your PIC is not, the PK3 can also program faster because the PK2 redundantly writes all empty code due to stupid way it handles the old osccal value, which is in the last spot of programming memory in these super old chips.

[bd139]

Not sure what has happened with this one. It isn't even lighting up now. Have tried it on another PC to see if the USB port has died but nope completely dead. No sign of any damage at all. Yes have discovered you can't debug MPASM now as well.

Alas I've wasted enough time and money on this one so back to AVR and the luxuries of avr-gcc and avr-libc.

Thanks for everyone's help 

[JPortici]

How did that happen?
If it's firmware corruption open the thing and reflash its firmware.. but that should happen only with cheap clones these days (no idea why but my old clone would need a reflash so very often, my genuine and all those at the office never had this issue)

MPASM can't debug? really? well, actually to debug this one you need to use the external debug header, chip is dirt cheap for a reason..

[bd139]

Not sure to be honest. It died mid program cycle. Same as the last two. I’ve literally got two switches and an LED wired up on the target and am powering from the programmer a whole 8mA.

This is my third pickit3. I killed two genuine microchip ones. decided to stop paying through the nose and this is a clone one. I compared the two and they are basically identical. Identical failure mode. This is simply a flawed design if you ask me. Failure mode was the same on the other two.

I have used PICs on and off for about 20 years. Can’t be arsed with this any more.

[JPortici]

well, open a ticket, they'll probably replace the two genuine ones better than nothing

[bd139]

It takes soooooo long for them to do that. Two weeks with the first one.

I'll hit: USBasp + AVR + AVR-gcc + AVR-libc. I can afford to have a few USPasp's around for £2.50 a go and the toolchain isn't shit.

Wrote the code for this already and am 90% confident it'll work out of the box.

[mikeselectricstuff]

Re. Pickit failures - I recently looked at my dead pile.
Although the PCD/PGC pins are fairly well protected by polyfuses and zeners, the Vcc sense has no protection other than series Rs on the supply to the level shifters, so an overvoltage on this will kill the level shifters and also something else That I've not yet been bothered to track down.
I now always put a chunky 5.1V zener on the Vcc sense pin inside the case.
As clones  are about a tenner on ebay it's not worth spending much time fixing them - just keep a spare.