• AVR Freaks

Hot![SOLVED] Another (not a) bug in the MPLABX V5.40 simulator bait store

Author
dan1138
Super Member
  • Total Posts : 3841
  • Reward points : 0
  • Joined: 2007/02/21 23:04:16
  • Location: 0
  • Status: offline
2020/06/11 13:20:27 (permalink)
5 (4)

[SOLVED] Another (not a) bug in the MPLABX V5.40 simulator bait store

<EDIT>
This is also not a simulator bug. Thanks George!
 
This is not a compiler bug!

The simulator will branch to parts unknown when executing this code:
/*
 * File:   main.c
 * Author: dan1138
 * Target: PIC16F877A
 * Compiler: XC8 v2.20
 *
 * Created on June 11, 2020, 11:35 AM
 *
 * Note:
 *  The MPLABX v5.40 simulator does not run this code correctly.
 *
 *  The simulation fails in the sequence:
 *      Line   Address  Opcode  Label  DisAssy
 *        4    0003     00FF            MOVWF 0x7F
 *        5    0004     3000            MOVLW 0x0
 *        6    0005     008A            MOVWF PCLATH
 *        7    0006     087F            MOVF  0x7F, W
 *        8    0007     0782            ADDWF PCL, F
 *        9    0008     2808            GOTO  0x8
 *       10    0009     120A            BCF   PCLATH,0x4 <- single step on this instruction results in a branch to parts unknown.
 *       11    000A     158A            BSF   PCLATH,0x3
 *       12    000B     2DD2            GOTO  0x5D2
 */

#pragma config FOSC = HS, WDTE = OFF, PWRTE = OFF, BOREN = OFF, LVP = OFF
#pragma config CPD = OFF, WRT = OFF, CP = OFF

#include <xc.h>

extern void foo(void) __at (0xDD2);

void main(void)
{
    void (* volatile a)(void) = foo;

    for(;;)
    {
        a();
    }
}

MPLAB v8.92 simulates the HEX file correctly.

I have no clue how anyone code make the simulator do this on purpose.

What had to be whacked to make this regression occur would be an interesting story.

Hey George you in a story telling mood?
post edited by dan1138 - 2020/06/12 15:14:13
#1

