PIC read IO pin using BTFSS not doing a thing - Page 1
Forum section: electronics / general

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 10:58:18 am
content: 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 03. Disabled WPUEN in OPTION_REG4. set WPUA RA<1:0> to 1.5. Verified there is a pull up voltage present on those pins with a DMMI 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:main00btfss PORTA, RA0call ledoncall ledoffgoto main00set up code is:Code:; set up analogue pins -----------------------------------------------------clrf ANSELA; set up digital pins ------------------------------------------------------movlw b'00000011'; RA<1:0> as key inputsmovwf TRISA; set port direction; set weak pull ups on key pins --------------------------------------------bcfOPTION_REG, 7; Clear WPUEN to allow WPU to workmovlw b'00000011'; Set pull ups on RA<1:0> key inputsmovwf WPUA; set pull-up status; set default output state -------------------------------------------------clrf PORTA; disable all bits on PORTAAny help appreciated.

author: Buriedcode
author_rank: Super Contributor
timestamp: September 12, 2018, 11:20:37 am
content: 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.

author: nfmax
author_rank: Super Contributor
timestamp: September 12, 2018, 11:24:49 am
content: TRISA&PORTAare in different banks. On a PIC, it'salwaysa banking problem

author: Buriedcode
author_rank: Super Contributor
timestamp: September 12, 2018, 11:26:11 am
content: Quote from: nfmax on September 12, 2018, 11:24:49 amIIRC the PIC10Fxxx only has one bank

