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.

What effects does debug under CCSv5 with SBW connections have on interrupt response?

Other Parts Discussed in Thread: MSP430F5172

My MSP430F5172 project is interrupt-intensive (UART sending 400 bytes at 250K, 30 times/second); processor clock of 4 MHz.  Running in CCS Debug with SBW connection, UART data appears corrupted (missing an unknown # of bytes > - I lack instrumentation to tell for sure). Disconnected from SBW and being self-powered, behavior is as desired and rock-solid.

Does SBW interfere with interrupt processing, and would JTAG be any better?  I'd sooner not sacrifice I/O's to use JTAG, but will if I'd have better results

Thanks for thoughts

Doug

  • No doubt that running at 4 MHz and a baud rate of 256000 bps is reaching the limits of the MCU, don't forget that this is only 16 cycles between bits. Since the debugger requires extra clock cycles to monitor the MCU PC and determine when breakpoints are hit this is causing corrupted UART data. You have a few options here:

    - Try changing the JTAG/SBW speed to Fast inside of MSP430F5172.ccxml -> Target Configuration ->MSP430.
    - Increase the MSP core frequency (8, 12, or 16 MHz) to allow more processing cycles between UART bits, you may be able to revert back to 4 MHz once you no longer need to debug the application.
    - Reduce the UART baud rate (once again, this can be undone after finished debugging).
    - You can definitely try using 4-wire JTAG communication instead for faster debug processing but I'm not sure if this will eliminate the problem.

    Regards,
    Ryan
  • Doug,

    Please keep in mind that with the debugger enabled, no matter the speed, the whole application will run slower due to the EEM's interference with operation of the part. Since everything is slowed down, different subsystems can happen at the same time to the debugger, while running without the debugger in Free Run mode or self-powered, will not show these issues. Alternatively, the debugger can hide some issues due to this factor. This makes it particularly difficult to debug race conditions within an application.
  • Thanks to you both for replies.  I upped clock to 8 MHz with no change in symptoms, and 'scope shows no noticeable difference in UART Tx data in CCS/SBW mode vs standalone.  Processor is in LPM3 during UART activity and interrupts come at 44 uS rate (11 bits at 4 us each). 

    The unpredictable behavior may be in the early-stage code for my receiving devices (up to 40 -F5131's along an RS485 bus).  I'll start to work from that end 

    Regardless, I'd be interested in an app note or some-such that indicates how the debug tool (MSP-FET430UIF) and SBW and JTAG each interact with the processor.  I've always wondered how they may affect interrupts (or anything else)

  • Doug Lochner said:
    Regardless, I'd be interested in an app note or some-such that indicates how the debug tool (MSP-FET430UIF) and SBW and JTAG each interact with the processor.

    The introduction to Advanced Debugging Using the Enhanced Emulation Module (EEM) With Code Composer Studio Version 6 SLAA393E claims:

    The EEM logic in the MSP430 works nonintrusively, meaning that it does not use or lock any resources targeted for the application, such as registers, memory, or interrupts.

    Which is at odds with your observed behavior.

    When you run the program under the debugger are there any breakpoints, watchpoints or EEM trace active?

    Also, do you have any indication of how often the UART corruption occurs? Wondering if you can try and see if the rate of UART corruption ties in with how often the MSP-FET430UIF is access the target device over the SBW connection.

  • Doug Lochner said:
    Processor is in LPM3 during UART activity and interrupts come at 44 uS rate (11 bits at 4 us each).

    The MSP430x5xx and MSP430x6xx Family User's Guide SLAU208O contains the following note:

    Maybe the MSP-FET430UIF is causing a faster wake-up time from LPM3 which is highlight a timing problem.

    Can you try testing without entering LPM3 and see if the behavior is still different when connected to the MSP-FET430UIF .vs. running standalone?

  • Chester,

    that's a very informative post!  Changing to LPM1 (a mode not cited in the topic you included) was a trivial code change. After only a few minutes of test, so far the device now works as desired with the -FET430 connected and CCS controlling Run, Pause, Reset, etc.  At this point I haven't tried Breakpoints or other tools with this change in place, though I have in the past.

    I'll keep working with it and see if my luck holds!

  • I have in the past used breakpoints, but not recently in the presence of this debug problem.  The device acts up immediately upon clicking Debug's Run button, and I've concentrated on 'scoping the Tx Data signal. The code causes the UART to send ~400 bytes every 30 ms or so and at least the first several bytes all look good - I don't have instrumentation to actually read the whole message, but my receiving devices for the first few bytes always fail the same way, virtually every time I load and run the code with SBW connected.

    I've been concentrating on the Transmitting code using early code in my Receivers, that may lack some error recovery functions.  Running Tx in LPM1 per your subsequent post, I may now be in a position to debug both operations.

    Thanks!

    Doug

**Attention** This is a public forum