Very strange problem...


Closed Thread
Results 1 to 6 of 6
  1. #1
    Join Date
    Jun 2005
    Posts
    20

    Default Very strange problem...

    Hi--

    I've got PBP2.6 with a U2 programmer here, and I have been happily writing and debugging PICBASIC programs since 1996, so I'm not a newbie. However, I'm having a problem here that I just can't find the source of... PIC is an 18F4520 assembling with MPASM, and here's the deal:

    This code (and this is the ENTIRE program) works:

    Code:
    DEFINE OSC 8
    
    OSCTUNE = %11000000     'int low speed clock from osc 
    OSCCON =  %01110000     '8mhz internal oscillator 
    
    start:
        low portd.5 'LED on
        pause 100
        high portd.5 'LED off
        pause 100
    goto start
    
    lcdout $fe, 1
    As expected, this program flashes the LED on portd.5. I should point out that there is no LCD attached to the board, I removed it during my debugging process, along with all the other code.

    Here's the really weird part, the code below DOES NOT work:

    Code:
    DEFINE OSC 8
    
    OSCTUNE = %11000000     'int low speed clock from osc 
    OSCCON =  %01110000     '8mhz internal oscillator 
    
    start:
        low portd.5 'LED on
        pause 100
        high portd.5 'LED off
        pause 100
    goto start
    The only difference is I eliminated the LCDOUT command, which isn't inside the loop of the code that executes in the above (working) example anyway, so why does the code that contains the command work, whereas the lower code without it does not?

    Configuration in MeProg is set to INTRC, PWRT ON, brownout reset off, WDT enabled, MCLR set to RESET (and yes, there is a pullup on MCLR pin).

    Any ideas where to look??

    Thanks--

    --Alan
    Last edited by alanmcf; - 7th May 2011 at 00:55. Reason: typo more typos

  2. #2
    Join Date
    Aug 2010
    Location
    Maryland, USA
    Posts
    869


    Did you find this post helpful? Yes | No

    Default Re: Very strange problem...

    Just a guess here, but 2 things jump at me.

    INTRC is not a valid choice according to the datasheet, is this a typo or something strange.

    Assuming the above is just strange to me, try setting SCS bits to SCS1=1 and SCS0=0. This will force it to use the internal no matter what the config says (maybe).

    Now if this makes it work, I will have no idea why. My guess there is, well, hmmm, maybe, no no, ummm, clearly I have no idea. SRY
    -Bert

    The glass is not half full or half empty, Its twice as big as needed for the job!

    http://foamcasualty.com/ - Warbird R/C scratch building with foam!

  3. #3
    Join Date
    Jun 2005
    Posts
    20


    Did you find this post helpful? Yes | No

    Default Re: Very strange problem...

    Hi Bert--

    Thank you for your reply! My reference to INTRC was actually referring to the configuration option I selected from the pull-down menu for the meProg software-- it tells the U2 programmer to set the configuration fuses for the internal oscillator. I tried explicitly setting the SCS1 & SCS2 bits per your recommendation, but the program still behaves the same-- it works when it contains the LCDOUT command, and doesn't work without the command being present.

    Thanks--

    --Alan
    Last edited by alanmcf; - 7th May 2011 at 03:37.

  4. #4
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default Re: Very strange problem...

    Hi Alan,

    Do you have the "Options > More Options > Program > Serial Number" enabled in meProg?
    If so, uncheck it.

    It could be overwriting locations in Flash at the beginning of the code space.
    DT

  5. #5
    Join Date
    Jun 2005
    Posts
    20


    Did you find this post helpful? Yes | No

    Default Re: Very strange problem...

    Hi Darrell--

    Thank you for taking a look at this! That was, in fact, the problem. I turned off the serial number programming feature and it worked, and I verified that by turning the serial number feature back on, and adding a DEFINE RESET_ORG xx instruction at the top of the code, and it worked as well.

    So what is it about the LCD command's presence that makes the code work? Does LCDOUT force a different start for the code?

    Thanks--

    --Alan

  6. #6
    Join Date
    Jul 2003
    Location
    Colorado Springs
    Posts
    4,959


    Did you find this post helpful? Yes | No

    Default Re: Very strange problem...

    Well, the only difference between the two examples was the additional Library code added by the LCDOUT command.

    LCDOUT comes before PAUSE in the .lib file, so when included ... it pushes PAUSE up to a higher address. And since the LCDOUT command was never executed, a memory overwrite wouldn't be noticed, but PAUSE would work now.

    If the first example had tried to execute the LCDOUT statement, it probably wouldn't have worked (right) either.
    DT

Members who have read this thread : 1

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