author: nfmax
author_rank: Super Contributor
timestamp: September 12, 2018, 11:32:35 am
content: Quote from: Buriedcode on September 12, 2018, 11:26:11 am...except when it isn't a banking problemWhat is the value of RA0? It should be the bit number of the pin the switch is connected to.

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2018, 11:44:07 am
content: I always try to avoid doing these operations on PORTx. They should work but they never do for meI always buffer the input (maybe double buffer to be sure i'm getting the current state)Code:MOVF PORTA,WMOVF PORTA,Wand then perform the operation on the buffer

author: ggchab
author_rank: Frequent Contributor
timestamp: September 12, 2018, 11:44:58 am
content: "ledoff" always called after "ledon". So, led never stays on

author: JPortici
author_rank: Super Contributor
timestamp: September 12, 2018, 11:46:20 am
content: Quote from: ggchab on September 12, 2018, 11:44:58 amand that, tooi focused on the BTFSS...

author: Buriedcode
author_rank: Super Contributor
timestamp: September 12, 2018, 11:47:08 am
content: Quote from: ggchab on September 12, 2018, 11:44:58 amnailed it. I vaguely remember making the same mistake a couple of decades ago

author: ggchab
author_rank: Frequent Contributor
timestamp: September 12, 2018, 11:50:20 am
content: I already made the same mistake

author: Ian.M
author_rank: Super Contributor
timestamp: September 12, 2018, 11:55:55 am
content: 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.

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 12:21:05 pm
content: Thanks everyone. Solved it.The issue was ledoff was always called after ledonTold you it was a stupid error. Big thanks toggchab! Have changed it to the following and it's working:Code:main00btfss PORTA, RA1call ledonbtfsc PORTA, RA1call ledoffgoto main00I'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 meSome 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.

author: Ian.M
author_rank: Super Contributor
timestamp: September 12, 2018, 12:51:05 pm
content: 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 . . . .

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 01:03:43 pm
content: 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.

author: TomS_
author_rank: Frequent Contributor
timestamp: September 12, 2018, 01:25:57 pm
content: Quote from: bd139 on September 12, 2018, 12:21:05 pmI 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".

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 02:32:29 pm
content: Yes indeed. I’m actually technically a programmer by profession. You wouldn’t think it looking at that cock up

author: KL27x
author_rank: Super Contributor
timestamp: September 12, 2018, 08:06:56 pm
content: QuoteAt 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.

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 08:08:46 pm
content: Well this PK3 is dead now. Just blew the fucker up. That's the third one now. Bloody things are made of butter.

author: KL27x
author_rank: Super Contributor
timestamp: September 12, 2018, 08:24:01 pm
content: QuoteI 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.

author: bd139
author_rank: Super Contributor
timestamp: September 12, 2018, 09:02:48 pm
content: 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

author: JPortici
author_rank: Super Contributor
timestamp: September 13, 2018, 07:31:44 am
content: 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..

author: bd139
author_rank: Super Contributor
timestamp: September 13, 2018, 07:44:47 am
content: 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.

author: JPortici
author_rank: Super Contributor
timestamp: September 13, 2018, 07:55:32 am
content: well, open a ticket, they'll probably replace the two genuine onesbetter than nothing

author: bd139
author_rank: Super Contributor
timestamp: September 13, 2018, 08:29:33 am
content: 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.

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: September 13, 2018, 08:42:00 am
content: 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.

author: Ian.M
author_rank: Super Contributor
timestamp: September 13, 2018, 08:46:42 am
content: Here's the Microchip forum post from 2010 where a member of the Microchip PICkit 3 development team 'leaked' the PICkit 3 firmware image complete with bootloader, suitable for reflashing it by ICSP.https://www.microchip.com/forums/FindPost/481245You'll need a spare programmer that can flash a PIC24FJ256GB106 in-circuit from a Microchip format HEX file.As its a rather old firmware version, and if you use it, the Pickit 3 hardware is already suspect, its a good idea to use thePICkit3 Programmer Application and Scripting Tool v3.10*to check it can program a PIC, then use the above utility to revert the PICKIT 3 to MPLAB mode which will force a firmware update when its next connected to MPLAB.Using MPLAB 8 to debug assembler code on older PICs is still a valid strategy - it at least will show you which RAM and FLASH locations are reserved for the debug executive for your PIC when you open the memory views, and as long as you are using MPASM in relocatable code mode, should be able to load the symbol table to support symbolic debugging.On the subject of what dies due to over-voltage damage to PICkit 3 programmers see my comments inhttps://www.eevblog.com/forum/microcontrollers/pickit3-not-working/msg1008468/#msg1008468* CAUTION: this tool installs PICkit 2 emulation firmware with all that implies i.e. limited device support. You MUST *EITHER* run the menu item in the scripting tool to revert to PICkit 3 firmware *OR* hold down the button when plugging it in to USB to force bootloader mode, to return to using MPLAB 8 or X. This utility does NOT require MPLAB 8 or X to be installed.

author: jpanhalt
author_rank: Super Contributor
timestamp: September 13, 2018, 10:46:39 am
content: Back to the original question, you could also:Code:mainoobtfss PORTA,RA1bra ledon ;or gotobra ledoff ;or goto or just have your ledoff rountineledon<code>bra main00ledoff<code>bra main00That is, assuming ledon and ledoff always go to main.

author: TomS_
author_rank: Frequent Contributor
timestamp: September 13, 2018, 10:50:27 am
content: Quote from: JPortici on September 13, 2018, 07:55:32 amWhen I logged a fault for my PK3 which died they said I should buy an ICD3 instead.I thought that was a little bit of a cop out, but I did end up buying one and essentially havent looked back. Way more reliable and far fewer issues than I was having with the PK3.ICD3 does still have a few issues and I need to unplug and re-plug USB every so often, but no where near as frequently as I used to have to do with PK3, which could sometimes be every single time I needed to program a device. ICD3 I can sometimes get a week or so before needing to unplug it, and other times may need to do it a couple of times before it stops playing up.

author: jpanhalt
author_rank: Super Contributor
timestamp: September 13, 2018, 11:34:13 am
content: I had basically the same experience as TomS_My PK3 had early death and Microchip replaced if for free. The few Times I have used it over the years it has been fine, but I always power the target separately. In the process of the exchange Microchip offered a good discount on the ICD3, and it has been my goto since. I can usually power from the ICD3 unless some power hog is on the board, like an LCD backlight.

author: cv007
author_rank: Frequent Contributor
timestamp: September 13, 2018, 11:59:17 am
content: QuoteI think the firmware is inside the PICKIT3.jar file in mplabx.

author: Ian.M
author_rank: Super Contributor
timestamp: September 13, 2018, 12:22:46 pm
content: I don't know about the current MPLAB X version, but historically, the firmwares MPLAB X downloads to the PICkit 3 to support different PIC families, and the base PICkit 3 firmware it uses to upgrade old versions, didn't include the bootloader which made them useless for recovering a bricked PICkit 3 using an external programmer.If that's no longer the case, it would help the community if someone familiar with the current MPLAB X would write out a cheat-sheet for locating the firmware + bootloader and re-flashing the PICkit 3 PIC24FJ256GB106.

author: TomS_
author_rank: Frequent Contributor
timestamp: September 13, 2018, 12:35:45 pm
content: Quote from: jpanhalt on September 13, 2018, 11:34:13 amthey didnt offer me any discount.

author: Ian.M
author_rank: Super Contributor
timestamp: September 13, 2018, 12:42:30 pm
content: That depends on whether or not they've got a current trade-in offer on devtools. They usually run one when they want to obsolete a devtool, I *guess* to move as many as possible paying customers to current tools to minimise their support burden. Previously some of the offers have been good enough that its been worth acquiring a PICkit series programmer to trade in and take advantage of the offer on an ICD series one.

author: cv007
author_rank: Frequent Contributor
timestamp: September 13, 2018, 02:21:44 pm
content: QuoteLooks like probably still true. I scanned the hex files for a data record with an address of 0000- didn't find any. Looks like the scripting tool download is still needed. My bad.