9 Replies Related Threads

    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/11 13:24:20 (permalink)
    +2 (2)
    I'm sure George will ask what PIC device you had selected when testing.
    I would assume it is a non-enhanced PIC16F device. Does it matter which one?
     

    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!
    #2
    dan1138
    Super Member
    • Total Posts : 3841
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/11 13:39:27 (permalink)
    +2 (2)
    You really thing he's going to ask that?
     
    The comment in the test code:
     * Target: PIC16F877A

    is too subtle?
    #3
    ric
    Super Member
    • Total Posts : 28365
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: online
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/11 15:02:01 (permalink)
    +3 (3)
    Oops, sorry Dan.
    I'd scrolled the code window down to the actual sequence, and forgot there were lines above it.
    I should have kown better, you're always very thorough documenting your code. :)
     
     

    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!
    #4
    MHS
    Super Member
    • Total Posts : 367
    • Reward points : 0
    • Joined: 2010/04/23 10:05:39
    • Location: 0
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 11:09:49 (permalink)
    0
    What is "correctly" ? There doesn't seem to be any code at 0xDD2
    #5
    GeorgePauley
    Moderator
    • Total Posts : 1268
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 12:25:42 (permalink)
    +4 (4)
    I believe the root issue here is the phrase "execution of this instruction results in..." in the source code.  How exactly are you executing this instruction?  I'm going to guess you are using "step-into" or "step-over".  

    These two MPLAB X commands are source file oriented, meaning they will use line-table information from the ELF file to "figure out" where the target address of the step-over or step-into command should end up.  Given that the code in question here is compiler generated start-up code, there very likely is no line-table information (for this code segment) in the ELF file, and MPLAB X is... confused.  So MPLAB will tell the simulator to single step until it ends up at an address that it can find in the line-table information (or it gives up after some large number of single steps.)  This is what happens here.

    Simplifying the last paragraph:  If you step-into or step-over, at 0x0009, the simulator is going to end up executing more than one instruction.

    The way to get around this "problem" is to use step-instruction instead.  Unfortunately, step-instruction is not available on the MPLAB X toolbar or menu's by default.  (Decision made by the same folks who decided it was time to get rid of the assembler. mr green: mr green)  But you can get it on the toolbar, by right-clicking on the (debug) toolbar, selecting customize, finding step-instruction in the debug commands section, and dragging that button out onto the debug toolbar.  (See attached screenshot of modified toolbar.)

    Now if you instruction-step at 0x0009, you will see that the "BCF PCLATH, 0x4" instruction works as expected.  Two more instruction-steps get you to 0x000B with the "GOTO 0x5D2" instruction.  This becomes "GOTO 0xDD2" because of the current contents of the PCLATH register.

    But there is no actual code at 0xDD2!  At this point the application is out of control.

    I am very interested in the idea that MPLAB 8.92 simulator executed this exact same sequence of instructions differently.



    Attached Image(s)

    #6
    dan1138
    Super Member
    • Total Posts : 3841
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 14:02:09 (permalink)
    +1 (1)
    @George,

    I understand your explanation is to use a feature of the MPLABX simulator user interface that is hidden from the developer to cause the simulation to advance by just one and only one instruction cycle.

    I can confirm that this does exactly what you have described and the instruction simulates as expected.

    Because there is "no code" in my example project at address 0xDD2 I had the project fill all unused instruction words with the 'RETURN' (opcode 0x0008) so that there are valid instructions everywhere.

    So when using the double secret "step instruction" you recomment this is the result:


    When using the "step-into" this is the result:


    When the "step-into" is used on the "BCF PCLATH, 0x4" instruction why does the simulator select the next instruction from address 0x7F8?

    MPLAB v8.92 simulates this without issue is because you cannot use the XC8 v2.20 compiler I just imported the HEX file and used the "step-into" button on the toolbar.

    Perhaps MPLABX v5.40 will behave the same way if no line debug information is available.

    I just checked this and yes the "step-into" button works as expected when no debug information is available to the MPLABX v5.40 simulator.
    post edited by dan1138 - 2020/06/12 14:19:43
    #7
    GeorgePauley
    Moderator
    • Total Posts : 1268
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 14:22:04 (permalink)
    +1 (1)
    Step-into and step-over are MPLAB X High Level Debugger (HLD) operations.  The HLD is a simulator client.  I'm not knowledgeable about the HLD internals.  My understanding is that the HLD will always try to get the tool (server) to stop on an address that corresponds to a source level line, based on information gleaned from the line-table information in the project ELF file. 

    Since there (likely) is no line table information for this portion of the code, the HLD will attempt to get to one of the desired addresses by telling the simulator to instruction-step several times, stopping when one of those desired addresses is reached.  (Or when a substantial number of steps have occurred, without reaching a desired address, and the HLD realizes the situation is hopeless, and just gives up.)

    But this is just my understanding.  I really don't know exactly what HLD is doing here.  But for sure, it is geared to supporting stepping through C source code.
    #8
    GeorgePauley
    Moderator
    • Total Posts : 1268
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 14:23:25 (permalink)
    +1 (1)
    I would think that filling unused memory with RETURN statements would be likely to produce... undesired results?  Such as returning to invalid addresses, and causing stack underflow exceptions.
     
    #9
    dan1138
    Super Member
    • Total Posts : 3841
    • Reward points : 0
    • Joined: 2007/02/21 23:04:16
    • Location: 0
    • Status: offline
    Re: Another bug in the MPLABX V5.40 simulator bait store 2020/06/12 14:55:18 (permalink)
    +3 (3)
    GeorgePauley
    I would think that filling unused memory with RETURN statements would be likely to produce... undesired results?

    Such as returning to invalid addresses, and causing stack underflow exceptions.

    First filling the unused instruction space with RETURN instruction is for this test purpose.

    Second the PIC16F877A does not have a stack underflow exception so this cannot be a problem.

    Third if the simulator was actually executing the instruction stream in memory it would have executed only valid PIC instruction and not halted the simulation at address 0x7F8 after a "step-into" the "BCF PCLATH, 0x4" instruction.

    So I got to ask again how did the simulator decide that address 0x7F8 was where the simulation should be stopped?


    <EDIT>
    I think I figured it out. Address 0xF78 is the address of the "next" High-Level-Language statement that the simulator "knows" the location of. In my code this the "for" loop end brace '}' and is a "GOTO" opcode.
     
    So my mystery solved, not a simulator bug after all. It's the MPLABX IDE making the simulator look like it has a bug.
    post edited by dan1138 - 2020/06/12 15:15:22
    #10
    Jump to:
    © 2020 APG vNext Commercial Version 4.5