Post by thread:[PIC] Weird GPIO-problem on a PIC12F683

I've built a small cable-tester. In a loop, I have these lines: movlw b'00000001' ; run cable test on GP0 movwf GPIO call delay_500ms movlw b'00000010' ; run cable test on GP1 movwf GPIO call delay_500ms movlw b'00000100' ; run cable test on GP2 movwf GPIO call delay_500ms movlw b'00010000' ; run cable test on GP4 movwf GPIO call delay_500ms movlw b'00100000' ; run cable test on GP5 movwf GPIO call delay_500ms Each of the corresponding GPs are connected to an LED and an (external) AND-gate. The problem is, none of the LEDs are being lit when using the above code. Even more weird, if I insert this piece of test-code (light all LEDs): movlw -1 movwf GPIO call delay_500ms clrf GPIO call delay_500ms between the GP0/GP1 tests above, all LEDs are being lit. Step-debugging in MPLAB and watching the GPIO, I clearly see "00000001", "00000010" etc in GPIO for the various tests, but none of them are being lit. I also tried this: movlw b'11111100' movwf GPIO call delay_500ms Then the LEDs are instantly flashing (for like 0.1 ms, just barely noticeable) before turned off. I've been scratching my head for a couple of hours now, double-checking the datasheets but I just can't see what's wrong. It works for all the LEDs at the same time, but not one at a time. Can anyone explain what's happening? Could it be a RMW-problem? I can't think of anything right now. -- - Rikard - http://bos.hack.org/cv/

Rikard, Did you clear the ANSEL register? All the A/D pins default to analog mode on reset. Bill Rikard Bosnjakovic wrote: {Quote hidden}>I've built a small cable-tester. In a loop, I have these lines: > > movlw b'00000001' ; run cable test on GP0 > movwf GPIO > call delay_500ms > > movlw b'00000010' ; run cable test on GP1 > movwf GPIO > call delay_500ms > > movlw b'00000100' ; run cable test on GP2 > movwf GPIO > call delay_500ms > > movlw b'00010000' ; run cable test on GP4 > movwf GPIO > call delay_500ms > > movlw b'00100000' ; run cable test on GP5 > movwf GPIO > call delay_500ms > >Each of the corresponding GPs are connected to an LED and an >(external) AND-gate. The problem is, none of the LEDs are being lit >when using the above code. > >Even more weird, if I insert this piece of test-code (light all LEDs): > > movlw -1 > movwf GPIO > call delay_500ms > clrf GPIO > call delay_500ms > >between the GP0/GP1 tests above, all LEDs are being lit. >Step-debugging in MPLAB and watching the GPIO, I clearly see >"00000001", "00000010" etc in GPIO for the various tests, but none of >them are being lit. > >I also tried this: > > movlw b'11111100' > movwf GPIO > call delay_500ms > >Then the LEDs are instantly flashing (for like 0.1 ms, just barely >noticeable) before turned off. > >I've been scratching my head for a couple of hours now, >double-checking the datasheets but I just can't see what's wrong. It >works for all the LEDs at the same time, but not one at a time. > >Can anyone explain what's happening? Could it be a RMW-problem? I >can't think of anything right now. > > > >

If the external AND gate has one GPIO connected to each input, and assuming it's a 6 input AND gate, ALL pins would have to be HIGH for the output to go HIGH. If there are any unused inputs on the AND gate, ie an 8 input AND gate, pull each of them HIGH with a 10K or so ohm resistor. The reason it works for the case of writing -1 is that this makes the PORT take the value of '255', or all pins HIGH (0-1=255). Try using an OR gate in place of the AND gate, and see if that works. Regards, Jim {Quote hidden}> I've built a small cable-tester. In a loop, I have these lines: > > movlw b'00000001' ; run cable test on GP0 > movwf GPIO > call delay_500ms > > movlw b'00000010' ; run cable test on GP1 > movwf GPIO > call delay_500ms > > movlw b'00000100' ; run cable test on GP2 > movwf GPIO > call delay_500ms > > movlw b'00010000' ; run cable test on GP4 > movwf GPIO > call delay_500ms > > movlw b'00100000' ; run cable test on GP5 > movwf GPIO > call delay_500ms > > Each of the corresponding GPs are connected to an LED and an > (external) AND-gate. The problem is, none of the LEDs are being lit > when using the above code. > > Even more weird, if I insert this piece of test-code (light all LEDs): > > movlw -1 > movwf GPIO > call delay_500ms > clrf GPIO > call delay_500ms > > between the GP0/GP1 tests above, all LEDs are being lit. > Step-debugging in MPLAB and watching the GPIO, I clearly see > "00000001", "00000010" etc in GPIO for the various tests, but none of > them are being lit. > > I also tried this: > > movlw b'11111100' > movwf GPIO > call delay_500ms > > Then the LEDs are instantly flashing (for like 0.1 ms, just barely > noticeable) before turned off. > > I've been scratching my head for a couple of hours now, > double-checking the datasheets but I just can't see what's wrong. It > works for all the LEDs at the same time, but not one at a time. > > Can anyone explain what's happening? Could it be a RMW-problem? I > can't think of anything right now. > > > -- > - Rikard - http://bos.hack.org/cv/ > --

On 6/14/07, spam_OUTjamespTakeThisOuTintertex.net <.....jamespKILLspam@spam@intertex.net> wrote: > If the external AND gate has one GPIO connected to each input, and > assuming it's a 6 input AND gate, ALL pins would have to be HIGH for > the output to go HIGH. If there are any unused inputs on the AND gate, > ie an 8 input AND gate, pull each of them HIGH with a 10K or so ohm > resistor. That makes sense. However, each GPIO goes to one AND-input (and one red LED) each, and from the same input it goes through the cable in question to test, and the opposite end of the cable goes to the second AND-input. The AND-output goes to a green LED. This means as soon as one GPIO goes high, one AND-input and one red LED goes high, and if the cable is functional, the other end makes the second AND-input high, making the output high, making the green LED lit. I'm not sure if I'm making sense, but I hope so. -- - Rikard - http://bos.hack.org/cv/

