• AVR Freaks

Hot!Why doesn't this program flash the LEDs?

Author
oliverb
Super Member
  • Total Posts : 189
  • Reward points : 0
  • Joined: 2009/02/16 13:12:38
  • Location: 0
  • Status: offline
2019/06/20 23:12:53 (permalink)
0

Why doesn't this program flash the LEDs?

Had a wierd experience last night where a program just seemed to "brick".
 
So I wanted to put in an initialised array of char.
If the line "    char test[]="test";" is put in anywhere the PIC just sits in tristate, nothing happens even though the line isn't reached. I'm guessing that the initializer is looping endlessly?
I tried to simulate it, but it seemed to run as expected in sim.
 
/*
 * File: main.c
 * Author: Oliver
 *
 * Created on 21 June 2019, 06:49
 */
#define _XTAL_FREQ 64000000
// PIC18F46K42 Configuration Bit Settings

// 'C' source line config statements

// CONFIG1L
#pragma config FEXTOSC = OFF // External Oscillator Selection (Oscillator not enabled)
#pragma config RSTOSC = HFINTOSC_64MHZ// Reset Oscillator Selection (HFINTOSC with HFFRQ = 64 MHz and CDIV = 1:1)

// #pragma config statements should precede project file includes.
// Use project enums instead of #define for ON and OFF.

#include <xc.h>


void main(void) {
    TRISD=0;
    while(1)
    {
        LATD=0x55;
        __delay_ms(100);
        __delay_ms(100);
        LATD=0xAA;
        __delay_ms(100);
        __delay_ms(100);
    }
    // this line?
    char test[]="test";
    return;
}

post edited by oliverb - 2019/06/20 23:22:23
#1

