Today 14:49
Forum: The Lounge
Starter: See_Mos
Views: 0
Replies: 6
Today 13:24
Forum: Absolute Beginners Section
Starter: amod
Views: 0
Replies: 28
Closed Thread
Page 1 of 4 123 ... LastLast
Results 1 to 10 of 37

Thread: Mysterious PORTB problem39 days old

  1. #1
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    148
    Thumbs Up
    Received: 4
    Given: 6
    Total Downloaded
    355.40 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,833
    Thumbs Up
    Received: 161
    Given: 158
    Total Downloaded
    3.22 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
    148
    Thumbs Up
    Received: 4
    Given: 6
    Total Downloaded
    355.40 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
    408
    Thumbs Up
    Received: 28
    Given: 5
    Total Downloaded
    2.11 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
    379
    Thumbs Up
    Received: 68
    Given: 0
    Total Downloaded
    141.92 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,833
    Thumbs Up
    Received: 161
    Given: 158
    Total Downloaded
    3.22 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,209
    Thumbs Up
    Received: 16
    Given: 0
    Total Downloaded
    614.99 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,209
    Thumbs Up
    Received: 16
    Given: 0
    Total Downloaded
    614.99 MB

    1 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

  9. #9
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    148
    Thumbs Up
    Received: 4
    Given: 6
    Total Downloaded
    355.40 MB

    1 Not allowed!

    Default Re: Mysterious PORTB problem

    Quote Originally Posted by Stephen Moss View Post
    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.
    Thank you, Stephen. There are 15,000 lines in the program, I can' post it all, it would be very hard to understand. GIE is not aliased. It is only there because I thought if I stopped this section of code from interrupting, it might solve the problem. It doesn't, so it makes no difference. My config settings are pretty standard, and are the same as other devices, with similar programs that don't have the problem. I don't think its relevant, but here are the config settings:

    Config_Start
    ' $ifdef Xfosc
    ' $if Xfosc = 16 Then
    FOSC=INTIO67 ' Internal oscillator block, port function on RA6 and RA7
    ' $else
    ' FOSC=ECHPIO6 ' HS Ext oscillator block, no port function on RA6 ?
    ' $endif
    ' $endif
    PLLCFG=On 'ON:Oscillator multiplied by 4 ; OFF:Oscillator used directly
    PRICLKEN=OFF 'Primary clock can be disabled by software
    FCMEN=OFF 'Fail-Safe Clock Monitor disabled
    IESO=OFF ' Oscillator Switchover mode disabled [Off:RE3 input pin enabled,MCLR disabled]
    XINST=OFF ' Instruction set extension and Indexed Addressing
    ' PBADEN=OFF ' PORTB<4:0> 0 = pins are configured as digital I/O on Reset 1 = As analog I/O On Reset
    PBADEN=OFF ' PORTB<4:0> pins are configured as digital I/O on Reset
    CCP2MX=PORTC1 'CCP2 input/output is multiplexed with RC1
    Debug=OFF 'Disabled
    HFOFST=OFF ' HFINTOSC output and ready status are delayed by the oscillator stable status
    T3CMX=PORTB5 ' T3CKI is on RB5
    P2BMX=PORTC0 ' P2B is on RC0
    CCP3MX=PORTE0
    MCLRE=INTMCLR ' RE3 input pin enabled; MCLR disabled
    PWRTEN=On ' Power-up Timer Enabled
    BOREN=On ' Brown-out Reset Disabled
    BORV=285 ' Brown-out Voltage (25)2.5V
    WDTEN=Off ' Watchdog Timer Disabled
    WDTPS=1 ' Watchdog Postscaler 1:128
    ' CCP2MUX = On ' CCP2 MUX Enable (RC1)
    STVREN=Off ' Stack Overflow Reset Disabled
    LVP=Off ' Low Voltage ICSP Disabled
    ' Debug = Off ' Background Debugger Enable Disabled
    Cp0=On ' Code Protection Block 0 Disabled
    CP1=On ' Code Protection Block 1 Disabled
    CP2=On ' Code Protection Block 2 Disabled
    CP3=On ' Code Protection Block 3 Disabled
    CPB=On ' Boot Block Code Protection Disabled
    CPD=On ' Data EEPROM Code Protection Disabled
    WRT0=Off ' Write Protection Block 0 Disabled
    WRT1=Off ' Write Protection Block 1Disabled
    WRT2=Off ' Write Protection Block 2 Disabled
    WRT3=Off ' Write Protection Block 3 Disabled
    WRTB=On ' Boot Block Write Protection Disabled
    WRTC=On ' Configuration Register Write Protection Disabled
    WRTD=Off ' Data EEPROM Write Protection Disabled
    EBTR0=Off ' Table Read Protection Block 0 Disabled
    EBTR1=Off ' Table Read Protection Block 1 Disabled
    EBTR2=Off ' Table Read Protection Block 2 Disabled
    EBTR3=Off ' Table Read Protection Block 3 Disabled
    EBTRB=On ' Boot Block Table Read Protection Disabled
    Config_End


    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.
    I do not know Assembler very well either. I was trying assembly to see if that fixed the problem, it didn't.

    Here is the original code I started with. This or what I posted, nothing yet has put a dent in the problem

    ' Symbol SWoff = $3F '111111
    ' Symbol SWup = $3E '111110
    ' Symbol SWdwn = $3D '111101
    ' Symbol SWmode = $3B '111011
    ' Symbol SWupMode = $3A '111010
    ' Symbol SWdwnMode = $39 '111001
    ' Symbol SwTRIG = $37 '110111
    ' Symbol SwINT = $2F '101111
    ' Symbol SwIntTrig = $27 '100111
    ' Symbol SwUPIntTrig = $26 '100110
    ' Symbol SwDwnIntTrig = $25 '100101
    ' Symbol SwMCLR = $1F '011111
    ' Symbol SWupMCLR = $1E '011110
    ' Symbol SWdwnMCLR = $1D '011101
    ' Symbol SWupMCLRIntTrig = $06 '000110
    ' Symbol SWdwnMCLRIntTrig = $05 '000101


    SwState = 0 'clear the register
    SwState = PORTB & 11110 'sw1 & sw2 pins swapped RB.1 & RB.2 in AasignPins
    SwState = SwState >> 1 '001111
    SwState.4 = INT '011111
    SwState.5 = LCDSw3pin '111111 '

    SwByte = SwState

    Select SwState

    ' do switch action

    EndSelect





    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.
    I will try, thanks for the suggestion.

    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
    There is no PortBswCheck = 0 because the variable increments from 255 to 0, ie, it rolls over and starts again without adding code that does the same thing. Anyway, in all the tests I've tried, its never rolled over. Again, I put this code there to prevent or react to the case where PORTB got stuck, and I tried to unlatch it by writing to it, reading it, clearing it, changing TRISB from outputs and back to inputs, setting and clearing LATB, etc. Nothing clears PORTB from returning logic 0's for what should be logic 1's, confirmed by oscilloscope on PORTB 0-4 pins.

    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.
    This is a good point, and one which I have considered, even thought, I've done 5 PCBs with this same method and never experienced this problem. When the freeze occurs, I attempt to clear WPUB, which controls the weak pullups, clearing them and resetting them. I tried leaving them OFF. The results are the same - so far.


    Thank you for your ideas. I will consider all of them and try them. I believe the problem to be that for whatever reason, the PORTB internal latch, (that part of which is not related to the PORTB interrupt on change) is locking up. Is I understand it, it can only lock up for 1 reason - 1.) some software issue, such as a collison of CONTEXT SAVE / RESTORE in the HIGH and/or LOW priority interrupts, stack overrun, RAM overrun, etc, OR 2.) an external electrical condition, such as the "dead short" condition of an fully discharged capacitor, some weird inductance condition, noise on the +5v line that is spiking >+5v that causes some strange current flow inside the MCU circuitry, such that, as you suggest, the gate of the internal FET is >0, forcing the pin to be connected to ground until being reset by a power cycle.

    I'm done all I can think of with respect to Problem 1.) so I'm currently exploring 2.).

    I will post what I discover.
    Last edited by xldaedalus; 16th October 2018 at 23:00. Reason: bad formatting

  10. #10
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    148
    Thumbs Up
    Received: 4
    Given: 6
    Total Downloaded
    355.40 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Quote Originally Posted by tumbleweed View Post
    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?
    As I explained, I was trying everything I could think of to fix the problem. The code isn't the problem, because, as show, it works just fine. The problem is something, somehow to freeze the lower pins of PORTB so that it no longer reads. I posted my original code and the config settings in my response to Stephen.

    I hope you can see my quandry. MyByteVal = PORTB should ALWAYS return the electrical state of the PORTB pins. Something is happening to cause this NOT to be the case.

Closed Thread
Page 1 of 4 123 ... LastLast

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, 09:09
  2. PORTB not behaving
    By shantanu@india in forum Proton Plus Compiler v3
    Replies: 17
    Last Post: 27th October 2009, 09:23
  3. [SOLVED !] 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, 03: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 9th November 2018, 01:20 : 29

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