> However, each GPIO goes to one AND-input (and one red LED) each, and > from the same input it goes through the cable in question to test, and > the opposite end of the cable goes to the second AND-input. The > AND-output goes to a green LED. > > This means as soon as one GPIO goes high, one AND-input and one red > LED goes high, and if the cable is functional, the other end makes the > second AND-input high, making the output high, making the green LED > lit. > > I'm not sure if I'm making sense, but I hope so. The design looks fine to me. Do add pull-down resistors to the second AND inputs though, if you haven't already. My suggestion: whip out a multimeter (or just hotwire some LEDs) and test the PIC outputs. You might have miswired the AND gates, or maybe the chip is defective, or the wire to test is wired wrong (in which case your tester seems to be working perfectly). Testing the midpoint (the PIC outputs) will allow you to rule your program out, if it's not the problem. With the behavior you described, it might be that the cable-to-test is miswired. If there are no pull-downs on the AND gate inputs, you can get all sorts of funky behavior due to varying charge on the FET gates when inputs are floating (especially if a long but unterminated wire is connected). Once you do add pull-downs, if the behavior persists, it might be the test wire is just connected improperly, or the AND gates are (assuming the PIC tests out fine as above). If the PIC doesn't put out the proper states, then either there's someone competing with it (e.g. the AND gate outputs are wired to the PIC outputs), or there's a code problem (As others have mentioned, check analog mode. Doublecheck TRIS too.) -- Hector Martin (hectorKILLspammarcansoft.com) Public Key: http://www.marcansoft.com/marcan.asc

On 6/15/07, Hector Martin <.....hectorKILLspam.....marcansoft.com> wrote: > With the behavior you described, it might be that the cable-to-test is > miswired. If there are no pull-downs on the AND gate inputs, you can get > all sorts of funky behavior due to varying charge on the FET gates when > inputs are floating (especially if a long but unterminated wire is > connected). Once you do add pull-downs, if the behavior persists, it > might be the test wire is just connected improperly, or the AND gates > are (assuming the PIC tests out fine as above). If the PIC doesn't put > out the proper states, then either there's someone competing with it > (e.g. the AND gate outputs are wired to the PIC outputs), or there's a > code problem (As others have mentioned, check analog mode. Doublecheck > TRIS too.) I forgot to say that when I tested the code the cable-to-test was not plugged in, because I was only tracking down the error as to why the red LEDs did not lit. I've double checked the TRIS and ANSEL and I can't find any errors. Also, the datasheet says that when the GPIO is configured as output, ANSEL has no effect even if it's set. I wrote an ugly test-loop writes the numbers 1..255 to GPIO, just for the sake of testing and see what happens. No test-cable was plugged in, and the LEDs did get lit. But not in the way you would expect (binary look-a-likes), but rather "the higher the number, the more the intensity". All five red LEDs got lit at the same time, and the green as well. So, this cannot be a code problem, since I've step-debugged the code flawlessly and it works perfectly within MPLAB. The reason must be that I have messed up big time in the external circuitory. Somewhere. I have the tester working in another (non-PIC) version[1], and this one was supposed to replace it. Somehow I thought that I could boast to myself saying that I don't need any stinking schematics since I've already constructed the "same" circuit earlier, 2 years ago. I will put this protoboard in the trashcan and start over, and this time I *will* make a schematic for it. Thanks for the input. [1] http://bos.hack.org/hacks/x1541-testare/ -- - Rikard - http://bos.hack.org/cv/

Rikard Bosnjakovic wrote: > I have the tester working in another (non-PIC) version[1], and this one > was supposed to replace it. Somehow I thought that I could boast to > myself saying that I don't need any stinking schematics since I've > already constructed the "same" circuit earlier, 2 years ago. I will put > this protoboard in the trashcan and start over, and this time I *will* > make a schematic for it. Ah, here is the bug :) At least, if you don't see it immediately when you draw it, a schematic helps other people help you. Gerhard

On 6/15/07, Gerhard Fiedler <EraseMElistsspam_OUTTakeThisOuTconnectionbrazil.com> wrote: > At least, if you don't see it immediately when you draw it, a schematic > helps other people help you. True that. I didn't do that for the complex poker clock - which happened to be my first PIC-construction, by the way - some month ago, and I'm still astonished I managed to get it to work. But I guess it was a one-shot luck, because this real small project screwed up big time. Good thing is that you (usually) learn by the mistakes. In this case, I need to make it a routine to draw schematics for every circuit before actually building it. Thanks. -- - Rikard - http://bos.hack.org/cv/

> Good thing is that you (usually) learn by the mistakes. Even in poker I hope ? :-) Jan-Erik. Rikard Bosnjakovic wrote: {Quote hidden}> On 6/15/07, Gerhard Fiedler <listsspam_OUTconnectionbrazil.com> wrote: > >> At least, if you don't see it immediately when you draw it, a schematic >> helps other people help you. > > True that. > > I didn't do that for the complex poker clock - which happened to be my > first PIC-construction, by the way - some month ago, and I'm still > astonished I managed to get it to work. But I guess it was a one-shot > luck, because this real small project screwed up big time. > > Good thing is that you (usually) learn by the mistakes. In this case, > I need to make it a routine to draw schematics for every circuit > before actually building it. > > Thanks. > >