FTM counter stops working after entering debugger once

[corecode]

I noticed that FTM0 on my MK20DX128 will stop incrementing the counter after I enter the debugger once:  a simple break + continue is sufficient to make FTM stop working.

If I set CONF[BDMMODE] to 0b11, it works as it should, but does not suspend operation during debugging.  Is this a hardware bug?

Code used for testing:

#include "MK20DZ10.h"

void
main(void)
{
  SIM_SCGC5 |= SIM_SCGC5_PORTC_MASK;
  PORTC_PCR1 = PORT_PCR_MUX(4);
  SIM_SCGC6 |= SIM_SCGC6_FTM0_MASK;
  FTM0_MOD = FTM_MOD_MOD(0xffff);
  FTM0_CNTIN = FTM_CNTIN_INIT(0);
  FTM0_C0SC = FTM_CnSC_MSB_MASK | FTM_CnSC_ELSB_MASK;
  FTM0_C0V = FTM_CnV_VAL(0x8000);
  FTM0_SC = FTM_SC_CLKS(1);

  for (;;)
  /* NOTHING */;
}

[Mario_Guardado]

Hi,

I had a similar “issue” few time ago.  As David commented this behavior is caused due to the actual FTM/BDM implementation.

The FTM behavior in BDM mode works as follow:

FTM module entries in BDM mode once a break point is set in the code or when the FTM registers are accessed using the Register Window or Memory Window debug tools.

It is not defined as an issue, it is simply the actual implementation.

Possible workarounds I found:

- A dummy read of the FTM used (i.e. FTM0_CNT) can be implemented at code to unfreeze the FTM_CNT and output channels when register/memory windows are used.

- Do not use or close the register window or Memory Window debug tools

I hope it helps.

Mario

[corecode]

Can you please add this as an errata or define it clearly in the documentation?

[DavidS]

Hi Simon,

The FTM lacks a “when debugging stop the clock” setting like the PIT timer module has:

So whenever I’m testing code for the FTM I have to let it run full speed and not use breakpoints.

I think this a design limitation for the FTM.

Regards,

David

[michaelsteffenf]

David,

There is a setting in the FTM which allow the FTM timer to stop or continue to run in debug mode.

Mike

[niranjanbc]

where can I set the BDM, is there setting in KDS.

or do I need to add that in code.

[mjbcswitzerland]

Hi

FTM_CONF register sets the debug behavior.

Can be set in code or by a script file when connecting to the device with a debugger.

Regards

Mark

[niranjanbc]

hi Mark,

I am setting BDM in FTM_CONF has below but it is generating Hard fault interrupt.

FTM0_CONF |= 0xC0;

  FTM1_CONF |= 0xC0;

  FTM2_CONF |= 0xC0;

  FTM3_CONF |= 0xC0;

I also tried initializing, still generates Hard fault interrupt.

FTM0_CONF = 0xC0;

  FTM1_CONF = 0xC0;

  FTM2_CONF = 0xC0;

  FTM3_CONF = 0xC0;

Thanks

Niranjan

[niranjanbc]

Hi Mark

if I set the BDM after FTM iniitialization , I dont see the Hardfault.

but now I cant do suspend, this option is disabled.

Niranjan

[mjbcswitzerland]

Hi

FTMx_CONF can only be written to after the FlexTimer module has bee enabled (in SIM_SCGC3 or SIM_SCGC6, depending on channel(s)).

I don't expect that there is a releationship between this setting and the behavior of the IDE.

Regards

Mark

[DavidS]

Don’t know how I missed that Mike….but thanks. Will have to try that.

Regards,

David

[jrychter]

Mario Ernesto Guardado Ruiz wrote:

It is not defined as an issue, it is simply the actual implementation.

How is that not an issue?

I've just spent more than an hour trying to figure out why my FTM was freezing and only counting to 2. It seems I am not the only one. This definitely deserves a mention in the errata, along with a workaround (dummy read of the FTM0_CNT register).

The FTM stopping when entering BDM is expected. The FTM not restarting after execution is continued is a bug.

[jrychter]

I just noticed that there is an additional side effect: either the "FTM freezing problem" or the workaround with the dummy read of CNT causes FTM_CnV writes in EPWM mode to bypass buffering: values get written to CnV immediately, so you might get two matches per timer period. This isn't something you can expect from reading the documentation.

This means that debugging code that uses the FTM is effectively impossible.

[egoodii]

I think we will just have to call it a 'design weakness'.  It does seem most unpleasant for BDM 'reads' to impact peripheral modules in the same way as 'other bus masters' given the side-effects often involved in such access, but there it is...

Such a 'read' can clear 'data available' flags, empty FIFOs, or as in this case set 'access freeze' flags designed to insure valid register-access interlock.  What that all means is that you generally CANNOT look at peripheral module memory space, either in the 'registers' window OR the 'memory' window.

[corecode]

So it is a hardware bug - the FTM peripheral does not correctly un-stop when the debugger continues execution.

[DavidS]

Hi CoreCode,

Some peripheral modules do not operate when in debug mode and you have to let the code execute full speed and instrument it to determine what is happening.  I don't like that feature in a peripheral and wish all designers would implement a "debug" mode.

The Reference Manual does have the following:

36.3.4 Counter (FTMx_CNT)

The CNT register contains the FTM counter value.

Reset clears the CNT register. Writing any value to COUNT updates the counter with its

initial value, CNTIN.

When BDM is active, the FTM counter is frozen. This is the value that you may read.

Memory map and register definition

K20 Sub-Family Reference Manual, Rev. 1 Mar 2012

I've also attached a test file that plays with the FTM1 (I tested with TWR-K60D100M) and it can be setup as polled or interrupt mode.  I tried to comment the code as best as I could so it might help others.

This code can replace the MQX4.0/mqx/examples/timer/main.c

Regards,

David