Debugging issue with FRDM-KE02Z40M

davetelling — Tue, 18 Nov 2014 23:25:03 GMT

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;

}

Re: Debugging issue with FRDM-KE02Z40M

egoodii — Wed, 19 Nov 2014 16:45:23 GMT

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.

Re: Debugging issue with FRDM-KE02Z40M

davetelling — Wed, 19 Nov 2014 17:21:37 GMT

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.

Re: Debugging issue with FRDM-KE02Z40M

davetelling — Wed, 19 Nov 2014 22:20:32 GMT

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!

Re: Debugging issue with FRDM-KE02Z40M

egoodii — Thu, 20 Nov 2014 04:14:43 GMT

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').

Kinetis MicrocontrollersのトピックRe: Debugging issue with FRDM-KE02Z40M

Debugging issue with FRDM-KE02Z40M

Re: Debugging issue with FRDM-KE02Z40M

Re: Debugging issue with FRDM-KE02Z40M

Re: Debugging issue with FRDM-KE02Z40M

Re: Debugging issue with FRDM-KE02Z40M