Debugging issue with FRDM-KE02Z40M

[davetelling]

I have two FRDM boards, and both exhibit the same behavior. If I run the sample programs provided by Freescale, using the IAR toolchain, they generally seen to to do what they are supposed to. However - I have tried a variety of small projects that use the FTM, and all do the same thing - when I build and debug, the debugger interface comes up as expected, and I click the "run" button. Nothing happens on the FRDM board. If I click the"halt" button on the debugger, it is always stalled at one of two places - either the "default isr" in vectors.c, or whatever the FIRST line of code is that calls an FTM setting.

For example, I have a line: FTM0_MODE = 4; If this is the first call to the FTM, the program will stall/crash here. If I click the halt button, it will stop at this line. If I click the single-step enter button, the debugfger shows a 'run" condition (i.e. it doesn't step, it's as if I clicked the "run" button) and if I click "halt" again, it will be at the start of that line. If I switch to the assembler mode, and click the single step enter button, it will immediately jump to the default_isr in vectors.c, and then alternate between the default_isr function and the LAST line of the assembler function (STR R1, [R0]).

If I comment out the FTM0_MODE line, then the program will run until it encounters another FTM access, then stall in the same way.

I am totally stumped here, and need some help, as my ultimate application depends very heavily on the FTM. Below is a sample of what I'm trying:

/* timer_int_setup.c tests various timer interrupt & counting functions */

#include "common.h"

#include "ftm.h"

#include "wdog.h"

//#include "rtc.h"

/********************************************************************/

int main (void)

{

uint16_t counter;

uint32_t temp;

wdog_disable();

typedef struct

{

  uint8_t Port0;

  uint8_t Port1;

  uint8_t Port2;

  uint8_t Port3;

} fourBytes;

typedef struct

{

   uint16_t dbyte0;

   uint16_t dbyte1;

} twoDbyte;

union {

  fourBytes portBytes;

  twoDbyte port16;

  uint32_t portWord;

}PORTA;

  temp = FTM0_FMS; WILL STALL HERE, UNLESS COMMENTED OUT

  FTM0_MODE = 4; // set WPDIS bit WILL STALL HERE, UNLESS COMMENTED OUT

  GPIOA_PDDR = 0xffffffff; /* all ones for outputs */

  counter = 0;

  FTM0_SC = 0x0000000f; // set for system clock, /128 WILL STALL HERE, UNLESS COMMENTED OUT

  while (1)

  {

   PORTA.portWord = GPIOA_PDOR;

   PORTA.port16.dbyte0 = counter;

   GPIOA_PDOR = PORTA.portWord;

   counter = FTM0_CNT; WILL STALL HERE, UNLESS COMMENTED OUT

   if (counter == 100)

   {

     // toggle bit 0 of GPIOA

       GPIOA_PTOR = 00000001;

   }

  }

}

[egoodii · Accepted solution]

Sounds like you haven't enabled the clock for FTM0, so you get a bus-fault on any access, that may take effect immediately or 'after a couple clocks' with Cortex write-buffering.

[davetelling]

Earl, I have a line in my code: FTM0_SC = 0x0000000f;

As far as I can tell, this should select the system clock, with a 128 divisor. Is there something else I need to do?

Thanks,

Dave T.

[davetelling]

Well, I found that if I add this:

SIM->SCGC |= SIM_SCGC_FTM0_MASK;

The debugging seems to run normally.

Earl, you were right! Thanks!

[egoodii]

Yes, THAT clock!  Sorry I wasn't more explicit (and more timely!).  That 'enable' powers-up the peripheral and brings the registers into the bus-space (as well as the actual clocking of internal 'flops').