We are using Codewarrior 10.6. The processor is MK20DX128VLH7, 64 pin package, using Processor expert, with GCC toolchain.
Having many problems getting this project to work. I have used the HC05,08,9S08, Coldfire for years, the ARM stuff is giving fits..
In the effort to trouble shoot our actual project, we created a new dummy project with 1 bean that toggles an I/O pin in an endless loop.
The frequency of this toggling is about 2.5 times faster in debug mode than when the unit is just powered up. (it's about 1Mhz in Debug and 390Khz in run mode).
Why does the processor run at a different speed in debug than standalone?
I do a test with TWR-K20D72M board to toggle PTC9 pin using Processor Expert [BitIO_LDD] component with CodeWarrior v10.6.
From attached scope screen copy, there without any difference when the code run with/without debugging.
I set the K20 core clock/bus clock run at 50MHz and Flash clock run at 25MHz.
The test code also be attached.
Wish it help.
best regards,
Ma Hui
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Rande
Check the debug configuration to see whether it is loading and executing from SRAM. If this is the case it will probably be faster than when located in Flash since the Flash is slower (although compensated to some degree by caching and speculation operation).
If you are having problems with the K20 check out the uTasker project - µTasker Kinetis support
It gives a complete K20 project out of the box so doesn't require piecing things together and allows you to simulate the Kinetis and the board to make development much faster and simpler. It works with all standard tool chains including CW10.x, KDS, GCC, CooCox, Rowley, IAR and Keil. If you know the Coldfires, it also allows Coldfire and Kinetis projects (any KL or K part or Coldfire V2 part) to be interchanged between the families.
Below is a screen shot of the simulator running the TWR K20N72M board - with UARTs (connected to PC COM ports for real-time operation) as well as USB, SD card (via SPI) etc.
Complete code can be downloaded from KINETIS Project Code Attached is also a simulation executable that can be started by double clicking uTaskerV1-4_K20_TWR.exe (no installation needed) - it connects to COM 9 and attaching a serial loop back device allows controlling its command line menu, which enables working with the SD card, checking the accelerometer operation, controlling LEDs on the board and various such things.
Regards
Mark
Hi Mark,
I think all the problems we have stem from some setting that uses SRAM when we want to use FLASH.
We do not see in the debug configurations where we can choose to not use SRAM.
We are using the configuration named FLASH, but it seems to want to run from SRAM.
Is there some setting somewhere that forces both debugging and standalone to always use FLASH (never use SRAM)?
Thank you,
Rande
Check the linker script file being used in your debug configuration. That will be defining the location of code.
I don't know of any other settings - you may like to ask in the Codewarrior forum for CW related questions.
Regards
Mark
Might be that the debugger is 'tweaking' the clock registers. I'm using the KL25/15 parts with SwD. Might be that the debugger configures the clocks to the flash memory to run faster than the default. (Helpful eh?)
If the K20 is similar to the Kl25 you can configure the CLKOUT pin to put out 'bus clock' Might try that and then see if the bus clock frequency changes in debug vs normal mode.