• State Resolved
  • Locked Locked
  • Replies 9 replies
  • Subscribers 80 subscribers
  • Views 1375 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.

debug mode in IAR: can it cause timing issues?

Michael Stachowsky
Intellectual 420 points

Other Parts Discussed in Thread: MSP430G2553

I am using IAR to download the debug version of my code to a 430g2553.  I use the debug version because the eventual application will involve students writing their own code and learning to use debugging tools as it runs.  However, this code also requires them to make a software serial interface.  We use simple bit banging running on the DCO, something like this:

send_bit(value);
delay_cycles(104); //104 cycles at approx 1MHz gives us 9600 baud
repeat

I understand that, when using an uncalibrated DCO the timing might be off so badly that our serial will be flaky at best, and we definitely are seeing some flaky behaviour (it will work sometimes flawlessly, but sometimes the timing will be off and the receiver will get garbage).  

I was wondering: is it possible that the debug mode is causing things to be worse?  Will the debug mode still try to send data even if the serial/USB interface is not plugged in?  Would that cause some interrupts to happen while the hardware serial sets up its buffers to send whatever data it sends?

It's sort of hard to replicate the timing issues, so turning off debug output in the assembler won't necessarily tell me if it worked - just because it worked 5 times in a row doesn't mean it won't fail again, hence why I ask.

Mike

ps: out of curiosity, what output is sent over the hardware serial interface when debug output is selected?

  • 0
    Guru 46710 points

    msp430g2553 have USCI peripheral which supports UART mode, no need of bit banging.

    Michael Stachowsky said:
    I am using IAR to download the debug version of my code

    Debug code running on msp430 does not differ much from release code. Difference is debug information for debugger which is absent in "non-debug" code

  • 0 in reply to Ilmars
    Intellectual 420 points

    I agree.  I guess the question is: does that debug information, which is sent over the hardware serial link, cause interrupts to happen or something that might throw off my timing if I need to use delay_cycles?

  • 0 in reply to Michael Stachowsky
    Guru 46710 points

    Michael Stachowsky said:
    does that debug information, which is sent over the hardware serial link, cause interrupts to happen or something that might throw off my timing if I need to use delay_cycles?

    Debugger communication over SBW or JTAG does not do any harm to code execution as long as debugger does not instruct CPU to stop code execution :) So, if you single-step through code then timing is heavily affected by how fast you step through code ;)

  • 0 in reply to Ilmars
    Guru 12050 points

    Debug only sends info to the compiler if you have Log Breakpoints etc placed around your code.
    These breakpoints DOES stall the MCU for a brief moment, as clocks still will be running
    TimerA0 may have then missed a compare value and will not be fixed until TA0R rolls around. 

    Debug info is not sent over backdoor UART, it's sent over JTAG/SBW
    As USB have FIFO and multi endpoints, the data will not be mixed up.

    P.S using delay() you have to take in  to account the overhead what the rest of the loop has to do.
    You should not use a fixed pause but a pause based on interval if possible = a interval timer.
    Go for 2400 baud first as 9600 baud bitbanged uart is not for the novice. 

    As with 9600 just the difference between what your code does if sending a 1 or 0 bit may add up.
    If uart  stops working with values that has to many 1bits set is a giveaway that this is happening etc.
    Better disassemble that part of the C code and post it here and I can tell you.

  • 0 in reply to Tony Philipsson
    Intellectual 420 points

    So, I'm not sure I'm clear here (and I think this is the source of the issue :-P )

    - why would 9600 baud be any different, code-wise, from 2400?  Is it not just "wait until the right time, then send the bit"?  Or is it that, since we are delaying for whatever time, the overhead causes more problems because it takes, comparatively, more of a chunk of the delay?

    - Would 2400 give me more robustness to a badly calibrated system clock?  If the clock is off by x% then would that not cause the same problems with low baud rates as with high?

    This forum, and you in particular, have been extremely helpful to me in better understanding this uC, thanks a lot!

    Mike

  • 0 in reply to Michael Stachowsky
    Guru 12050 points

    Uart uses a system of sampling the bit state on perceived fixed time.

    2400baud allows for knowing the exact cycles the loop take to be less accurate, as in a % that is still a low error.

    104 cycles +- 10 cycles = failure at 9600
    416 cycles +- 10 cycles = still OK at 2400

  • 0 in reply to Michael Stachowsky
    Guru 46710 points

    Michael Stachowsky said:
    why would 9600 baud be any different, code-wise, from 2400?

    Difference is error of bit rate rate. The higher speed - the harder to get desired bit  rate precisely - because clock frequency is limited and clock divider is integer number, not fractional one

  • 0 in reply to Ilmars
    Intellectual 420 points

    To finish this up, we determined what the actual problem was.  For anyone else who has similar problems trying to bit bang serial, here it was:

    1) We set DCO to 1MHz in the code but do not have an external crystal, so we were just assuming that the error between the clock we want and the clock we get was "small enough" to not be much of an issue.

    2) We failed to account for the fact that the DCO's frequency is *highly* dependent on voltage.  We were also supplying, accidentally, too high a voltage for the chip (4.6V...oops)

    As a result, that 1MHz we were expecting was probably around 1.2MHz or something not at all what we wanted.  We put a 3.3V regulator on it and now the serial works fine at 2400 baud.  I won't test it at a higher baud rate because we don't need it.

    So there's the lesson for you: double check your voltages! (and use an external crystal if you're having timing problems :-P )

  • 0 in reply to Ilmars
    Guru 227245 points

    in debug mode, the compiler usually does not do any code optimization that might confuse the debugger. However, this might unexpectedly break code when optimization is done in release mode.
    Basically, the two are just different sets of project settings, and you can add more if you want.
    By default, the debug setting defines a debug symbol that you can use to conditionally compiler your own additional debug code into the binary, which is not compiled when in release mode (like blinking LEDs or additional printf output)
    #ifdef _DEBUG // or similar - check the project settings, additional defines
    // debug code
    #endif

**Attention** This is a public forum