• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 80 subscribers
  • Views 231 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP430FR2676: Large delay introduced around breakpoint

Richard Franke
Prodigy 40 points
Part Number: MSP430FR2676
Other Parts Discussed in Thread: MSP-FET

Tool/software:

I have the following code:

  1. Global disable interrupts
  2. Disable watchdog
  3. Init DCO (as per TI documentation)
  4. Clear port pin
  5. NOP 
  6. NOP
  7. NOP
  8. NOP
  9. Set port pin
  10. Clear port pin
  11. NOP
  12. NOP
  13. NOP

If I place a breakpoint at 13, and scope the pin, I get a pulse of ~1.2us as expected for my clock. However if I place the breakpoint at 11 (and sometimes 12), and scope the pin, the pulse is around ~41ms.

(Above line edited to fix line number reference error. I added items to my numbered list after I had typed this statement - DOH)

Note:

  • I have confirmed the code is as expected, by viewing the disassembler 
  • The pin is not connected to any other hardware. I have tried other pins, the result is the same.
  • I am using EW430 IAR Debugger together with MSP-FET Flash emulation tool (with latest firmware)
  • IAR support have referred me here, as they believe it is a device / FET specific issue.
  • I have tried various combinations of JTAG speed, Memory cache and ULP debug, but the result is always the same.

Example of the pin code and breakpoint location:

  • 0
    TI__Mastermind 39895 points

    Can you use a while(1), instead of the breakpoint and run the code at free run mode? This can make sure it is only related to the run/debug mode, instead of the executed code. The code under debug mode may be different at run mode. 

    If you really want to check what happens in the debug mode, please disable the software breakpoint function and make a try again. 

  • 0
    Guru 25295 points

    Not really sure what you are asking. I have to assume by pulse you mean the positive pulse between lines 9 and 11.

    Setting a breakpoint at line 9 requests stopping the CPU before the pin is set. You say that this results in a long pulse but I suspect what you really mean is that you get a long pulse after you continue execution.

    I would be surprised if there weren't odd timings in the first few instructions executed after continuing execution. What would be interesting is how far before line 9 you have to set the breakpoint for the pulse timing to be normal.

  • 0 in reply to David Schultz
    Prodigy 40 points

    Apologies, I had a numbering error in my statement as I added items to the list after the fact - DOH. I have corrected the original post

  • 0 in reply to Eason Zhou
    Prodigy 40 points

    Apologies, I had a numbering error in my statement as I added items to the list after the fact - DOH. I have corrected the original post

  • 0 in reply to Richard Franke
    Guru 25295 points

    Changes only from how to restart the CPU over JTAG to how to set and field a breakpoint. The later complicated by the ability of the MSP430 to prefetch instructions.

**Attention** This is a public forum