0

I'm currently working on a program for an 8-bit freescale chip (MC9S08QG8) in CodeWarrior v10.3 which uses the timer/ period capture to turn a frequency to an analog voltage.

I've gotten the thing to work pretty well in debug mode, but I noticed when I just flash the .abs file to the target to test the release build, it behaves as if the timer register is skewed. In other words, a 20ms period will normally turn on a DAC in debug mode (as intended). However, when the file is flashed directly, the DAC turns on at about 17.4ms. Ditto for other other cases; an event that's supposed to happen at 6.64ms happens at 5.75ms.

The code is interrupt-based - does anyone know what's different in debug vs direct flash that could cause this? Anything I can disable in debug mode to make it behave like a release build?

Drewster
  • 483
  • 3
  • 10

1 Answers1

1

How did you implement the timing? Are you using a hardware time or do you have a buys wait loop that's tuned empirically? The latter would behave different in debug mode since the compiler adds overhead to collect debug information. In general processors run "slower" in debug mode, or to be precise: the same code executes slower because of the debug overhead

Hilmar
  • 2,015
  • 8
  • 7
  • _The code is interrupt-based - does anyone know what's different..._ – Matt Young Aug 14 '15 at 18:38
  • I'm using a hardware timer/ capture. Essentially, a falling edge will cause the current timer value to be stored in a register, followed by an interrupt. During said interrupt, my code immediately pulls that register into a variable and does stuff based on what that value is (e.g. if(<20000){scale var}). Because of this, the only way for me to "debug" the timer is to let it run and periodically suspend it to check the register, etc. However, I can't think of what debug mode would change about that.. – Drewster Aug 14 '15 at 19:17