Debugger Effect on MCU Timing?

[Plato220]

Let me preface this by saying I am relatively new to Freescale device development. I am working with a DEMOQE board with the FLEXIS 8-bit device installed (QE128), and cutting my teeth using the Processor Expert function in the IDE. A component of my project will be to output a PWM signal from a MCU pin, so I have started with the PWM bean in Processor Expert. The output I am requesting is 10ms period with 5ms pulse width from PTA0. The program compiles correctly, and the TTS/RTD is able to program the MCU without any errors. The problem arises when I run the program with the debugger. My oscilloscope is measuring the pulse widths at 5.25ms with a period of 10.5ms. Now here is what's interesting. If I close the debugger, and cycle the power on the development board, the pulses are right where they are supposed to be - 5ms wide with a period of 10ms. It seems to me that there is some effect of the debugger on the timing of the MCU. Does anyone have any ideas as to what is going on here?

[Plato220]

Thank you both for your help on this. After reading your posts and digging around a bit I have come up with a hypothesis. Perhaps you would consider commenting on it... Processor expert is setting the reference clock to 32.768kHz, which gives a 4.194MHz clock through the DCO. PE is setting the modulo value of the TPM to 41942. Doing the math, this results in a period of 9.999 ms - right where it should be. Now, when I go to load the code, the bottom box on the PEMICRO Conneciton manager is for trim control. It says that the default reference frequency is 31.25kHz. Doing the math with this value gives the period that I am seeing on the oscilloscope - 10.48 ms. WhenI check the 'use custom trim reference frequency' box, and enter 32768 for the frequency, the code will load, but there is no output at all to the pin. There must be something else that I am missing if this is even the problem at all.

[peg]

Hello,

Is the code being produced for the PWM using a timer module in PWM mode?

If it is then the debugger slowing down the code should be irrelevant. The PWM then will be produced in hardware which should only be affected by the clock. Question is why should the clock be different when using the debugger.

What is your clock setup?

[bigmac]

Hello,

Check the value within the ICSTRM register at address 0x003A, and compare with the value stored at flash address 0xFFAF.  The two values should be identical, assuming the initialisation code sets the ICSTRM register using this flash value.  If the two values are different during debug, this might account for the differences you are observing.

For the PWM frequency that you require, a trim frequency of 31.25 kHz would seem to be a better choice.  This will require a modulo value of 39999 with a bus frequency of 4.000 MHz.  This may simplify  the calculation of the required channel value for a given duty cycle.

Regards,

Mac

[peg]

Hello and welcome to the fora, Plato

Quite simple! Don't believe the marketing hype. The debugger is not non-intrusive. It does steal cycles from the CPU and it will slow down a running programme slightly. It is "not very"-intrusive! Mostly it still allows you to see what is going on though. For precise timing you need to run without the BDM doing accesses.

[bigmac]

Hello,

This does seem to suggest that the PWM bean within PE does not use PWM mode associated with the TPM module - I might have expected that the CPU cycle stealing for the debug process would not have affected the operation of the TPM module hardware.

If the PWM bean does use a software method, it may also be susceptible to delays caused by other interrupt processing.

Regards,

Mac