18 Replies Related Threads

    pcbbc
    Super Member
    • Total Posts : 1104
    • Reward points : 0
    • Joined: 2014/03/27 07:04:41
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/20 23:31:58 (permalink)
    +1 (1)
    In the code you have posted, I expect the compiler may completely ignore that code. It can never be reached, and so can be completely eliminated with no side effects.
    As to why that makes your PIC balk, I cannot say. Look at the assembler output if you want the answer.
    post edited by pcbbc - 2019/06/21 02:01:22
    #2
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11218
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/20 23:51:15 (permalink)
    +1 (1)
    I would expect the hex file to be identical with or without the "test" declaration and the "return" statement.  Neither does anything.
    #3
    jtemples
    عُضْوٌ جَدِيد
    • Total Posts : 11218
    • Reward points : 0
    • Joined: 2004/02/13 12:31:19
    • Location: Southern California
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/20 23:58:21 (permalink)
    +1 (1)
    Where are the rest of your configuration fuses?
    #4
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 00:48:16 (permalink)
    0
    I left the rest of the fuses at default, so I removed them to reduce the size of the code sample. I compiled it like that to confirm the behavior didn't change. Comment the array and the LEDs work. Uncomment it and the PIC just sits in tristate.
     
    I don't see a reason for the return statement, it was in the template so I left it there. I suppose it is just a pedantic interpretation of "void"?
     
    Originally the problem first showed up in a much bigger program, and it took the form of an elaborate LCD demo suddenly doing absolutely nothing.
     
    I found the assembly listing file eventually, as far as I can tell having that array there creates an initialised data "psect" and also the initialiser code to fill the psect. Initialiser code runs first before "main", even though the array declaration is never reached.
     
    I'm going to take a guess that on real silicon the initialiser loop never ends for some reason. Right now I don't know how to make MPLAB simulate at assembly level in order to walk through the "invisible" initialisation code.
     
    I'm currently using a "XPRESS" board so as far as I'm aware I have no in-circuit debug capability on the xpress. I do have a PICKIT3 and a suitable board (believed to be "a001" silicon), so I intend to try that this afternoon.
     
    post edited by oliverb - 2019/06/21 02:45:33
    #5
    ric
    Super Member
    • Total Posts : 22756
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Why doesn't this program flash the LEDs? 2019/06/21 03:04:16 (permalink)
    +1 (1)
    Which version of XC8?
    If it's v2.xx, which mode are you using (C90, or C99) ?
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #6
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 03:36:20 (permalink)
    0
    Currently 2.05, I can't confirm the mode as I wasn't actually aware of the option. Which one would be default?
     
    I remember also trying 1.45 and seeing the same behavior but I do need to confirm that.
     
    MPLAB version was 5.10.
     
     
    #7
    ric
    Super Member
    • Total Posts : 22756
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Why doesn't this program flash the LEDs? 2019/06/21 03:39:26 (permalink)
    0
    oliverb
     I can't confirm the mode as I wasn't actually aware of the option. Which one would be default?

    I believe that if you import an old project, it defaults to C90.
    If you start a new project, it will use C99.
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #8
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 06:24:00 (permalink)
    0
    OK so I tried it on a different board and it works with that line left in or out. I've tried C90 and C99 settings.
    So far it seems confined to the xpress board, so I guess I can rule out a compiler bug.
     
    Things took a turn for the wierd...I attached the xpress to a board that also has the connector for a PICkit3.
     
    If I write the hex file to the xpress it doesn't run.
    If I write the hex file via the PICkit3 it does run.
     
    I think the next step may be to read the memory contents back and "FC" the hex files.
     
     
    #9
    ric
    Super Member
    • Total Posts : 22756
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Why doesn't this program flash the LEDs? 2019/06/21 06:28:00 (permalink)
    0
    Have you by chance, manually set how much program memory to write in the settings for the Express programmer?
     

    I also post at: PicForum
    Links to useful PIC information: http://picforum.ric323.co...opic.php?f=59&t=15
    NEW USERS: Posting images, links and code - workaround for restrictions.
    To get a useful answer, always state which PIC you are using!
    #10
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 07:21:12 (permalink)
    0
    No, but I think you're on to something. The xpress board is much faster on small files, so I'm going to assume it only writes what it has to, whereas MPlab IPE seems to do a blanket overwrite of all memory.
    I tried loading the hex into the IPE and saving it. The result was too BIG for the xpress to program, so I tried editing out a big block of FFs, and it accepted the trimmed file, and it worked.
     
    Next step has to be reading the PIC contents back.
     
    #11
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 12:12:54 (permalink)
    0
    OK so here's where things get seriously wierd. Dumpbad was obtained by programming the PIC using the xpress board's onboard programmer. Dumpgood was obtained by programming the SAME code but using IPE. Both were read back using the IPE.
     
    It appears as if the hex in DUMPBAD is OFF BY ONE!!!
     
    Comparing files C:\USERS\OLIVER\DOCUMENTS\dumpbad.hex and C:\USERS\OLIVER\DOCUMENTS\DUMPGOOD.HEX
    ***** C:\USERS\OLIVER\DOCUMENTS\dumpbad.hex
    :10FF7000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91
    :10FF80007465737400810EF66EFF0EF76E000EF846
    :10FF90006E00EE07F010EE05F009006F00D7FFEEDF
    :10FFA000FFE550E150F9E10001D7EF7FF0000EC509
    :10FFB0006E550EBD6E210E016E760EE82EFED70137
    :10FFC0002EFCD700D0210E016E760EE82EFED70152
    :10FFD0002EFCD700D0AA0EBD6E210E016E760EE863
    :10FFE0002EFED7012EFCD700D0210E016E760EE832
    :10FFF0002EFED7012EFCD700D0DBD7C3EF7FF0FF5A
    :020000040030CA
    ***** C:\USERS\OLIVER\DOCUMENTS\DUMPGOOD.HEX
    :10FF7000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF91
    :10FF8000FF7465737400810EF66EFF0EF76E000E3F
    :10FF9000F86E00EE07F010EE05F009006F00D7FFD5
    :10FFA000EEFFE550E150F9E10001D7EF7FF0000EE0
    :10FFB000C56E550EBD6E210E016E760EE82EFED773
    :10FFC000012EFCD700D0210E016E760EE82EFED752
    :10FFD000012EFCD700D0AA0EBD6E210E016E760E4A
    :10FFE000E82EFED7012EFCD700D0210E016E760E32
    :10FFF000E82EFED7012EFCD700D0DBD7C3EF7FF071
    :020000040030CA
    *****

    ***** C:\USERS\OLIVER\DOCUMENTS\dumpbad.hex
    :020000040020DA
    :10000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00
    :020000040031C9
    ***** C:\USERS\OLIVER\DOCUMENTS\DUMPGOOD.HEX
    :020000040020DA
    :10000000FF0FFF0FFF0FFF0FFF0FFF0FFF0FFF0F80
    :020000040031C9
    *****

    #12
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 12:23:02 (permalink)
    +1 (1)
    Here's some compiler output. Now technically there is nothing wrong with this hexfile, but for a PIC hexfile there is something really wierd going on: It doesn't appear to be word-aligned.
     
    Here's my hypothesis: Adding an intialised variable adds a data psect. Unlike code a data psect can start on an odd address. Somehow instead of padding as required the compiler has actually created the file with an unaligned start.
     
    MPLAB has no problem with this as it pads automatically. I'm going to guess that xpress can't auto-pad and confronted with an odd address it truncates it down?
     
    :020000040000FA
    :04000000FEEF7FF0A0
    :10FF81007465737400810EF66EFF0EF76E000EF845
    :10FF91006E00EE07F010EE05F009006F00D7FFEEDE
    :10FFA100FFE550E150F9E10001D7EF7FF0000EC508
    :10FFB1006E550EBD6E210E016E760EE82EFED70136
    :10FFC1002EFCD700D0210E016E760EE82EFED70151
    :10FFD1002EFCD700D0AA0EBD6E210E016E760EE862
    :10FFE1002EFED7012EFCD700D0210E016E760EE831
    :0FFFF1002EFED7012EFCD700D0DBD7C3EF7FF059
    :020000040020DA
    :10000000FF0FFF0FFF0FFF0FFF0FFF0FFF0FFF0F80
    :020000040030CA
    :0A000000ECFFFFFFFFFFFFFFFFFF13
    :00000001FF

    #13
    PStechPaul
    Super Member
    • Total Posts : 2303
    • Reward points : 0
    • Joined: 2006/06/27 16:11:32
    • Location: Cockeysville, MD, USA
    • Status: online
    Re: Why doesn't this program flash the LEDs? 2019/06/21 13:22:03 (permalink)
    +1 (1)
    Probably not your problem, but default CONFIG is usually WDTEN = ON.
     
    Also, check the connections to MCLR-. They might differ between boards.
    post edited by PStechPaul - 2019/06/21 13:26:22

     
    #14
    1and0
    Access is Denied
    • Total Posts : 9314
    • Reward points : 0
    • Joined: 2007/05/06 12:03:20
    • Location: Harry's Gray Matter
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/21 14:42:21 (permalink)
    +1 (1)
    oliverb
    It appears as if the hex in DUMPBAD is OFF BY ONE!!!

    Hex file that is off by one byte is NOT GOOD, because a PIC18 instruction word consists of two bytes.
     
    #15
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/22 00:56:33 (permalink)
    0
    Just to clarify: xpress needs an extra padding byte at the beginning to make the addresses even otherwise an off-by-one failure occurs.
    MPLAB IPE adds padding automatically
     
    I've just managed to manually pad a hex file, but leaving the addresses odd so now the data IS misaligned. Now I have a file that the xpress board will accept but MPLAB IPE can't load unless I correct the addresses too.
     
    Oh and for what its worth I looked up the xpress source on Github and I can see it now, in direct.c function "packrow" it clearly ignores the bottom bit of the address.
     
     
    post edited by oliverb - 2019/06/22 09:28:45
    #16
    dan1138
    Super Member
    • Total Posts : 3123
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/22 11:46:03 (permalink)
    0
    @oliverb,
     
    I am curious about the specific xpress board and the git repository for the loader code you are using.
     
    Would you please post links to what you are using?
     
    Thanks.
    #17
    mlp
    boots too small
    • Total Posts : 766
    • Reward points : 0
    • Joined: 2012/09/10 15:12:07
    • Location: previously Microchip XC8 team
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/22 20:01:44 (permalink)
    +1 (1)
    oliverb
    I've tried C90 and C99 settings.

    C90 requires all variable definitions be BEFORE any statements within a given block.
    The "extra variable", even if unused, invokes Undefined Behaviour when the compiler is in C90 mode.
    So, in C90 mode everything is fine (because once you raise the UB flag, whatever happens is Your Fault and no business of the compiler).
     
    In C99 mode, though, if the generated code behaves differently with the addition of this single otherwise-unreferenced initialised variable to the source then it's time for you to lodge a Support Case with a complete sample project (including all config pragmas) demonstrating the bug.

    Mark (this opinion available for hire)
    #18
    oliverb
    Super Member
    • Total Posts : 189
    • Reward points : 0
    • Joined: 2009/02/16 13:12:38
    • Location: 0
    • Status: offline
    Re: Why doesn't this program flash the LEDs? 2019/06/24 02:38:45 (permalink)
    +2 (2)
    I have a support case open : 00428609
    I've uploaded the skeletal project, though it still has only the minimum config still.
    I can demonstrate the behavior with a three line nonfuctional program now I know what to look for.
    If the array initialiser data has an odd number of bytes then the hex file gets an odd start address.
     
     
    #19
    Jump to:
    © 2019 APG vNext Commercial Version 4.5