This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Debugging, execution speed & SWI_Handler...

I have an app that seems to work perfectly when executing from flash ROM. However, if I load the code into the flash ROM and then start the debugger, the code slows down to a very slow crawl while executing. If I clear the only breakpoint I had set (the one you get when you enable the debugger to start your code and run to main), and do a reset/run, it runs correctly at the normal speed.

However, if I stop the debugger and put a breakpoint anywhere, such as where I'm toggling the state of a heartbeat LED, which is blinkking away just fine, and then restart the debugger that breakpoint never triggers. Worse yet, the code once again slows to a crawl. Worse yet, if I click on the red 'X' to manually break execution, the debugger stops at a line of ASM code labeled SWI_Handler in KEIL's SAM7.s file, and seems to stay there.

Other than the startup ASM code provided by the KEIL tools, SAM7.s, there is no other assembly source code in my project. I only edit that ASM code via the GUI configuraion wizard, and very little at that. Basically I configure the PLL, increase the space allocated for the interrupt and user/system modes and enable the watchdog timer.

Can anyone help me figure out

1) why the code slows to a crawl when I enable a breakpoint, and
2) why I end up at SWI_Handler if I manually break execution, and
3) why the code seems to run just fine at the correct speed if I clear all breakpoints and do a reset/run?

Confuzed...
Dave.

Parents
  • Perhaps I could use a little more patience...

    I noticed that after starting the debugger and pressing the 'RUN' key, if I waited ~ 15 seconds my program would suddenly appear to miraculously start running, and run just fine.

    Also, I could then click on the 'BREAK' key and the debugger would break in a believable place in my code. However, after putting in a breakpoint and hitting the 'RUN' key, the debugger would then appear to do nothing again, for ~ 15 seconds or so, then the code would appear to take off and break right away on the breakpoint I just entered.

    So... where's this 15 second delay coming from. I'm really, really sure it can't be due to my code. Okay, well... I'm pretty sure ;-) After all, if I just load the code and run it outside the debugger it starts up immediately and works perfectly, every time, right away, including right after releasing my hardware reset switch, no matter how many times I repeat this.

    ARRGGGHHHH... I sure would like to be able to use the debugger (in a way that convinced me it was working correctly). This 15-second delay is killing me.

    Sigh...

    Any suggestions...?

Reply
  • Perhaps I could use a little more patience...

    I noticed that after starting the debugger and pressing the 'RUN' key, if I waited ~ 15 seconds my program would suddenly appear to miraculously start running, and run just fine.

    Also, I could then click on the 'BREAK' key and the debugger would break in a believable place in my code. However, after putting in a breakpoint and hitting the 'RUN' key, the debugger would then appear to do nothing again, for ~ 15 seconds or so, then the code would appear to take off and break right away on the breakpoint I just entered.

    So... where's this 15 second delay coming from. I'm really, really sure it can't be due to my code. Okay, well... I'm pretty sure ;-) After all, if I just load the code and run it outside the debugger it starts up immediately and works perfectly, every time, right away, including right after releasing my hardware reset switch, no matter how many times I repeat this.

    ARRGGGHHHH... I sure would like to be able to use the debugger (in a way that convinced me it was working correctly). This 15-second delay is killing me.

    Sigh...

    Any suggestions...?

Children