[SOLVED !] Mysterious PORTB problem - Page 4


Today 10:37
Forum: The Lounge
Starter: Les
Views: 0
Replies: 1
Today 00:36
Forum: The Lounge
Starter: normnet
Views: 0
Replies: 2
Yesterday 11:49
Forum: The Lounge
Starter: Oldhack
Views: 0
Replies: 41
Closed Thread
Page 4 of 4 FirstFirst ... 234
Results 31 to 37 of 37

Thread: Mysterious PORTB problem61 days old

  1. #31
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,850
    Thumbs Up
    Received: 163
    Given: 162
    Total Downloaded
    3.24 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I'm sure it's safe to say that Isis does't simulate anything EXACTLEY.

    Very interesting that Isis found the bug because that means it not some weird electical problem eg. stray capacitance nor is it switch bounce. I quess it's either code or some race condition in the '22 that nobody has discovered.
    George

  2. #32
    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 towlerg View Post
    Very interesting that Isis found the bug ....

    Sorry to say, ISIS did NOT find the bug. Its still there. I did a bad job of explaining. Forgive for my poor typing skills. I'm partly dyslexic, so I often see words that aren't there because I expect them to be there. Believe me, this makes programming a bitch.

    In my code, I have a two level USART ISR. I have to use the same interrupt flag for both. The response to HIGH or LOW ISR depends on the state of the interrupt priority flag. I am currently thinking that in a very rare circumstance High priority interrupt occurs at just the wrong moment, and ends up operating in one ISR instead of the other - or something along those lines - and the Context Restore acts the wrong Context Save. How and why that would effect PORTB or the variable that holds the PORTB match state, I do not know.

    I made the choice to have a two level ISR to save instruction execution time. The LOW ISR has all the set up instructions, and the HIGH does the heavy lifting with as few instructions as possible. The purpose of the two level ISR is to receive DMX data frames 513 bytes long, each byte arriving every 44uS nearly constantly. I have set up a double buffer to insure accurate receipt of data, as DMX512 protocol offers no checksum. Therefore a large part of the running time of the program is spent in the UART the ISR. Adding all the instructions in a single ISR could have a significant impact on the total program.

    Until the addition of the OLED display, the software as written functions seems to have functioned very well for nearly a year.

    I'm will re-write the ISR so that the entire Serial UART data receive function happens in a single HIGH priority ISR. I will try to organize it to be fast enough to work.

    I will let you know if this solves the problem. It might be a few days.

  3. #33
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,850
    Thumbs Up
    Received: 163
    Given: 162
    Total Downloaded
    3.24 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Surely once an high priority interupt is generated, bothe high an low interupts are disabled and not reenabled until the restore is complete. Even if that were not the case it would be so spurious that your time to fail would be all over the place.

    I can't begin to imagin how you manage to code while suffering from dyslexia.
    George

  4. #34
    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 towlerg View Post
    Surely once an high priority interupt is generated, bothe high an low interupts are disabled and not reenabled until the restore is complete. Even if that were not the case it would be so spurious that your time to fail would be all over the place.
    Well, time to fail is all over the place, and the symptoms of the "freeze" are all over the place.

    Quote Originally Posted by towlerg View Post
    I can't begin to imagin how you manage to code while suffering from dyslexia.
    Hahaha! You and me both! Its a lot of extra typing! I name my variable with Capital but always type lower case, so I see the capital C appear, corrected by the IDE, I know its correct. Surprisingly, suffering isn't a good way to describe those with dyslexia. It's advantage outweigh its disadvantages, because Dyslexics think from the outside in, so we're already outside the box, so to speak, very often dyslexics have photograph like memories. I "see" numbers, so if I remember a number backwards, I never forget it. Often people don't know what I'm talking about, I guess because I'm outside the conventional box of language. It seems to me I'm being quite clear, but it appears not, not until I make a diagram or just do what I'm thinking of. And in reverse, it make learning by conventional methods difficult. Of course, that has the obvious disadvantages in that, besides mixed up numbers and words, it makes good organization very slow. Check out the desks of famous dyslexics, like Jobs, Einstein etc. That's my desk, and my code! But as Albert Einstein famously quipped, “If a cluttered desk is a sign of a cluttered mind, of what, then, is an empty desk a sign?”

    Luckily, its not that bad, just makes me slow, and my code hard to read, even to myself. It gets worse when I am tired. My cousins had it so bad, they had to go to special schools. I make it work.

    Thanks so much for your help. It is greatly appreciated.

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

    2 Not allowed!

    Default Re: Mysterious PORTB problem

    Well, I think I solved part of the problem anyway.

    In my project, I was forced to use the OLED as 3 wire SPI. This meant sending 9 bit SPI packets. I had to do this by bit banging the 9th bit (MSB) then using the 8bit SPI module to send data at 4Mhz. As Len and other's here suggested, the routine written in ASM might have been the problem, so I re-wrote it as follows:

    LATC.3 = 0 ; clear SCK pin
    DelayCS 2' 128nS
    SSP1CON1.5 = False ;disable SPI module
    DelayCS 1 ' 128nS
    LATC.5 = 0 ; clear SSD1309_MOSI_pin
    DelayCS 1 ' 64nS
    LATC.3 = 1 ; set SCK pin 1= CMD 0 = DATA
    SSP1CON1.5 = True ;enable SPI module


    SSP1BUF = OLED_wData ' start SPI clock
    DelayCS 1 ' 64nS


    While SSPSTAT.0 = 0
    Inc TempByte
    If TempByte > 100 Then Break 'max 48uS to send one byte to prevent endless loop
    Inc TempByte
    Wend


    TempByte = SSP1BUF

    This did NOT fix the OLED freeze problem. Finally, I connected one of my devices to the other, one sending serial data, and the other receiving, using the HIGH and LOW interrupts at 44uS per byte received. Everytime I started to send, the receiver OLED would freeze, and go black, while the device continued to receive data and otherwise function properly. SPI data continued to be sent to the OLED (monitored by Oscilloscope), but the OLED itself was no longer reacting. I figured that something about the interrupt, and the two identical devices running at very, very close to the same frequency (64Mhz internal OSC), was happening to panic the OLED.

    I guessed that an interrupt happening at the wrong time in the bit-bang portion, might be the cause. So I changed the above code, adding per the Proton manual, NOT GIE but PEIE:

    PEIE = False 'Symbol PEIE = INTCON.6 disable all peripheral interrupts


    LATC.3 = 0 ; clear SCK pin
    DelayCS 2' 128nS
    SSP1CON1.5 = False ;disable SPI module
    DelayCS 1 ' 128nS
    LATC.5 = 0 ; clear SSD1309_MOSI_pin
    DelayCS 1 ' 64nS
    LATC.3 = 1 ; set SCK pin 1= CMD 0 = DATA
    SSP1CON1.5 = True ;enable SPI module


    PEIE = True 'PEIE Enable all peripheral interrupts


    SSP1BUF = OLED_wData ' start SPI clock
    DelayCS 1 ' 64nS


    While SSPSTAT.0 = 0
    Inc TempByte
    If TempByte > 100 Then Break 'max 48uS to send one byte to prevent endless loop
    Inc TempByte
    Wend


    TempByte = SSP1BUF

    And part of the freeze problem disappeared.

    Its possible that the modification of the PORTB was due to one of my many stupid mistakes:

    DIM StringData[256] as byte
    ...
    Symbol SerialBufferMAX = 24 '<--- Change buffer size for max effectiveness
    DIM SerialBufferOUT[ SerialBufferMAX ] as byte
    DIM SwByte as Byte System

    ...

    For Counter = 0 to SerialBufferMAX

    SerialBufferOUT[Counter] = StringData[Counter]

    Next

    For those who don't recognize the stupid mistake, SerialBufferMAX(24) is used to SerialBufferOUT, which creates a 24 byte array but numbered 0 to 23. The FOR..NEXT writes 0 - 24 bytes, overwriting the array by one byte, which, as my luck would have it, the byte that holds the PORTB read. So, that when Counter = SerialBufferMAX, Counter = 24 and the program writes to SerialBufferOUT[24], which doesn't exist.

    To prevent this, something like this would be better.

    DIM StringData[256] as byte
    ...
    Symbol SerialBufferMAX = 24 '<--- Change buffer size for max effectiveness
    Symbol SerialBufferSize = SerialBufferMAX + 1
    DIM SerialBufferOUT[ SerialBufferSize ] as byte
    DIM SwByte as Byte System




    Anyway, I hope this is the end of the mystery. It re-affirms my understand that the MCU always does EXACTLY what you tell it to do. And the problems are almost always in the telling.

  6. #36
    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

    Still struggling with this strange problem. I put buffer variables in the declares to prevent array over runs change the variables value. I triple buffered the PORTx read value. Still, at seeminly random times, after random actions, the switch stops responding to the code after working for up to three hours function perfectly. I just can't imagine how a three way switch could be ON both UP and DOWN at the same time.

    Updating to new compiler, but I doubt that will make a difference. I just don't see how a port read or both of the double buffers matching and holding the read value could be effected by anything. Could it be possible that one of the variable names is the same as a protected name?

    28 days and counting.

  7. #37
    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

  8. Ok, I think the problem is solved - in a way.

    This was in my config settings.

    PBADEN=OFF ' PORTB<5:0> pins configured on reset


    PWRTEN=On ' Power-up Timer Enabled
    BOREN=On ' Brown-out Reset Disabled
    BORV=285 ' Brown-out Voltage (25)2.5V


    InitB: 'Initialize PORTB

    ANSELB = $00 'all digital I/O

    TRISB = $FF 'all inputs

    It means on experiencing a "brown out" (drop in MCU operating voltage) The processor resets. I have never experienced a "brown out" before, so I wasn't looking closely. So I had set up my oscilloscope on the 5v MCU power, and captured a random drop out in the voltage. In reading about the reset, I discovered that PBADEN=OFF cause PORTB<5:0> to reset as "analog" inputs. This means ANSELB resets to %00000000 or $1F, and in so doing PORTB.1 and PORTB.2, where my switches are located are set to "0"s, and will always read as "0". I set up a trap at the switch read subroutine, and printed the value of ANSELB to the OLED screen - it should always be $00 is it was initialized. Sure enough, when the MCU "froze", the ANSELB value was > $00

    So, I fixed the problem by

    PBADEN=ON ' PORTB<5:0> pins configured on reset as digital I/0

    And I haven't experience a freeze since.

    Of course, it has me looking at my MCU 5v power plan to figure out how and why there's a "brown out". That's a bit easier problem to solve.

    Thanks, everyone for your suggestions.

Closed Thread
Page 4 of 4 FirstFirst ... 234

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 : 60

Actions :  (Set 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