Today 17:33
Forum: The Lounge
Starter: basparky
Views: 0
Replies: 9
Go to last post By: yvesmazzon
Today 16:43
Forum: The Lounge
Starter: rverm
Views: 5528
Replies: 12
Today 16:34
Forum: Proton Plus Compiler v3
Starter: gtv_pic
Views: 0
Replies: 10
Today 15:31
Forum: Absolute Beginners Section
Starter: amod
Views: 0
Replies: 13
Today 14:42
Forum: Projects discussion
Starter: steyn
Views: 0
Replies: 4
Today 13:06
Forum: Proton Plus Compiler v3
Starter: evoortman
Views: 0
Replies: 1
Today 13:05
Forum: Proton Plus Compiler v3
Starter: evoortman
Views: 0
Replies: 20
+ Reply to Thread
Page 3 of 4 FirstFirst 1234 LastLast
Results 21 to 30 of 36

Thread: Mysterious PORTB problem33 days old

  1. #21
    Administrator John Drew's Avatar
    Join Date
    Feb 2002
    Posts
    2,542
    Thumbs Up
    Received: 106
    Given: 29
    Total Downloaded
    2.69 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Have you tried increasing the LCD delays?
    John

  2. #22
    Prolific Poster See_Mos's Avatar
    Join Date
    Feb 2004
    Posts
    1,198
    Thumbs Up
    Received: 16
    Given: 0
    Total Downloaded
    603.66 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I'm sorry. My circuit is using an 18F46k22. The 18F26k22 doesn't have a PORTE. I apologize for any confusion. I use the 18F26k22 in 4 or 5 other devices, so, its on my brain.
    Although it does not have a Port E as such RE.3 / MCLR is is implemented on pin 1 of the 25K22 and follows the same rules as the bigger device.

    You mentioned that the code seems more stable after working with ANSEL reminded me of a problem I experienced with mixed analog and digital. I fixed it by putting All_Digital = True at the start of my code and manipulating ANSEL when analog was needed.

    I'm with John on increasing the LCD delays.

    If the leads to the button is less than 200mm you should not need the capacitors. As you already know the capacitors will take time to charge back up after a button press and could cause errors but that should not cause lockup
    Last edited by See_Mos; 18th October 2018 at 09:56.
    My RAM is failing

  3. #23
    Prolific Poster See_Mos's Avatar
    Join Date
    Feb 2004
    Posts
    1,198
    Thumbs Up
    Received: 16
    Given: 0
    Total Downloaded
    603.66 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Just thought of something else, have you got 100nF ceramic capacitors pins 11 to 12 and 31 to 32 and as close to the PIC as possible?

    Depending on track layout you might get away with either but they are so cheap I use both.
    My RAM is failing

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

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Quote Originally Posted by See_Mos View Post
    Just thought of something else, have you got 100nF ceramic capacitors pins 11 to 12 and 31 to 32 .
    On the 18F46k22 pin 12 is NC, pin 31 is the CS pin for SPI and 32 is a logic pin. Pin 11 has a 1uF cap on it. I assume you mean me to use bypass caps on all of the power pins of the chip. Yes, I always put the caps as close as possible to the device.


    ...MCLR is is implemented on pin 1 of the 25K22 and follows the same rules as the bigger device.
    Yes. I saw this, thanks for pointing it out. I think the 18F2xK22 also has a TRISE.x for setting the weak pull up on that pin


    You mentioned that the code seems more stable after working with ANSEL reminded me of a problem I experienced with mixed analog and digital. I fixed it by putting All_Digital = True at the start of my code and manipulating ANSEL when analog was needed.
    I don't ever use All_Digital = TRUE. I got in the habit early one to use the registers directly to set everything. It makes it harder to set up a program, but easier to go through and check the exact state of everything. Its not being snobby, its just the way I like to do it, even if it creates problems like the stupid mistakes I make. At least, I'm making them, and not a command / macro I not sure what it does and doesn't do.


    I'm with John on increasing the LCD delays.
    I did decrease them as much as possible, however, it takes so long to print the OLED, I can't really delay it any more without getting flicker. What I do is actually divide up the work of printing the whole screen into individual elements. Each element gets printed every 12.5mS. So it might take @ 50mS to update the entire screen, but when it does print to the OLED, it's only away from the state machine loop ((Main: ... : goto Main) for 1-5mS - which is bad, but the best I can do without writing all new code. When printing a new screen, I print everything at once, so it might take up to 60mS its out of the state machine loop (Main: ... : goto Main) - which is too long, but this also limits the button press / PORTB read.


    If the leads to the button is less than 200mm you should not need the capacitors.
    The switch leads are less than 100mm. But I always use caps on switches as my boards are always used around lots of radio noise, and no one like the lights to flicker when the push the Talk-to-send button.




    That said, in response to adding the caps to the switches, the failure became the OLED screen going black. Les suggested a pull down resistor on RB.5, which has been more or less a floating input. So, I got an unmodified board, pulled RB5 to GND, and I got a pretty dramatic improvement. While it still freezes, it takes a lot longer to freeze. According to Les RB.5 is or can be used in place of MCLR (PGM) although I can't find this anywhere in the data sheet or programming guide. However in App Note DS41398A Flash Memory Programming Specification: it says this


    The sequence that enters the device into the Program/
    Verify mode places all unused I/Os in the high-impedance
    state


    While it seems unlikely, if LVP=Off, that the chip could enter LVP mode, but stranger things have happened.

  5. #25
    Prolific Poster See_Mos's Avatar
    Join Date
    Feb 2004
    Posts
    1,198
    Thumbs Up
    Received: 16
    Given: 0
    Total Downloaded
    603.66 MB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I should have said that the pin numbers I suggested are for the DIP version so the capacitors are across VDD and VSS
    My RAM is failing

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

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    I now this the problem is that, somehow the values in RAM are switched somehow, something suddenly puts them out of order

    PortBstate = PORTB 'PUT action store value to RAM address PortBstate


    SwState = PortBstate & %00011110 ' ( CALL action recalling PortBstate from a different RAM location)


    Something is happening so that the PUT and CALL address values are different. Something along the lines of the ISR restoring a value to the wrong address..


    This has something to do with


    a.) the small RAM stack I have is overflowing
    b.) Context Save / Restore
    c.) an ISR interrupting a RETURN
    d.) the Gosub / Return stack is overflowing


    I think this because in the original crash listing in which I printed the values of SwState and PortBstate, and at the crash, I was suddenly getting a frozen value for SwState (ie SwState wasn't changing as I pressed the buttons). I jumped to the conclusion that it was PORTB that was wrong. PORTB was right but SwState or the mechanism that moves the PORTB value to SwState is out of order, and recalling and usind the wrong RAM location.

    I don't know how this can happen, but its the only thing that makes sense. I'm going through all of my gosubs that POP and PUSH values to the small STACK I have (20).

  7. #27
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,825
    Thumbs Up
    Received: 161
    Given: 158
    Total Downloaded
    3.20 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Don't GOSub variables use an internal stack, that you can make any size?
    George

  8. #28
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    147
    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
    Don't GOSub variables use an internal stack, that you can make any size?
    Maybe the compiler has changed. I always add a

    Declare Stack_Size 20

    at the top of my program because I thought it created 20 bytes of RAM for passing variables back and forth for doing stuff like

    Gosub XXXX [MyByteVar1, MyByteVar2], MyByteVar3

    .....

    XXXX:
    Dim ByteVar1 as Byte
    Dim ByteVar2 as Byte
    Dim ByteVar3 as Byte

    Pop ByteVar2
    Pop ByteVar1

    ByteVar3 = ByteVar1 + ByteVar2

    Return ByteVar3

    Obviously, you'd never waste this much code space for a simple addition, but the mechanism is the same.

    Is this wrong?

  9. #29
    Prolific Poster towlerg's Avatar
    Join Date
    Mar 2012
    Posts
    1,825
    Thumbs Up
    Received: 161
    Given: 158
    Total Downloaded
    3.20 GB

    0 Not allowed!

    Default Re: Mysterious PORTB problem

    Thats my point, if the stack is too small, make it bigger.
    George

  10. #30
    Member xldaedalus's Avatar
    Join Date
    Jan 2005
    Posts
    147
    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
    Thats my point, if the stack is too small, make it bigger.
    Thanks. It didn't make a different, besides if the RAM stack was filling up by bad code, a bigger stack would just take longer to fill up. It would just take longer to crash. I put LED traps in every endless loop, ie WHILE : WEND. DO : UNTIL, interrupts, etc. Indicator LED is RGB, all colors OFF outside endless loop, different colors ON inside each endless loop, so that when frozen, LED would be solid color inside the frozen endless loop. When I finally experience the freeze, all colors off, and interrupt routines are flashing, but at a much slower rate, like the PLL is off, or there's a long delay somewhere, maybe not frozen delayed enough to cause the interrupts to happen about 50x slower than normal. I tested the switch state to see if the program was running, just very, very slowing, that the switch values would function, they didn't unless the OSC was running at 32kHz and would take 15 min for the button switch condition to get reacted to.

    Bottom line, its still freezing, and its not because its stuck in an endless loop. Since each freeze seems to manifest itself with slightly different attributes, I suspect there are either multiple reasons for the freeze, or that the freeze is actually something akin to the MCU just becoming completely confused, and how this confusion manifests itself, like Quantum Physics, is also effected by what I've tried to do to observe it.

    I tried to capture the bug running the program in ISIS with a simulated fast button press routine. It took 12 hours to get to 6:42 in real time(real world freeze usually happens @4:30), and all registers, memory etc, look perfectly normal. RAM doesn't seem to be filling with extraneous data, the GOSUB stack is 10 of 31. All this tells me is that either the automated button press pattern I wrote(in HDL) was either wrong(it looked identical on the oscilloscope except for switch bounces) or the ISIS simulator doesn't mimic the 18F46K22 EXACTLY.

    Still trying to figure it out. I'm re-writing the HDL to add random switch bounce and run another 12hr sim while I'm re-writing the interrupt routines.

    Thanks for your suggestions.

    Lee

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

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