• AVR Freaks

Hot!Debugging itoa failed

Author
Ekkehard
New Member
  • Total Posts : 12
  • Reward points : 0
  • Joined: 2018/01/01 16:25:16
  • Location: 0
  • Status: offline
2019/06/21 14:26:49 (permalink)
0

Debugging itoa failed

Summary: When pressing F8 (Step over), while the executed command is an itoa() function call, the debugger crashs. Using F7 (Step into) instead succeeded.
 
Details: I am using

Product Version: MPLAB X IDE v5.20
Java: 1.8.0_181; Java HotSpot(TM) 64-Bit Server VM 25.181-b13
Runtime: Java(TM) SE Runtime Environment 1.8.0_181-b13
System: Windows 10 version 10.0 running on amd64; Cp1252; de_DE (mplab)
The used Compiler is 1.36
The target device is a PIC24FJ64GA104
I am using an ICD 3
 
Full description:
The used testcode is very small, pls see the code below. The program uses a global buffer and operates with an itoa function on it. It also it uses the itoa function with a pointer instead of the direct buffer.
When debugging, I am using the F8 key to step over the functions line by line. If the line is the itoa statement then the debugger halted somewhere (not on the following line) and the debugger output window shows a message like this
No source code lines were found at current PC 0x32c. Open program memory view to see instruction code disassembly. 
User program running
User program stopped
and it is not possible to step further in the program.
It is notable, that the ito function is probably correct executed, since the correct result could be seen in the global variable.
The only debugging option is to hit the reset button to restart the program from the very beginning.
 
If I am using the F7 Key instead (which is strange, since the function has no source code where to step through), everything is running fine, the debugger is continuing on the next line.
 
Any idea, what causes the strange behaviour?
 
Best regards
Ekkehard
 
/* 
 * File: main.c
 * Author: Ekkehard
 *
 * Created on 21. Juni 2019, 11:08
 */
// PIC24FJ64GA104 Configuration Bit Settings

// 'C' source line config statements

// CONFIG4
#pragma config DSWDTPS = DSWDTPSF // DSWDT Postscale Select (1:2,147,483,648 (25.7 days))
#pragma config DSWDTOSC = LPRC // Deep Sleep Watchdog Timer Oscillator Select (DSWDT uses Low Power RC Oscillator (LPRC))
#pragma config RTCOSC = SOSC // RTCC Reference Oscillator Select (RTCC uses Secondary Oscillator (SOSC))
#pragma config DSBOREN = ON // Deep Sleep BOR Enable bit (BOR enabled in Deep Sleep)
#pragma config DSWDTEN = OFF // Deep Sleep Watchdog Timer (DSWDT disabled)

// CONFIG3
#pragma config WPFP = WPFP0 // Write Protection Flash Page Segment Boundary (Page 0 (0x0))
#pragma config SOSCSEL = IO // Secondary Oscillator Pin Mode Select (SOSC pins have digital I/O functions (RA4, RB4))
#pragma config WUTSEL = FST // Voltage Regulator Wake-up Time Select (Fast regulator start-up time used)
#pragma config WPDIS = WPDIS // Segment Write Protection Disable (Segmented code protection disabled)
#pragma config WPCFG = WPCFGDIS // Write Protect Configuration Page Select (Last page and Flash Configuration words are unprotected)
#pragma config WPEND = WPSTARTMEM // Segment Write Protection End Page Select (Write Protect from page 0 to WPFP)

// CONFIG2
#pragma config POSCMOD = XT // Primary Oscillator Select (XT Oscillator mode selected)
#pragma config I2C1SEL = PRI // I2C1 Pin Select bit (Use default SCL1/SDA1 pins for I2C1 )
#pragma config IOL1WAY = OFF // IOLOCK One-Way Set Enable (The IOLOCK bit can be set and cleared using the unlock sequence)
#pragma config OSCIOFNC = OFF // OSCO Pin Configuration (OSCO pin functions as clock output (CLKO))
#pragma config FCKSM = CSDCMD // Clock Switching and Fail-Safe Clock Monitor (Sw Disabled, Mon Disabled)
#pragma config FNOSC = PRI // Initial Oscillator Select (Primary Oscillator (XT, HS, EC))
#pragma config IESO = OFF // Internal External Switchover (IESO mode (Two-Speed Start-up) disabled)

// CONFIG1
#pragma config WDTPS = PS8192 // Watchdog Timer Postscaler (1:8,192)
#pragma config FWPSA = PR128 // WDT Prescaler (Prescaler ratio of 1:128)
#pragma config WINDIS = OFF // Windowed WDT (Standard Watchdog Timer enabled,(Windowed-mode is disabled))
#pragma config FWDTEN = ON // Watchdog Timer (Watchdog Timer is enabled)
#pragma config ICS = PGx3 // Emulator Pin Placement Select bits (Emulator functions are shared with PGEC3/PGED3)
#pragma config GWRP = ON // General Segment Write Protect (Writes to program memory are disabled)
#pragma config GCP = OFF // General Segment Code Protect (Code protection is disabled)
#pragma config JTAGEN = OFF // JTAG Port Enable (JTAG port is disabled)

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

#include <xc.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/*
 *
 */

char strbuf[20]; // Buffer to hold the result
int main(int argc, char** argv) {
    char * s; // A string pointer
    itoa(strbuf,10,10); //convert the number 10 into a string "10", at the beginning of strbuf
    s = strbuf + strlen(strbuf); // lets point s to the \0 after the "10" in the strbuf
    itoa(s,11,10); // convert the number 11 into a string "11" and place the result just after the "10"
    strcat(strbuf,"!"); //place a "!" at the end of the string
    // the string should now contain "1011!"
    for(;;);
    return (EXIT_SUCCESS);
}




#1

11 Replies Related Threads

    crennolet
    Super Member
    • Total Posts : 136
    • Reward points : 0
    • Joined: 2012/03/15 09:51:58
    • Location: 0
    • Status: offline
    Re: Debugging itoa failed 2019/06/21 15:14:40 (permalink)
    0
    Where does itoa come from here? I built your code and get it undefined.
    #2
    Ekkehard
    New Member
    • Total Posts : 12
    • Reward points : 0
    • Joined: 2018/01/01 16:25:16
    • Location: 0
    • Status: offline
    Re: Debugging itoa failed 2019/06/21 15:22:09 (permalink)
    0
    Thank you for your answer. This is a point I forgot to mention.
    There is a tick box in the compiler settings in the "XC-16 (Global Options)", named "use legacy libc" which is checked by default but must be unchecked, to get the function included.
     
    I altered another setting there using "ELF/DWARF", but the "COFF"-Setting for the output format does not change the behaviour.
    Best regards
    Ekkehard
    #3
    Jim Nickerson
    User 452
    • Total Posts : 6329
    • Reward points : 0
    • Joined: 2003/11/07 12:35:10
    • Location: San Diego, CA
    • Status: online
    Re: Debugging itoa failed 2019/06/22 07:51:00 (permalink)
    +1 (1)
    Maybe you could add a couple of Nops before and after the call to itoa and see if step over then works
    #4
    crennolet
    Super Member
    • Total Posts : 136
    • Reward points : 0
    • Joined: 2012/03/15 09:51:58
    • Location: 0
    • Status: offline
    Re: Debugging itoa failed 2019/06/22 12:15:02 (permalink)
    +1 (1)
    The same thing happens with a PIC24FJ64GA002 using a linux system. And also with a PICKIT3.
     
    As Jim suggests, putting a couple of asm("nop"); in before and after the itoa helps. It also helps to use breakpoints rather than try and step.
     
    Further information: the problem does not appear to be with the itoa function, as replacing it with my own does not change the behavior. And then, using "step out" while in that function, the same behavior was seen. The debugger reports that the chip has been halted. But, if you pull down Window and memory views, and select Program Memory, you can see that the program is in a loop, which looks like a loop in the itoa function, but without the source code, how can we know? It seems that the debugger thinks the function has returned, but the display doesn't think so, and the result appears to be a deadlock.
     
    You can then step several times and get out of that loop. (I suspect the loop count would depend on the length of the string.) I've seen this kind of thing before, and found that looking at program memory is useful in these cases.
     
    #5
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Debugging itoa failed 2019/06/22 12:31:19 (permalink)
    +2 (2)
    If Nop() helps, the base issue could be breakpoint skidding.
    #6
    crennolet
    Super Member
    • Total Posts : 136
    • Reward points : 0
    • Joined: 2012/03/15 09:51:58
    • Location: 0
    • Status: offline
    Re: Debugging itoa failed 2019/06/23 10:52:09 (permalink)
    0
    Can "skidding" happen retroactively? That appears to be what's happening here. The stop should happen on the instruction which represents the first line of C after the call to the subroutine itoa, but it happens earlier.
    #7
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Debugging itoa failed 2019/06/23 11:06:15 (permalink)
    +2 (2)
    Breakpoints happen on ASM instructions not C ones. And no the breakpoint skid after not before.
    #8
    GeorgePauley
    Moderator
    • Total Posts : 1172
    • Reward points : 0
    • Joined: 2009/12/01 13:59:30
    • Location: Chandler AZ
    • Status: online
    Re: Debugging itoa failed 2019/06/24 13:30:59 (permalink)
    +3 (3)
    I'm going to guess it's the watchdog timer.  From your config bits it looks like it is on.. "#pragma config FWDTEN = ON".  If you don't execute a CLRWDT instruction periodically you'll get an interrupt.  Unless you are handling this interrupt, you'll likely vector to the default interrupt handler which is just an infinite loop.  You can check RCON.WDT0 to see if a watchdog timeout occurred.
    #9
    crennolet
    Super Member
    • Total Posts : 136
    • Reward points : 0
    • Joined: 2012/03/15 09:51:58
    • Location: 0
    • Status: offline
    Re: Debugging itoa failed 2019/06/25 14:00:57 (permalink)
    0
    WDT fires at the top of main with a prescaler of 8192 and postscaler of 128? Takes about 32,000,000 instruction cycles. Also, in my version, with the same code but using a PIC24FJ64GA002 (since that's what I have) I explicitly disable the WDT and still get the same behavior. In addition, why does the code work when you then step through it? You need to try this with actual hardware, as it works as expected in the simulator. But, as noted, it will show the syndrome with either a PICKIT3 or ICD3.
     
    #10
    ric
    Super Member
    • Total Posts : 24222
    • Reward points : 0
    • Joined: 2003/11/07 12:41:26
    • Location: Australia, Melbourne
    • Status: offline
    Re: Debugging itoa failed 2019/06/25 15:53:40 (permalink)
    +2 (2)
    crennolet
    ...
    , why does the code work when you then step through it?



    I believe the debugger forces the WDT timer off when you're single stepping, or it couldn't operate at all.
     

    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!
    #11
    NKurzman
    A Guy on the Net
    • Total Posts : 17924
    • Reward points : 0
    • Joined: 2008/01/16 19:33:48
    • Location: 0
    • Status: online
    Re: Debugging itoa failed 2019/06/25 17:55:55 (permalink)
    +1 (1)
    ric
    crennolet..., why does the code work when you then step through it?


    I believe the debugger forces the WDT timer off when you're single stepping, or it couldn't operate at all. 


    I believe you are correct.
    I think it even warns you if you left it on.
    #12
    Jump to:
    © 2019 APG vNext Commercial Version 4.5