Application hangs in HWTIMER_SYS_Start

cancel
Showing results for 
Search instead for 
Did you mean: 

Application hangs in HWTIMER_SYS_Start

Jump to solution
347 Views
filipdossche
Contributor III

Hi,

I am writing a KL03Z application which uses a HWTIMER interrupt and a CMP0 interrupt.

The code to initialize both peripherals is generated by the processor expert.

The callback function for the HWTIMER in events.c is definitely correctly called once every microsecond.

I can put breakpoints on the start of it, check that it performs the implemented counting functions etc...

I am not getting any CMP interrupts though and found out that is because I never get to the point where I call "CMP_DRV_Start( FSL_CMPANALOG1 );"

using breakpoints and stepping I have found that it is due to a problem occurring in "HWTIMER_SYS_Start" which is also processor expert generated code.

This is what it looks like:

/*FUNCTION**********************************************************************

*

* Function Name : HWTIMER_SYS_Start

* Description   : Enables the timer and leaves it running. The timer starts

* counting a new period generating interrupts every time the timer rolls over.

*

*END**************************************************************************/

_hwtimer_error_code_t HWTIMER_SYS_Start(hwtimer_t *hwtimer)

{

    /* Check input parameters */

    if (NULL == hwtimer)

    {

        return kHwtimerInvalidInput;

    }

    if (NULL == hwtimer->devif)

    {

        return kHwtimerInvalidPointer;

    }

    /* Start timer */

    assert(NULL != hwtimer->devif->start);

    return hwtimer->devif->start(hwtimer);

}

The point where it fails is the last "return" line. I can put a breakpoint or step to there and it works.

If I try to step past it, put a breakpoint after it or try to put a breakpoint after the function call it never makes it.

The application appears to hang permanently.

Does anybody have any idea or suggestion as to what might be causing this ?

Well,  some more findings:

1) The "Kinetis SDK KL03 API reference manual" does not even mention HWTIMER or any of its functions.

2) The KL03 reference manual does not even mention a HWTIMER peripheral so which peripheral are the HWTIMER functions dealing with ?

3) There is definitely a demo application for the HWTIMER in the KL03Z example set, that is why I started using it in the first place.

4) From looking at the call tree when I put a breakpoint somewhere in the callback function it would seem that after the timer is started it does nothing else than executing the interrupt function. At least that would explain why it is not doing anything else.

pastedImage_0.png

5) could it be that 1 microsecond between interrupt calls is too fast ? Surely a 48 MHz ARM Risc processor chip should be able to deal with that?

6) One more for the road: if I set the interval to 1 millisecond it works but for my application to work I need at least a counter value to increment at a 1 microsecond interval.

Message was edited by: Filip Dossche

Labels (1)
Tags (3)
0 Kudos
1 Solution
165 Views
filipdossche
Contributor III

Ok, There was a problem with the clock setup. I cranked it up to 48 Mhz and it was better but did not provide a final solution.

I guess there was just to much overhead in calling the callback function.

In the end I decided to use one of the TPM modules to provide a free running 1 microsecond counter and read that when my CMP edge interrupts occur.

That does the trick: the CMP inettrupts don't occur as fast and maintaining the 1 microsecond counter requires nothing, just the setup.

View solution in original post

0 Kudos
1 Reply
166 Views
filipdossche
Contributor III

Ok, There was a problem with the clock setup. I cranked it up to 48 Mhz and it was better but did not provide a final solution.

I guess there was just to much overhead in calling the callback function.

In the end I decided to use one of the TPM modules to provide a free running 1 microsecond counter and read that when my CMP edge interrupts occur.

That does the trick: the CMP inettrupts don't occur as fast and maintaining the 1 microsecond counter requires nothing, just the setup.

0 Kudos