FRDM-K22F: PIT timer: Does PIT timer start automatically once the count becomes 0?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

FRDM-K22F: PIT timer: Does PIT timer start automatically once the count becomes 0?

1,726 Views
snehalpatil
Contributor II

I am trying to set delay in microsecond for that I am using PIT timer. I have enabled interrupt. I want to know does timer restart when count becomes 0 or do we have to load count and start timer in ISR.

Labels (1)
0 Kudos
7 Replies

1,190 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Snehal Patil,

      If you read the PIT chapter in the K22 reference manual, you will find the count will be reload after it reaches 0:

22.jpg

      So when the interrupt happens, you just need to clear the TIF bit, you  don't need to reload the count.

Wish it helps you!

If you still have question, please contact with me!


Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

1,190 Views
snehalpatil
Contributor II

Hi,

Thanks I got in reference manual.

I want to run PIT timer continuously after some microsecond delay. I tried to do this by checking LED ON/OFF functionality. I am using 2 timer channel 0 and 1 but not able to make LED1 On and OFF continuously. I am making LED1 ON in PIT 0 ISR and LED2 OFF in PIT 1 ISR. After clearing interrupt flags and doing LED functionality tried to start timer in ISR but not getting these interrupt continuously.

Could you please help..

Regards,

Snehal.

0 Kudos

1,190 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Snehal,

    DId you clear the PIT ISR interrupt flag in the interrupt?

    Besides, if you don't use the PIT, with you can toggle the LED?

  I think you should test PIT and the led separately, after all the function is ok, then combine it.

  1. Toggle LED without the PIT, make sure LED toggle is working.

  2.  Use debug to test the PIT, to check whether it can enter the PIT interrupt automatically.

  You should clear the according PIT interrupt Flag,  keep the PIT working normally.

    Please test one PIT channel at first, after it working , then add another PIT channel.

Please follow my step do it.

If you still can't make it work, please upload your project, I would like to help you to check it.

Wish it helps you!


Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,190 Views
snehalpatil
Contributor II

Hi,

Yes PIT interrupt is working fine.

Now I am confused actually how should I give periodbyMicrosec value in structure

pit_user_config_t chn1Confg = {

.isInterruptEnabled = true,

.periodUs = DELAY_TIME

};

I have defined macro DELAY_TIME and I am not understanding how value is assigned to it, i.e if I want to set timer value 240 microsecond what value should be given 240 or 240,000,000. I tried to give both values and checked on CRO but results are not good sometimes getting in millisecond and sometimes I am not able to get results properly to count.

For checking this time I was trying to use LED.I didn’t check LED toggle functionality will check .

Apart from this now I am facing new issue. My code is not getting flashed in board FRDM-K22F neither I am able to debug code , the pointer is not pointing to main.

While flashing I am getting issue as shown in attachment flash_error.png. Debugger used is PE Multilink Universal.

I am using this board for MK02FN128VFM10. Request to reply soon ☹☹

Debugger settings:

Snehal.

0 Kudos

1,190 Views
kerryzhou
NXP TechSupport
NXP TechSupport

Hi Snehal,

  1. About the PIT time value definition.

  You can find it from the K02 reference manual, PIT chapter:, there has an example:

33.jpg

If you want to get 240ms, you should check your bus clock at first, because the PIT clock source is bus clock.

  Then,  calculate the LDVAL register value:

    LDVAL register = (period / bus clock period) -1

  If your bus clock is 50Mhz, then LDVAL register = 12000000-1.

The above is the PIT principle, but if you use the KSDK, you should configure it like this:

DELAY_TIME= 240000;

pit_user_config_t chn1Confg = {

                                .isInterruptEnabled = true,

                                .periodUs = DELAY_TIME

                            };

240ms=240000us.

2. GPIO toggle, please test the function at first.

3, FRDM-K22F board debug and download.

Actually, the FRDM-K22F have the on-board debugger, I don't know why you use the PE multilink again?

If you can't connect it now, please use the JLINK firmware to check the board at first.

Please follow this steps, don't connect your PE multilink again:

1) download the JLINK driver and install it:

SEGGER - The Embedded Experts - Download

2) download the jlink firmware

https://www.segger.com/cms/admin/uploads/userfiles/file/J-Link/OpenSDA/JLink_OpenSDA_V2_1_2015-10-13...

3) Change the board firmware

1' Unplug the board's USB cable.

2' Press the board's "Reset" button. While still holding the button, plug the board back in to the USB cable.

3' When the board re-enumerates, it shows up as a disk drive called "BOOTLOADER".

4'  Drag the new firmware image(JLink_OpenSDA_V2_1_2015-10-13.bin) onto the BOOTLOADER drive in Windows operating system Explorer.

5' unplug and plug the board to your PC again.

6' open the JLINK Commander interface(you can find it from the JLINK driver install path), please check whether it can find the ARM cortex M4 core. And input commander: unlock kinetis

  Check it, whether the unlock kinetis can success.

Wish it helps you!

Any question, please let me know!


Have a great day,
Jingjing

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos

1,190 Views
snehalpatil
Contributor II

Hi,

Actually I am using FRDM board for POC purpose later I would need separate debugger so we are using Multilink Universal.

I am facing with below issue:

I am getting above snapshot when I am trying to flash code or debug code. Along with dialogue box as shown above I also get below message (highlighted in yellow)

This application has requested the Runtime to terminate it in an unusual way.

/home/build/work/GCC-4-8-build/src/gdb/gdb/linespec.c:2445: internal-error: decode_line_full: Assertion `state->canonical_names[i].suffix != NULL' failed.

A problem internal to GDB has been detected,

further debugging may prove unreliable.

Create a core file of GDB? Please contact the application's support team for more information.

(y or n)

I have uninstalled PEmicro and again installed it , also installed drivers, but getting same error ☹

Please suggest what needs to be done.

Snehal.

0 Kudos

1,190 Views
DavidS
NXP Employee
NXP Employee

Hi Snehal,

The following link has pulldown to select the development board you have so you can get debug firmware:

OpenSDA Serial and Debug Adapter|NXP

Select your board (FRDM-K22F) and you will see following:

FRDM-K22F

Board Information click here

OpenSDA version / bootloader

Default firmware application

Latest firmware application

Try getting the PEMicro firmware binary and reload it to your Freedom board.

If that continues to have issue, try the Segger JLink or CMSIS-DAP.

Please note that on the FRDM-K22F board if you want to use external debugger (like PEMicro USBMultilink) then jumper J7 needs to have trace cut on bottom side of board to prevent contention with the on-board debugger.  The schematics have the following note:

SHORTING HEADER ON BOTTOM LAYER

Jumper is shorted by a cut-trace

on bottom layer. Cutting the trace

will effectively isolate the on-board

MCU from the OpenSDA

debug interface.

Regards,

David

0 Kudos