Today 16:00
Forum: Timer Modules
Starter: See_Mos
Views: 0
Replies: 0
Today 14:22
Forum: The Lounge
Starter: craig
Views: 0
Replies: 22
Go to last post By: See_Mos
Yesterday 19:23
Forum: Absolute Beginners Section
Starter: amod
Views: 0
Replies: 29
+ Reply to Thread
Results 1 to 8 of 8

Thread: Mysterious PORTB problem4 days old

  1. #1
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    130
    Thumbs Up
    Received: 1
    Given: 6
    Total Downloaded
    279.64 MB

    0 Not allowed!

    Default Mysterious PORTB problem

    I'm using Proton+ to develop firmware for a product with switches. The MCU is an 18F26K22. Most of the switches reside on PORTB. I am NOT using a PORTB interrupt on change, but I am checking the port for changes about 10000 times per second(25uS with delays up to 10mS when writing to the OLED). There are other interrupts happening, a Timer, and a UART which, when receiving DMX interrupts are happening every every 60uS.

    There is a ON -OFF -ON switch and three buttons. Two of the buttons are on RB6 and RB7 the ON-OFF-ON is on RB1 and RB2. Other switches are on RB3 and RB4 but they do nothing in this version of software.

    Something happens where suddenly pins RB0-RB4 stop reading, so the ON-OFF-ON doesn't work. It takes 2-5 min of constantly pressing buttons before the FREEZE happens. RB6 and RB7 respond normally, the OLED responds according, and the state machine loop still works. The UART interrupts don't seem to, but its hard to tell what is happening inside the memory of the MCU.

    The Freeze is kind of random. Sometimes only one pin returns on 0, usually the one already = 0 sometime all 5 pins return 0 RB6 and RB7 never do. Once the condition occurs, nothing I have yet tried seems to return the port to normal operation. I've read about an interrupt on change bug in all 18Fxxxx chips, that explains the PBADEN Config bit reset PORTB RB0-RB4 to either analog or digital on Brown out, and RB6 and RB7 are the programming pins. So, clearly the internal circuitry is different.

    I use hardware de-bouncing I use the WPUB pull up pins, plus an external pull up of 10k with a 1k resistor and a 1uF cap. Electronically, this give me a 2-3mS change on rise and 8ms change on fall, so, there'd have to be a LOT of noise to create a situation where this was a problem. In any event, I read the port twice seperating the read with a delayUS of 10 to 987 and compare the two read, if they're the same, they proceed. If they're different, they wait for another time period, and try again. After 255 tries for a match, they exit back to the state machine.

    I've tried modifying the code every way I can think of without any noticable improvement. But that's hard to tell, because it usually takes so long after reset to make it happen again. Any suggestions would be appreciated.

    This is the current code

    PortBswCheck = 1
    GetSw_Read:GIE = False
    GIE = False

    Nop
    Movf PORTB,0,0
    Nop
    OldPORTBstate = WREG

    GIE = True


    DelayUS 10


    GIE = False
    GIE = False
    Nop
    Movf PORTB,0,0
    Nop
    PORTBstate = WREG
    GIE = True


    If PORTBstate <> OldPORTBstate Then
    DelayUS 987
    Inc PortBswCheck
    If PortBswCheck = 0 Then
    GIE = False
    GIE = False
    Btg PORTB,1,0
    Btg PORTB,2,0
    Btg PORTB,3,0
    Nop
    PORTB = 0 ;write all 0 to portB
    DelayUS 3
    TRISB = $FF
    Nop
    WPUB = 011111 'Pullups Enabled '
    Nop
    TRISB = $FF
    Nop
    WPUB = 011111 'Pullups Enabled '
    RBIF = 0
    GIE = True
    GoSub DebugFlash_Red
    GoTo ExitGetSwEnd '255 read failed, so bail out and try again
    Else
    GoTo GetSw_Read 'try to clear port until two reads are stable
    EndIf
    EndIf


    SwState = 0 'clear the register
    SwState = PORTBstate & 011110 'sw1 & sw2 pins swapped RB.1 & RB.2 in AasignPins
    SwState = SwState >> 1 '001111
    ' SwState.4 = INT '011111
    SwState.4 = 1 '011111 ' no used set as ON
    SwState.5 = LCDSw3pin 'As PORTE.3 same as MCLR but set to digital in CONFIG MCLRE=INTMCLR ' RE3 input pin enabled; MCLR disabled




    Select SwState

  2. #2
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,784
    Thumbs Up
    Received: 158
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I see that you're using the programming pins, what programming mode are you using? Could it be that you're falling into LVP mode?
    George

  3. #3
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    130
    Thumbs Up
    Received: 1
    Given: 6
    Total Downloaded
    279.64 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I'm not sure how. The PICKIT programmer is attached, but not doing anything, so, electrically speaking those two pins are slightly different than the others. I tried it without the programmer attached and it made no difference. I've been using these pins like this years. It's the one thing you can do easily without circuitry interfering with programming. A 1k resistor protects the pins and the programming connection from the de-bounce capacitors. As as all the switches. Its never been a problem before. However, it could be that I just never noticed it because I never had so much going on interrupt-wise.

    Anyway, its not a problem programming the chip, nor is it a problem with these pins. In fact, these are the pins that do work. The freeze only happens under normal operation of the circuit, nothing to do with programming. A power cycle fixes the freeze issue.

    Right now, I'm using the timer interrupt to set a variable that allows the port to be read ever 12mS instead of every 50uS. So far, I haven't had the freeze, but that doesn't mean much.

    Thanks for the suggestion! I will look into it.

    Lee

  4. #4
    Senior Member Stephen Moss's Avatar
    Join Date
    Jan 2006
    Posts
    403
    Thumbs Up
    Received: 28
    Given: 4
    Total Downloaded
    1.86 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    A few comments...
    1) It is helpful if you include your entire code so that people can check everything including you fuse configuration, for example you are setting GIE but we cannot see if you have aliased it or not as we do not have the entire code.
    2) Proton is a BASIC compiler, consequently not everyone here understands Assembler, for maximum chance of getting help that resolves the problem it would be better if you could keep your code to all BASIC wherever possible.
    3) Try wrapping you Assembler code in the Asm and EndAsm commands, the compiler treats those Assembler instructions inside the commands a little differently to those inline with the Basic code, it is possible that may resolve the issue.
    4) I see you have the line Inc PortBswCheck followed by If PortBswCheck = 0 Then but no method of resetting the value to 0. I can only presume that you are incrementing the variable and relying on the value overflowing the variable size to return it to 0. That may not be the best or most reliable approach and could possible be causing odd things to happen, try replacing them with...
    Code:
    If PortBswCheck = 255 Then    'Value dependant on the maximum for the variable size (byte, word, etc)
    PortBswCheck = 0
    Else
    Inc PortBswCheck
    EndIf
    5) If I have understood your initial post correctly it appears that you are using weak internal pulls and external pull up resistors on the same pin, I would not think that is a good thing to do as at best you cannon be certain of the actual resistance with the internal pull-up (usually a low current FET) in parallel with external resistor and at worst you may get strange current flows between them that may possible result in the port pins latching up. Try it with either internal or external pull-ups on their own.

  5. #5
    Member tumbleweed's Avatar
    Join Date
    May 2011
    Posts
    373
    Thumbs Up
    Received: 66
    Given: 0
    Total Downloaded
    118.16 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I agree with Stephan.

    Why use error-prone statements like
    Code:
    Nop
    Movf PORTB,0,0
    Nop
    OldPORTBstate = WREG
    as opposed to the simpler "OldPORTBstate = PORTB".

    Also, there should be no need to constantly disable/enable interrupts and set the WPUB and TRISB registers.
    Why do you write to PORTB pins that are set as switch inputs?

  6. #6
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,784
    Thumbs Up
    Received: 158
    Given: 153
    Total Downloaded
    3.04 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    @xldaedalus. Sorry I wan't clear. My point was that is you are using LVP and using the programming pins it may be possible to fall into LVP mode. BTW Personally if I were using the programming pins as i/o I would not risk leaving the PicKit connected.
    I wonder if it might be an option to replace the 18F26K22 with 18F46K22 (if only for testing) so that you can free up those programming pins.

    But most of all, listen to Tumbleweed and Stephen Moss
    George

  7. #7
    Prolific Poster See_Mos's Avatar
    Join Date
    Feb 2004
    Posts
    1,188
    Thumbs Up
    Received: 15
    Given: 0
    Total Downloaded
    603.66 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I think Stephen has spotted where the code was latching up.

    If you have not set interrupts on change or interrupts on PortB then you don't need to keep clearing and setting GIE
    Last edited by See_Mos; 12th October 2018 at 15:13.
    My RAM is failing

  8. #8
    Prolific Poster See_Mos's Avatar
    Join Date
    Feb 2004
    Posts
    1,188
    Thumbs Up
    Received: 15
    Given: 0
    Total Downloaded
    603.66 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I looked at this again and the code has several problems and the timing is all wrong. I think you need to start again with just the switch code and get that working first..

    What is the code after
    Code:
    If PortBswCheck = 0 Then
    supposed to do ?
    My RAM is failing

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

     

Similar Threads

  1. 16f628A portb.4 problem
    By raf in forum Absolute Beginners Section
    Replies: 1
    Last Post: 14th March 2017, 08:09
  2. PORTB not behaving
    By shantanu@india in forum Proton Plus Compiler v3
    Replies: 17
    Last Post: 27th October 2009, 08:23
  3. Problem with portB on16F886
    By JohnP in forum Proton Plus Compiler v3
    Replies: 2
    Last Post: 14th October 2008, 13:14
  4. 18F452 PORTB.6 & 7 Problem
    By scott e. in forum Proton Plus Compiler v3
    Replies: 2
    Last Post: 1st January 2007, 02:08
  5. Confused about portb
    By David Blackburn in forum Proton Plus Compiler v3
    Replies: 6
    Last Post: 3rd June 2005, 20:50

Members who have read this thread since 14th October 2018, 17:01 : 8

Actions :  (Set Date)  (Clear Date)

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts