Shop OBEX P1 Docs P2 Docs Learn Events
Sx-key Breakpoints — Parallax Forums

Sx-key Breakpoints

inakiinaki Posts: 262
edited 2005-05-24 17:13 in General Discussion
On Sx-Key IDE is there any way to place breakpoints when debugging other than placing a BREAK sentence on the code?

·

Comments

  • KenMKenM Posts: 657
    edited 2005-05-22 19:52
    Inaki,

    Yes you can insert a breakpoint without hard coding.

    Just click on the line where you want a breakpoint, the line should turn red.

    You cannot insert a breakpoint as the last instruction before the sleep command.
    A work around is to insert a nop instruction before sleep.

    k


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    トヨタは　すばらし　です！！
  • Guenther DaubachGuenther Daubach Posts: 1,321
    edited 2005-05-23 17:06
    Inaki,

    using a BREAK directive in the source code is a good way to mark a "standard breakpoint", i.e. one you would usually set. This saves you from scrolling the list file until the code line becomes visible where you want the breakpoint. As Ken said, you can define a new breakpoint at any time by clicking on the code line in question. This also works when your source code contains a BREAK directive somewhere. In this case, the "standard breakpoint" is cleared, and set to the new location.

    Some additional tips:

    1) When you just change the position of the BREAK directive in the source code i.e. don't make any other changes, it is not necessary to re-load the the program into the SX, IOW use "Run - Debug (reenter)" instead of "Run - Debug" to re-start the debugger with the new breakpoint setting. This saves you the time to re-transfer the program into the SX.

    2) On code lines containing NOP instructions, breakpoints are ignored. This is due to the internal structure of the SX chips, and not a bug in the SX-Key software.

    3) Due to the internal structure, the code line containing the breakpoint is executed before the program stops. This sometimes can be annoying, e.g. when you set the breakpoint on a JMP or CALL instruction as the program will stop on the first line of the jump target or the subroutine. When you want to single-step the jump or call, place the breakpoint on the instruction immediately before the jump or call.

    4) Due to the internal structure of the SX, there can only be one breakpoint active at any time.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Greetings from Germany,

    G
  • inakiinaki Posts: 262
    edited 2005-05-24 16:26
    Guenther,
    so is it necessary to run the program from start when the breakpoint location is changed ? I understand it is not necessary to reload but is it necessary to restart it ?

    I mean, ordinary breakpoints on processors like, for example, PICs, can bet set at any place and continue running the program from the current point. Is this possible under SX-Key ?

    Thanks.
    Inaki.
  • PJMontyPJMonty Posts: 983
    edited 2005-05-24 17:10
    Inaki,

    You can set a breakpoint and have the debugger stop the processor. You can then set another breakpoint and continue debugging. You can do this as much as you like.

    Have you actually tried using the debugger? If you did, then you could try the experiment yourself and find out how the debugger works. I recommend experimenting to see how things work.


    Thanks,
    PeterM
  • Guenther DaubachGuenther Daubach Posts: 1,321
    edited 2005-05-24 17:13
    Inaki,

    maybe, my explanation was not precise enough...

    There are two methods setting a breakpoint:

    1) Add a BREAK directive in the source code. This automatically activates a breakpoint on the code line following the BREAK directive when you launch the debugger - either via "Run- Debug", or via "Run - Debug (reenter)". Where "Run-Debug" starts SASM to translate the source code into machine code which is then transferred into the SX program memory (provided that there are no errors detected). On the other hand, "Run - Debug (re-enter)" assumes that the machine code contained in the SX program memory is still up-to-date, i.e. that it matches the current version of the source code shown in the SX-Key program editor - thus, the machine code is not transferred into SX program memory, and the debugger will be launched immediately.

    2) Clicking on a code line in the list window while the Debugger is active. This will de-activate any breakpoint that has been eventually set before (no matter by which method), and then will activate a new breakpoint on this new code line.

    There is no need to run the program from start when you change the breakpoint location. A typical situation would be that you include a BREAK directive in your program in order to define the first breakpoint. You then will "Run - Debug" the program, and click the "Run" button in the debugger's command window. The program will be executed at full speed until this breakpoint has been reached. You may then click on another code line to define the next breakpoint, and click "Run" again to continue program execution until it reaches this new breakpoint, etc...

    When you quit the debugger, and later want to continue the debug session, as a rule of thumb, you may invoke the debugger via "Run - Debug (re-enter)" as long as you did not change the source code. This will start the debugger immediately w/o transferring the program code to the SX. One exception to this rule is that after changing the position of the BREAK directive in the source code it is still fine to launch the debugger using "Run - Debug (re-enter)" as this did not change the instruction code generated by the assembler - the BREAK only informs the Debugger (when launched) where to place the initial breakpoint.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Greetings from Germany,

    G
Sign In or Register to comment.